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().
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.
> 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.
> >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...
> >I know the ActivState people did work on this area. Too bad their stuff
> >is not accessible on Linux (some msi file format stuff).
> >I don't know if .net is the best back-end arch, it's certanly going
> >to be a common runtime to target since it's going to be fast and
> >support GC, reflection etc. With time and the input from the dynamic
> >language
> >people may become a compelling platform to run perl/python on.
>
> Doubt it. That'd require Microsoft's involvement, and I don't see that
> happening. Heck, most of what makes dynamic languages really useful is
The ECMA people are not (only) m$, there is people in the committee
interested in both other implementations and input on the specs.
> 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.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
