I'm not willing to go so radically to start, but I did have an idea.
I think part of the extra cost is just in cache fluffiness--the sync
info just isn't being used much. I don't think that it, or the
property info, will be used most of the time. We could yank the
metadata and sy
Leopold Toetsch wrote:
Leopold Toetsch wrote:
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pmc->synchronize (-10% size)
A total of 9 DOD runs were made
real0m0.635s
$ time parrot -j stress.pbc
Dan Sugalski wrote:
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
- No stackwalk,
I think we're always going to have to walk the stack, no matter how much
I'd rather not. It's an expensive walk too, alas.
This depends on. I think a mixed strategy of:
- code reordering (e.g. $1=pmc_new
Dan Sugalski wrote:
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
As programs tend to have much more scalars then aggregates and
probably more scalars w/o properties then with, this would win a lot
of precious cache mem.
Fair enough, though there's something just so bizarre about havin
At 9:35 PM -0500 1/3/03, Mitchell N Charity wrote:
I'm not willing to go so radically to start, but I did have an idea.
I think part of the extra cost is just in cache fluffiness--the sync
info just isn't being used much. I don't think that it, or the
property info, will be used most o
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
Ok. Here ist the rest.
- No stackwalk, as already sent by separate #19668, which is included
if this is a problem for $architecture, please enable
trace_system_areas in dod.c again - feedback still welcome
I think we're always going to have to
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm not willing to go so radically to start, but I did have an
idea. I think part of the extra cost is just in cache
fluffiness--the sync info just isn't being used much. I don't think
that it, or the property info, will be u
Dan Sugalski wrote:
At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote:
1) parrot compiled -O3 (classes/Makefile is br0ken, doesn't get CFLAGS
from Configure) - but unoptimized is still faster then perl5 :-)
Odd. Not on my system. Might be a x86/PPC issue.
I must have overlooked -O3 in clas
Dan Sugalski wrote:
At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote:
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
You've a *long* way to go to get that title. (It's mine, and you can't
have it! :)
Oh, sorry for misusing your prenome ;)
This test is with a 10% smaller PMC giv
At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote:
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
You've a *long* way to go to get that title. (It's mine, and you
can't have it! :)
$ time parrot -j stress.pbc
real0m0.849s
By reducing the amount of DOD runs I now have:
$ time pa
At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
1)
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
$ time parrot -j stress.pbc
real0m0.849s
By reducing the amount of DOD runs I now have:
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pm
Leopold Toetsch wrote:
[ another f'up myself ]
stress2 results:
$ time perl examples/benchmarks/stress2.pl
real0m2.430s
user0m2.410s
sys 0m0.020s
$ time parrot stress2.pbc
real0m1.854s
user0m1.710s
sys 0m0.140s
$ time parrot -j stress2.pbc
real0m1.460s
user0m
Leopold Toetsch wrote:
$ time parrot stress.pbc
real0m0.508s
Sorry, due to some lack of coffee, I ran a version, where DOD was
blocked in buildarray.
Here are updated numbers:
$ time perl examples/benchmarks/stress.pl
real0m0.786s
user0m0.590s
sys 0m0.200s
$ time parrot -
Dan Sugalski wrote:
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
1) parrot compiled -O3 (classes/Makefile is br0ken,
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
Your are sure, that you didn't start swapping?
Oh, absolutely. One of th
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower, which
is a Bad Thing.
Your are sure, that you didn't start swapping?
I have here this test pushing X integers into a PerlArray, then clone
it,
I've been playing with a few test programs, and I'm finding it
depressingly easy to get perl 5 to beat the pants off of Parrot for
runtime speed, often by a factor of 4, regularly by a factor of two.
There are a number of trouble spots that we can address now, without
affecting anything else th
18 matches
Mail list logo
