On 04/12/02 Dan Sugalski wrote:
> FWIW, the numbers were:
>
> No JIT: Parrot 866 gen/sec Mono 11 gen/sec
> JIT: Parrot 1068 gen/sec Mono 114 gen/sec
Interesting data: was this taken a while ago?
I get different ratios on my machine (PIII 1.1):
Parrot JIT: 850 (though the output is all garbled)
Mono JIT: 113
Still quite a bit slower, though. Our String.cs code is still from the
age when we didn't know C# and didn't know how the CLR worked, basically
the same kind of ugly and slow code as the life.cs sample you posted:-)
Anyway, if really the speed ratio went from 9.3 to 7.5 just waiting a
few weeks, I think we are on the good track, even if the code was not
optimized to run your life benchmark:-) (ok, it may just be that parrot
got slower, who knows...)
> In this case, it is apples to apples under the hood--concatenation in
> Parrot currently generates new strings as well. The only place (at
> the moment) we don't do immutable strings is for chomp.
Interesting. Currently our string methods are all done in C# code,
but the spec basically requires us to do most of it in C, so I guess
the ratio will change quite a bit when we do that even without an
optimizing JIT (plus, it will save us two memory allocations per
string object).
> On the other hand, there's a very strong "Who cares?" argument.
> (Targeted directly at the CLR design, not at Mono) If the design of
> the CLR requires certain operations to be really slow, well...
> they're going to be slow, and code that uses it will be stuck with
> lousy speeds. It *is* apples to apples comparison of speeds, since
> we're both doing concatenation. That you're potentially saddled with
> a slow design isn't my fault. :)
See above: if strings are immutable, concatenation is not the same thing
as when they are buffers, so, in real world code, you don't use a string
if you need a buffer in C# code. A part from the current known System.String
slowness, nobody would write C# code like in life.cs (well, specially
not for use in benchmarks:-), so I don't consider it a design issue.
Of course, it's a problem if perl programmers start translating the perl
code to C# changing every scalar to a System.String ;-)
But, as we learn to avoid some code patterns in perl code because they
slow down, the same thing I hope will happen to C# programmers,
specially if they see the same kind of improvements in speed as
applying to life.cs the suggestions in my first mail:
$ mono life2.exe
500 generations in 67 milliseconds, 7434 gen/sec.
RESULT: 0
I guess parrot can see about the same speed difference if you use an
array instead of the strings. _That_ is a design issue with perl, for
example, where if you just want an array of ints, you have to pay for
the whole scalar thing for each element, you can't escape it.
I don't consider it a design issue if the _developer_ writes slow code
(though the language should make it easy to write the fast code).
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
