At 11:46 AM -0800 2/4/02, Hong Zhang wrote:
> > mops tests :
>>
>> on perl5,python I get - 2.38 M/ops
>> ruby ~ 1.9 M/ops
>> ps ~ 1.5 M/ops
>>
>> parrot - 20.8 M/s
>> parrot jitted - 341 M/ops and it finish in half second ... for most of
>> the other I have to wait more that a minute ..
>
>Frankly speaking, this number is misleading. I know the python and ruby
>interpreter. They count "a + b" as 3 mops, load a, load b, and add top
>two values of stack. The a and b can be any type, so type check, coersion,
>vtable dispatch overhead are necessary. It is equivalent to add to PMCs
>and produce a third PMC. The Parrot op does not map directly to language
>constructs, it is more like Java virtual machine, where operand types
>are known. Some time, compiler can compile code directly into Parrot
>opcode, when the type information is avaible. Most of time, we have to
>use generic PMC and vtable. The difference between Perl 5 opcode and
>Perl 6 opcode + vtable would be much smaller.
Yup. With PMCs, the Parrot number drops in half. Still a nice boost.
:) Our opcode counting may be a little dodgy on other platforms, and
we need to check that to make sure the numbers match. mops.pasm is
really supposed to be a measure of opcode dispatch time as much as
anything else, and it's a bit dodgy there.
I'd like to get life.pasm working with PMCs and use that as a
cross-language benchmark when we're done getting it functioning. It
does more, and is more representative of at least one class of
processing. (Big numbers being nice for bragging, but I'd as soon
have accurate numbers for performance comparisons)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
