in reply to compiling perl scripts aka why is perl not as fast as C

What makes development fast is the use of the flexible scalar type. What makes the code "slow" is the use of the flexible scalar type.

strict typing doesn't by itself contribute to any speed gains, does it?

Actually, it has everything to do with it. int y = x; is two machine opcodes, and the optimiser can reduce the number of opcodes the next statement takes if it uses x or y. On the other hand, my $y = $x; require memory allocation, type checks, magic checks, and support to copy the string, the integer, the float and/or whatever else might be contained by $x.

Replies are listed 'Best First'.
Re^2: compiling perl scripts aka why is perl not as fast as C
by punkish (Priest) on Mar 21, 2010 at 05:56 UTC
    Fine then. We, the good programming citizens, are already used to declaring our variables with use strict, so tighten it even more by making us declare their types as well as required, but also make it possible to compile the program so it doesn't have to be interpreted any more, and endow it with whatever magic required to make it as fast as C. Why that is not possible is what I am trying to understand.
    --

    when small people start casting long shadows, it is time to go to bed

      so tighten it even more by making us declare their types as well as required,

      I said above "What makes development fast is the use of the flexible scalar type". So you'd lose that, it seems to me. You'd lose a lot more, in fact. The stuff that makes Perl Perl. Even basic stuff like returning lists from functions would become (a lot?) more complicated.

      so it doesn't have to be interpreted any more,

      Perl isn't interpreted. Perl programs are compiled into a list of native function calls. Perl just calls one function after another:

      while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) { PERL_ASYNC_CHECK(); }

      And soon, probably

      while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {}

      (PERL_ASYNC_CHECK checks if a signal was received. A proof of concept was given that shows that moving it can completely eliminate the cost of checking for signals.)

      endow it with whatever magic required to make it as fast as C

      There is already a programming language with all that magic - C. You have the choice, C is fast and lean, it is actually a very small language. Then again, ever tried using regular expressions in it, or string handling? You can do those things, but parts of your body will start to decompose as you do so.

      Perl can trace its lineage back to AWK - Aho, Weinburger, and Kerningham. The same Brian Kerningham who worked on C (with Denis Richie). He recognised that C wasn't good at everything, so we got AWK, but he never intended it to replace C, it is just another tool in your toolkit. Selecting the right one is the trick.

        Then again, ever tried using regular expressions in it, or string handling

        You could have a language that has C-style typing and the same integration of regex that Perl has. Remember, the OP didn't ask for C, just for some features of C.

      > Why that is not possible is what I am trying to understand.

      I think what you want could be done is something like a cerl corresponding to cython, such that you can write and embed (statical typed!!!) C but using Perl syntax.

      Just for time critical inline snippets.

      But while the WP page claims fantastical speed-gains I just read an interview with Guido van Rossum stating that for unpolished general code the speed gain diminishes to only about 50%...

      Wow, indeed worth the trouble ... ;-)

      And Python is known to have a much slimmer implementation than Perl, so try to figure out where the gain will be here... !

      A general solution can be rather found in JIT Just-in-time compilation, just check for the recent speed gains achieved for JS.

      But please note: JS is even much slimmer than Python!

      Cheers Rolf