http://www.perlmonks.org?node_id=1025750


in reply to Re^4: Curious find while comparing grep, map, and smart match...
in thread Curious find while comparing grep, map, and smart match...

but in this instance he was wrong.

Really? I added this sub:

sub shuffleEm { ( shuffle 1 .. $range )[ 0 .. $uSize ]; }

To your benchmark:

cmpthese( -1, { grepGen => sub{ @grep = grepGen(); }, mapGen => sub{ @map = mapGen(); }, smartGen => sub{ @smart = smartGen(); }, shuffleEm=> sub{ @shuffled = shuffleEm() }, } );

And got these times:

C:\test>junk Rate grepGen mapGen smartGen shuffleEm grepGen 35.3/s -- -51% -97% -100% mapGen 72.6/s 106% -- -94% -100% smartGen 1250/s 3439% 1621% -- -95% shuffleEm 26859/s 75977% 36902% 2049% --

And that doesn't include the time and memory you waste building your pointless pool of 1M values.

But hey. It's your time you are wasting.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^6: Curious find while comparing grep, map, and smart match...
by dbuckhal (Chaplain) on Mar 27, 2013 at 17:19 UTC

    Yes, you added an efficient random number generator, but how do you think those "shuffled" results relate to what the other results represent? What do you think I am benchmarking? How do you interpret the results you posted?

    You are pinpointing on a specific facet of my code and not looking at my code as a whole.

      The output of your program is meant to be a set of unique random numbers. How it is achieved is surely irrelevant (well almost). The code produced by BrowserUk delivers the same output as the previous 3 functions in a much shorter time.

      I hope this is regarded as informative and educational. TBH, I didn't think of looking at the problem in the same way as BrowserUk did until he posted his idea. It often happens, especially round here, that people look at a problem completely differently from the way you do and achieve a much better result. It's happened a few times to me as well. I believe it's called an XY problem, when people come on here talking about how to do Y when they should really be talking about X, the step that got them to Y; and its the person who first spots that who often produces the most interesting answer.

      If you are arguing that what he achieved was "against the rules" in some way, and you expected each function to have to sort through duplicates, then knock yourself out....:-)

      A Monk aims to give answers to those who have none, and to learn from those who know more.
        How it is achieved is surely irrelevant (well almost).

        Actually, it is absolutely relevant, because that is the core of my benchmark: comparing how fast grep, map, and ~~ process data. It is the generation of the data set that is irrelevant and probably can be replaced with BrowserUK's method, because it probably does not matter if what each of those functions process is unique, or not.

        note: this posting spree has really helped me improve on my posting markups!

      those "shuffled" results relate to what the other results represent?

      They achieve the same results -- an array of 100 random integers in the range 1 ,, 120 -- 20 times more efficiently than your best attempt and nearly 100 times more efficiently than your worst; whilst saving 100MB of memory and the setup costs.

      And the random selection of the values in that array is statistically fair with my method and not with yours.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        If my goal was to simply generate an array of unique random numbers, then you are correct and I completely understand, and appreciate, your solution. The memory cost saving ability of shuffle is definitely invaluable. But, that was not my goal. My goal was to benchmark the filtering/processing methods of grep, map, and~~ against the same data set.

        Can you see where I did not think your results directly related to the other results? If not, then that's fine.