On Tue, 2003-02-11 at 00:02, Shevek wrote:
> 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.
What does 'written traditionally' mean here? Oh come *on*, read the
comment: "Programmer cluefulness being equal".
There isn't much of that about. Hence a myriad of systems that claim to
be able to substitute for what I shall choose to call "talent".
>
> > 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.
And then again, you may not. You may also get a large overhead
collecting this information, altering the code accordingly. You may also
get race conditions and oscillation as you exercise different bits of
code and recast it on the fly.
Basically, one either "understands" or one does not. In the end, there
is no substitute for "talent" or if you prefer "knowing what you are
doing" and "experience". Who do you suppose has to write all these
wizzbangs?
>
> 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.
Yes, maybe, but show me one of these systems that _consistantly_
produces faster code than someone who is "talented". I willingly agree
that the code is physically produced faster - but it don't go as well.
And this is the nub of it. Basically there aren't enough "talented"
people to go around. Therefore people try to throw ("talentedly"
programmed) machines at the problem to try to get a better result than
average. But that is all you will get: slightly better code a lot
quicker.
> 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.
I can only say that I fundementally disagree. A talented implementation
will be faster in execution than perl. Period. Actually, I strongly
suspect that even a pretty shoddy implementation will execute faster
than perl.
Whilst I am about could I remind people of the existance of PCRE? This
seems to be a pretty good (cluefully hand written) largely perl
compatible regex library. I use it quite a bit.
Dirk
--
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Product, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.
