Hi list,
I released a few days ago the Neko intermediate language at
http://nekovm.org . In the FAQ I'm comparing Neko to LLVM / C-- and Parrot.
According to a mail sent to me by Leopold Toetsch I got some points wrong
when trying to generalize theses three frameworks in the same category,
which o
Hi list,
I tried to have a deeper look at Parrot so I installed latest PXPerl with
Parrot 0.2.3 and I tried to run some benchmarks on my computer in order to
compare with Neko.
I was thinking that Parrot JIT would outperform Neko VM easily but I got
theses results :
fib(35) Neko : 8 seconds
fib(
> > Or am I missing something about the way Parrot is handling integer
> > values ?
>
> fib is one of the few benchmarks that currently performs very badly due
> to huge function call overhead (mainly L2 cache misses). I'm currently
> working on a different call scheme, which eventually gets rid of
Hi list,
Yesterday I did a quick fib(30) benchmark comparing Parrot Win32 daily
build (using jit core) and NekoVM (http://nekovm.org). The results are
showing that Parrot is 5 times slower than Neko (see my blog post on
this point there : http://ncannasse.free.fr/?p=66).
I would like to unde
>
> On Feb 28, 2006, at 12:09, Nicolas Cannasse wrote:
>
>> Yesterday I did a quick fib(30) benchmark comparing Parrot Win32 daily
>> build (using jit core) and NekoVM (http://nekovm.org). The results are
>> showing that Parrot is 5 times slower than Neko (see my blog
> $ time ./parrot -j fib.pir 30
> Fib(30): 1346269
>
> real0m4.774s
>
> Ok that's slow (AMD [EMAIL PROTECTED], unoptimized parrot build), you are
> right. But:
>
> $ time ./parrot -Cj fib.pir 30
> Fib(30): 1346269
-Cj does not produce different results than -j on the Win32 build of
Parrot.
