Dan Sugalski [EMAIL PROTECTED] wrote:
The current calling scheme stands.
[ ... ]
No more performance changes. Period. We get parrot fully functional first.
Ok. As long as PIR code is concerned call internals are nicely hidden by
the function call and return syntax. But PASM could be a
At 9:38 AM +0100 11/6/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
The current calling scheme stands.
[ ... ]
No more performance changes. Period. We get parrot fully functional first.
Ok. As long as PIR code is concerned call internals are nicely hidden by
the function call
Below (inline/attached) is a longish analysis of fib benchmark timings.
leo
Why is the fib benchmark still slow - part 1
Python runs the fib test roughly twice as fast as Parrot. I don't
like that ;) So what's the problem?
1) CPU cache issues
First, if you like to investigate the issue yourself
Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
Or it would make sense to use multi-frame register chunks. I kept
locality of access in mind but somehow never spelled it out. But I
*think* I mentioned 64kb as a good chunk size
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
We have to address both areas to get rid of the majority of cache
misses.
ad a)
For each level of recursion, we are allocating a new context structure
and a new register frame. Half of these is coming from the
Leopold Toetsch wrote:
I believe that you shouldn't litter (i.e. create an immediately
GCable object) on each function call - at least not without
generational collector specifically optimised to work with this.
The problem isn't the object creation per se, but the sweep through
the *whole
Miroslav Silovic [EMAIL PROTECTED] wrote:
The problem with copying GC is that pointers can change under your feet
at every opportunity.
Basically yes. We have that problem currently with the copying
collection of strings. Normally this is solved by keeping the old object
in place, so that
Miroslav Silovic [EMAIL PROTECTED] writes:
Leopold Toetsch wrote:
I believe that you shouldn't litter (i.e. create an immediately
GCable object) on each function call - at least not without
generational collector specifically optimised to work with this.
The problem isn't the object
At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
The cache misses are basically in two places
a) accessing a new register frame and context
b) during DOD/GC
b) is relatively easy -- I'd bet that the vast majority of the cache
misses are because of the copying collector. That could be cleared up
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
The cache misses are basically in two places
a) accessing a new register frame and context
b) during DOD/GC
b) is relatively easy -- I'd bet that the vast majority of the cache
misses are because of the
Piers Cawley [EMAIL PROTECTED] wrote:
The catch with generation GC is that, once you have guaranteed
destructors being called promptly, you still have to sweep the whole
arena every time you leave a scope.
Yes. I hope that we can track objects needing timely destruction
directly. We have
Dan Sugalski [EMAIL PROTECTED] wrote:
[ Yet another f'up ]
..., except that it caches the top
half of the register sets
[ ... ]
copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
optimization with zig opcodes to address the
At 9:34 PM +0100 11/5/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
[ Yet another f'up ]
..., except that it caches the top
half of the register sets
[ ... ]
copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
13 matches
Mail list logo
