On Mon, 10 Feb 2003, Paul Makepeace wrote:
> On Mon, Feb 10, 2003 at 10:42:57AM +0000, Andy Wardley wrote:
> > I'm a little surprised by that. Although I must admit that I've never
> > written IIS extensions in C++, I'm surprised that it offers significantly
> > better performance than a mod_perl solution.
>
> Programmer cluefulness being equal, when did interpreted, profiled
> languages start even slightly approaching the speed of compiled,
> profiled languages like C(++)?
Look at DyC. It's been in SIGPLAN, I think. I forget.
> AFAIK, Perl just gets slower each rev, not faster.
>
> What am I missing here?
AICI, the current Perl interpreter is written traditionally whereas the
Parrot assembler interpreter is written to allow direct threaded
interpretation. This should reduce the bytecode overhead, but doesn't give
any of the advantages of a system like DyC.
> Having said that, I've heard of compilers being so smart they outpace
> hand-coded C but I imagine on the whole that's the edge case.
Basically, you have more information at runtime than you have at compile
time. Your basic yardstick is compile-time optimised C. This has to make
certain assumptions about locality, branch taken/not taken, and so on. At
runtime, you get actual statistical information about things like branch
taken optimisations, so you can manage instruction scheduling, which way
to do the jumps, even on which branches to spill registers, and get a
considerable speedup with the runtime information.
Bytecoded systems typically maintain a lot more semantic information than
simple compiled C or assembler. Therefore, after flash compiling to
instruction code, it's possible to annotate the semantic information in
the bytecode with the runtime statistics, and use this to guide the
optimiser in a re-compilation of the binary.
There are many other toys that you get from runtime optimisation with
semantic informationon on which I might discourse but you would very
rapidly get bored. Er. Make me give a talk one day if you really want to
know, then I'll have an excuse to read up.
It is still worth noting that a Perl implementation of Joe's String
Mmunging System will very likely be faster than one written in C simply
because Perl's algorithms for string handling will be more efficient than
Joe's general purpose C algorithms, since more time and expertise has been
put into them.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print"$x\n";eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;&{$x}(\$x);};};}
foreach my $i (3..65535) { &{'2'}($i); }
