15 Aug 2002 pphaneuf   » (Journeyer)

Jeff Darcy has replied on his weblog to an email I had sent to David McCusker, which the latter had put up on his weblog. Whew! Here's a continuation of this discussion.

The performance of smaller/simpler instructions is usually worse than the equivalent CISCy code (and I'm thinking of a much bigger granularity than CISC) because the instruction decoding overhead becomes a bigger percentage of the equation, everything else being equal.

Jeff asks why we should be worrying about the performance of interpreting code, when incremental compilation of those virtual instructions is the right thing to do when performance is what you want. He makes a good point about the level of abstraction and expressiveness being the important things, but I would point out that the in-memory representation of a Perl program plus the memory used by the native code implementation of these instructions is often smaller (and more cache friendly) than the fully spelled out native versions, and the quality of the virtual instructions implementations optimization is probably better than what an incremental compiler can do. In fact, the Perl interpreter has put all of the virtual instruction implementations in a single compilation unit (and they also tweaked the order of these inside that unit), so that they are in a contiguous area of memory. All of this adds up to code that's almost as fast as native, optimized C++ can be.

They can also be loaded from disk more quickly (though Perl itself doesn't take much advantage of this, as it compiles the code every single time).

For reference, the test program in "The Practice of Programming" (Kernighan/Pike) is a Markov chain generator. The timings and lines of codes were as follow (the first timing is Pentium II 400/Windows NT/VC++ and the second is MIPS R10000 250/Irix/can't remember the compiler):

  • Plain C: 0.30/0.36 seconds, 150 lines of code
  • Perl: 1.0/1.8 seconds, 18 lines of code
  • C++/STL: 1.5/1.7 seconds, 70 lines of code
  • AWK: 2.1/2.2 seconds, 20 lines of code
  • Java: 9.2/4.2 seconds, 105 lines of code

Perl is even faster than C++/STL! I wonder how good of a job would a JIT compiler do with this? Then again, it is possible that the Java version did use a JIT compiler, and it didn't do it much good if it is the case!

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!