On Tue, 2003-02-11 at 10:54, Shevek wrote:
> On 11 Feb 2003, Dirk Koopman wrote:
>
> > On Tue, 2003-02-11 at 00:02, Shevek wrote:
> > >
> > > 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".
>
> while (1) {
> switch (*ip++) {
> case F_ADD:
> f_add()
> break;
> (etc)
> }
> }
>
> which has one range check and five (wet finger) jumps per instruction in
> four code localities.
>
> Compare this to:
>
> #define NEXT() goto *insn_table[*ip++]
>
> f_add() {
> ...
> NEXT()
> }
>
> which has as overhead no range checks and one jump in one locality.
>
> I ask you to remember the comment "cluefulness being equal" for the
> remainder of this mail.
>
Well we have established that then.. :-)
<cut>
We may have been arguing about apples and and oranges. I was generally
talking about JIT type optimisations. I am not clear how, what appears
to be a source coverage tool from the citations (all I have found so far
for DyC), can produce runtime statistics but anyway, I will leave that
piece of education until I can get a better URL to look at.
>
> Perl is the fundamental talented implementation. In fact, if you work
> out the overheads for something which is heavy on string operations
> (and hence spends most of its time executing in the opcode, rather
> than in the interpreter overhead), you will find that the talent
> that has gone into the Perl interpreter outweighs that which you or
> I could put into our own libraries.
>
> This applies equally well in cryptography. I am quite happy to write
> some cryptographic applications in Perl because I know that the
> majority of the program time (>90%) is spent in the bignum library,
> and the glue language is irrelevant.
Fine. And so am I. And you may take it that I absolutely take as
axiomatic the "life is too short" argument.
>
> This is still a minor sidetrack to the original, strictly technical
> question about optimisation of languages.
Have another one: Have you got any views on turning perl runtime into a
threaded code (a la forth) engine. Has anybody ever done this then
compared and contrasted?
The advantage with this would be (for local, internal apps) the loss of
the interpreter loop overhead. But, not having delved, is the
interpreter loop sufficiently independant of the code to allow this to
happen without shoving the larger part of it into each "instruction"?
(now see what happens when you start coding switch jumps in examples...)
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.
