OO benchmarks
Leopold Toetsch
Results don't look really good.
- Parrot consumes ever increasing memory, so it can't even run up to 100000
- its slow (unoptimized build for now - but that doesn't matter yet)
- Parrot is leaking a vtable per new class and worse per new instance
- I'm currently trying to avoid the vtable_clone for new objects with
some success - I still have some test errors related to can or type.
Are these 2 programs somehow equivalent?
leo
$ cat o1.pl
#! perl -w
use strict;
for my $i (1 .. 100000) {
my $o = new Foo();
}
my $o = new Foo();
print $o->[0], "\n";
package Foo;
sub new {
my $self = ref $_[0] ? ref shift : shift;
return bless [ 10, 20 ], $self;
}
1;
$ cat o1.pasm
newclass P1, "Foo"
find_global P2, "init"
store_global "Foo", "__init", P2
addattribute P1, ".i"
addattribute P1, ".j"
set I10, 0
set I11, 20000
loop:
find_type I1, "Foo"
new P3, I1
inc I10
#sleep 0.0001
lt I10, I11, loop
find_type I1, "Foo"
new P3, I1
classoffset I0, P3, "Foo"
getattribute P2, P3, I0
print P2
print "\n"
end
.pcc_sub init:
classoffset I0, P2, "Foo"
new P10, .PerlInt
set P10, 10
setattribute P2, I0, P10
inc I0
new P10, .PerlInt
set P10, 20
setattribute P2, I0, P10
invoke P1
Dan Sugalski
>I've run these 2 tests below.
>
>Results don't look really good.
>- Parrot consumes ever increasing memory, so it can't even run up to 100000
>- its slow (unoptimized build for now - but that doesn't matter yet)
>- Parrot is leaking a vtable per new class and worse per new instance
>- I'm currently trying to avoid the vtable_clone for new objects
>with some success - I still have some test errors related to can or
>type.
Damn. Okay, I'm going to spend today digging into the object stuff to
try and track down the leaks. Something's not right in there, as the
DOD and GC ought to be reclaiming the dead memory.
>Are these 2 programs somehow equivalent?
Yeah, they're about the same, though the class lookup is cached so it
shouldn't have to be done every time through.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: Damn. Okay, I'm going to spend today digging into the object stuff to
: DOD and GC ought to be reclaiming the dead memory.
Can I hit you with a cream pie at OSCON if Perl 5 runs faster than Parrot?
:-)
Larry
Leopold Toetsch
> - its slow (unoptimized build for now - but that doesn't matter yet)
Some more remarks to that.
- Python is around at double the speed of perl here
- Parrot seems to take too much time in delegate.pmc:
- register preserving
- method lookup
- reentering run-loop
Creating 100.000 new objects on a P600:
PerlInt 0.15 s
delegate 1.6
delegate, __init 2.9
The last one calls an empty __init sub and returns
leo
Leopold Toetsch
> At 3:36 PM +0100 3/4/04, Leopold Toetsch wrote:
>
>> I've run these 2 tests below.
>>
>> Results don't look really good.
> Damn. Okay, I'm going to spend today digging into the object stuff to
> try and track down the leaks. Something's not right in there, as the DOD
> and GC ought to be reclaiming the dead memory.
I've a patch now (attached) - runs all tests. Please have a look at it.
- GC was blocked during list.c:allocate_chunk(). I've removed that -
it's very likely unneeded and wrong
- Parrot_new_class -> class_register allocates now a ParrotObject vtable
- with this the cloning during instantiation isn't needed anymore
- so the huge memory leak (~100 MB) for loop count 100.000 is gone
- not cloing the vtable saves about 10% execution time
>
>> Are these 2 programs somehow equivalent?
>
>
> Yeah, they're about the same, though the class lookup is cached so it
> shouldn't have to be done every time through.
Good, makes it faster ;)
leo
Dan Sugalski
Only if I can return the favor if it goes the other way. :-P
Dan Sugalski
Well, I just committed a change to the system that should speed up
object creation a bunch, as it doesn't need to allocate a vtable for
each object any more.
Still not great, but better.
Leopold Toetsch
> Well, I just committed a change to the system that should speed up
> object creation a bunch, as it doesn't need to allocate a vtable for
> each object any more.
Please cvs update and have a look at benchmarks/oo*. I'v speeded object
creation up by a factor of 3 - after your patch.
leo