🚀 go-pugleaf

On 22 Jan 1996, Randal L. Schwartz wrote:

> Tim> An important point, though, is that all 'reasonably' written C programs
> Tim> will run within a factor of 2 or so of 'about as fast as you can get,
> Tim> while for some problems, Perl won't be able to break through about a
> Tim> factor of 7 or so, even if you are a Perl expert.
> 
> I just want to point out to everyone that you are simply making that
> figure up based on what you think Perl is doing internally.
> 
> Tom Christiansen has had a long-standing bet that someone can't give
> him a program in C that he can't make run no more than "e" times
> slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
> done it.

hang on.  i think you missed what he's saying.  he said, effectively,
no that perl runs no less than 7 times slower than c, but that it runs
about 3.5 times slower.  ok, it's still about 26% up on e, but it
isn't quite as far from reality.

obviously, though, something that perl is very efficient at will go
like anything, because that's what the bytecode was designed for.
(similar results can be seen when rewriting a forth word in assembler,
for example.)  but for "generic" applications, of course c will
outpace perl, simply because a bytecode interpreter adds a 1-200%
overhead to _any_ program.

xian the desk lisard -- cdahello@comp.brad.ac.uk
    time's taught the killing game herself
  NO        i taught the killing game
                                              first