in reply to Re: Believably slow..
in thread Unbelievably slow..

Switching to an iterator-style for from the C-style for, using lexicals instead of globals reduces my running time from ten minutes thirty seconds to seven minutes thirty seconds. If you weren't aware the C-style for is equivalent to the pseudo-code initializer; while( condition ) { ... ; post_loop_action } which involves more steps than a .. iterator. In my example I moved the my() parts out of the tight loop because they have runtime implications. I used lexicals over globals because its one opcode lighter (a very, very cheap opcode though). Switching to 'use integer' further reduced the runtime to nine minutes forty five seconds (did I mention I'm doing this on an otherwise unburdoned machine?) and six minutes respectively.

The net effect is this particular form of "optimization" didn't buy me all that much but just shows that perl doesn't compete with simple things like that C++ which fits nicely within the processor's cache and is just a few instructions. The equivalent perl code is significantly more complex and of course takes longer. I wouldn't be surprised if most of the example's compiled C++ code was mostly register operations.

# The optimized perl code use strict; use warnings FATAL => 'all'; use integer; my $ans = 0; my $total; my $shift; for my $num ( 0 .. 16777216 ) { $total = 0; $shift = 1; for my $i ( 1 .. 24 ) { $total += $num & $shift ? $i : -$i; $shift <<= 1; } $ans++ if $total == 0; } print "$ans\n";

Replies are listed 'Best First'.
Re: Re: Re: Believably slow..
by waswas-fng (Curate) on Jun 22, 2003 at 21:54 UTC
    I guess you can look at it this way, your task is simular to making a round object that will roll down a hill, C lets you make just a simple wheel with no other baggage, Perl lets you make a wheel but gives you all the baggage that comes along with making the rest of a car. There is overhead to all of the memory managment, hash tables, etc that comes with even a one liner perl script -- stright C code can avoid most of this if it is not needed. On the other hand your C app as it grows into the "car" where it becomes more complecated will start to perform much more like the perl script overall.

    -Waswas

      Of course. Perl is a C application and is only slower and bigger because it must be so flexible. As a C application becomes more flexible there's a point at which it starts working its way into perl's territory.

Re: Re: Re: Believably slow..
by ant9000 (Monk) on Jun 23, 2003 at 13:29 UTC
    I've been trying your optimized code on my machine (an old Duron 700MHz, under medium load):
    $ time ./bench.pl
    187692
    
    real    17m12.507s
    user    10m3.640s
    sys     0m1.300s
    

    so it's still very slow compared to what it does.
    Then, I've tried to compile it:
    $ perlcc -O -o bench bench.pl
    $ time ./bench
    187692
    
    real    12m35.665s
    user    6m1.480s
    sys     0m0.720s
    

    It still is definitely slow, but you get an evident boost in performance just by compiling it into C code... something to remember for situations in which you really need Perl for doing lengthy tasks.

      Well... at that point you should be using Inline::C. You write just that one function in C and leave the rest in C. You should not be under the illusion that perlcc is a substitute for that. In fact, Inline::C is one of the premier ways to interface with C stuff these days. You'd probably even want to pick it over XS when possible.