At 10:47 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/06/01 Dan Sugalski wrote:
> > Then I'm impressed. I expect you've done some things that I haven't yet.
>
>The only optimizations that interpreter had, were computed goto and
>allocating the eval stack with alloca() instead of malloc().
Doesn't this really get in the way of threading? You'll chew up great gobs
of system stack, and that's a scarce resource when running with threads.
>Of course, now it's slower, because I implemented the full semantics required
>by IL code (the biggest slowdown came from having to consider
>argments and local vars of any arbitrary size; making the alu opcodes
>work for any data type slowed it down by 10 % only): but the parrot
>interpreter doesn't need to deal with that kind of stuff that slows
>down interpretation big time. Still, it's about 2x faster than perl5
>on the same benchmarks, though I haven't tried to optimize the new code, yet.
Well, we should have code ready for checkout on Monday--I'm really
interested to see what our respective speeds are with low-level operations.
> > Also, while I have numbers for Parrot, I do *not* have comparable numbers
> > for Perl 5, since there isn't any equivalence there. By next week we'll
> > have a basic interpreter you can build so we can see how it stacks up
> > against Mono.
>
>See above, I expect it to be faster, at least handling the low-level stuff
>since I hope you're not going to add int8, uint8 etc, type handling.
Gack, no. Ints are native sized. If people want shorter ints, they can use
full-blown variables.
> > >Yep, but for many things there is an overlap. As for the dynamic language
> > >issue, I'd like the ActiveState people that worked on perl <-> .net
> > >integration to share their knowledge on the issues involved.
> >
> > That one was easy. They embedded a perl interpreter into the .NET
> execution
> > engine as foreign code and passed any perl to be executed straight to the
> > perl interpreter.
>
>I think they worked also on outputting IL bytecode...
Yep, but that version was slower. Dick Hardt snagged me at TPC this year (I
think I spent most of my non-speaking time being pinned to a table or bench
by folks with Things To Say... :) and made a .NET pitch. They were going
with the translation to .net but switched to embedding perl. It was a lot
faster. (Brad Kuhn had a paper on translating perl to java bytecode and he
had lots of trouble, but for different reasons)
> > completely counter to what .NET (and java, for that matter) wants to do.
> > Including runtime compilation from source and runtime redefinition of
> > functions. (Not to mention things like per-object runtime changeable
> > multimethod dispatch, which just makes my head hurt)
>
>Naah, with the reflection support you can create types and methods on the
>fly, the rest can probably be done with a couple of ad-hoc opcodes.
Maybe. It'd be nice if that's true, though spitting out to .Net's a
secondary issue for me--a working interpreter's first. Once we get the
interpreter fast is when we (well, someone at least--probably not me) work
on emitting .net or jvm code instead of perl bytecode.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
