On 09/06/01 Dan Sugalski wrote:
> >The original mono interpreter (that didn't implement all the semantics
> >required by IL code that slow down interpretation) ran about 4 times
> >faster than perl/python on benchmarks dominated by branches, function
> >calls,
> >integer ops or fp ops.
>
> Right, but mono's not an interpreter, unless I'm misunderstanding. It's a
> version of .NET, so it compiles its code before executing. And the IL it
> compiles is darned close to x86 assembly, so the conversion's close to
> trivial.
Nope, if we had written a runtime, library, compiler and JIT engine in two
months we'd be all on vacation now ;-)
The figures are actually for a stack-based interpreter that executes IL opcodes,
no assembly whatsoever. And, no, IL is not close to x86 assembly:-)
I don't expect a new perl to run that fast, but there is a lot of room for
improvement.
> >Java is way faster than perl currently in many tasks:
>
> Only when JITed. In which case you're comparing apples to oranges. A better
> comparison is against Java without JIT. (Yes, I know, Java *has* a JIT, but
> for reasonable numbers at a technical level (and yes, I also realize that
> generally speaking most folks don't care about that--they just want to know
> which runs faster) you need to compare like things)
It's not so much that java *has* a JIT, but that it *can* have it. My point is,
take it into consideration when designing parrot. There's no need to
code it right from the start, that would be wrong, but allow for it in the design.
> >it will be difficult
> >to beat it starting from a dynamic langauge like perl, we'll all pay
> >the price to have a useful language like perl.
>
> Unfortunately (and you made reference to this in an older mail I haven't
> answered yet) dynamic languages don't lend themselves to on-the-fly
> compilation quite the way that static languages do. Heck, they don't tend
> to lend themselves to compilation (certainly not optimization, and don't
> get me started) period as much as static languages. That's OK, it just
> means our technical challenges are similar to but not the same as for
> Java/C/C++/C#/Whatever.
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.
> >The speed of the above loop depends a lot on the actual implementation
> >(the need to do a function call in the current parrot code whould blow
> >away any advantage gained skipping stack updates, for example).
>
> A stack interpreter would still have the function calls. If we were
> compiling to machine code, we'd skip the function calls for both.
Nope, take the hint: inline the code in a big switch and voila', no
function call ;-)
> numbers. (This is sounding familiar--at TPC Miguel tried to convince me
> that .Net was the best back-end architecture to generate bytecode for)
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.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
