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


in reply to Benchmarking the basic operations

It would be interesting to see results of this benchmark from other platforms; these are operations where the efficiency definitely depends on the underlying hardware.

Since >= and < took almost exactly the same amount of time, I conjectured that $foo >= $bar might get translated to $bar < $foo by the compiler, but this appears to not be the case:

But then, $foo >= $bar is actually equivalent to $bar <= $foo, so you don't gain anything by doing the conversion. :)

Replies are listed 'Best First'.
(tye)Re: Benchmarking the basic operations
by tye (Sage) on Jan 24, 2001 at 23:58 UTC

    <sarcasm>Yes, then we could make our programs run faster with:

    if( $^O =~ /^MSWin/ ) { $comp= $a lt $b; } else { $comp= $b gt $a; }
    </sarcasm>

    Please run the benchmarks 5 times with the order in which the different tests are run changed each time (prepend different letters to each case as Benchmark.pm runs them in order sorted by name). Then you can try to interpet the numbers. It wouldn't surprise me if the optimizer removed those operations anyway and you are just timing a bunch of loops.

    It is quite normal for the exact same operation to benchmark 5% or even more different each time you try. This is especially true of tiny things like what you are trying to benchmark.

    It just so happens that these are also the types of things that you don't want to optimize.

    Comparing the speed of lt, gt, ge, le, ne, and eq is just, well, silly. The difference comes down to a fraction of a machine language instruction. The time it takes to dispatch a single Perl opcode dwarfs that like a flea on an aircraft carrier.

    Some of the other comparisons might be interesting if the benchmarking code and results were shown to be actually doing a comparison. But I want to stress that this is not the type of stuff you should even think about when trying to make your code run faster.

    Okay, I feel slightly better. Now back to our regularly schedule trolling^Wdownvoting^Wscholarly discussions. (:

            - tye (but my friends call me "Tye")
      Quote:
      Yes, then we could make our programs run faster with:
      if( $^O =~ /^MSWin/ ) { $comp= $b gt $a; } else { $comp= $a lt $b; }
      Well, you must not have done the actual benchmark. I did, and I found that on MSWin32, it's gt that is faster, not lt. So the correct way to optimize this comparison is:
      if ($^O =~ /^MSWin/) { $comp= $a gt $b; } else { $comp= $b lt $a; }

      ;)

      You said,"

        Comparing the speed of lt, gt, ge, le, ne, and eq is just, well, silly. The difference comes down to a fraction of a machine language instruction. The time it takes to dispatch a single Perl opcode dwarfs that like a flea on an aircraft carrier. "

      How do you define dispatch and opcode? Apparently I'm not even literate in what constructs to focus on when optimizing, or how to isolate dispatch in a benchmark.

      coreolyn

        Sorry, those aren't my terms. :) Dispatching opcodes is a description I've heard of how Perl executes the code that it has compiled. So Perl has a fairly high overhead per opcode.

        The constructs to focus on when optimizing are the contructs that take the big chunk of the time. And usually the only big win you have when optimizing is to change the algorithm, that is, change the whole way you do things. Tweaking tiny things here and there is usually a waste of your time.

        Now occasionally you can do something simple like change a s/\W+//g to tr/a-zA-Z0-9_//cd and get a big speed improvement IF you are doing that operation on a huge number of really long strings.

        Another way to look at is, if you need to use Benchmark.pm in order figure out which of two ways is faster, then it probably isn't worth your time to be worrying about that "optimization". Using Benchmark.pm is a good way to figure out how much faster something is. And it can be fun and/or interesting to compare things with Benchmark.pm. But if you don't have a real problem that runs noticeably faster after your change, then the change really didn't make much difference.

                - tye (but my friends call me "Tye")