At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote:
You've a *long* way to go to get that title. (It's mine, and you can't have it! :)Leopold Toetsch wrote:[ this is Mr. f'up myself again ]
Damn, I was afraid of that. On the one hand I like the speed, on the other... :(By reducing the amount of DOD runs I now have:$ time parrot -j stress.pbc real 0m0.849s
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real 0m0.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
real 0m0.635s
This test is with a 10% smaller PMC giving 10% increase in speed. This seems to indicate again the necessity for a smaller Scalar PMC as already proposed in the thread
"[CVS ci] mark5 - PMC/Buffer unification #10".
Having only 50% size for a "plain" scalar could inidicate 50% speed increase for such programs with many live PMCs.
The problem is, we can't promote a smaller PMC to a bigger one. But what about this strategy: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 sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section.
- scalars start with a small PMC (16 bytes on a 32 bit machine)
except when the HL indicates, that the var needs properties or may be
be shared between threads
- 99% of all scalars will probably nether be used differently
- when such a small scalar gets runtime properties added then:
- make a new "big" PMC and point the old PMC to the newly created one.
This should work like an unvisible reference, doing all functions on
behalf of the scalar.
- in the next DOD run, when we find such a PMC pointer, replace it with
the real PMC. As this might need a modified pobject_lives function
(digging in all places to find all occurencies) this could be a
separate step too, run only when needed.
It ultimately increases the size of a PMC by one pointer if we preallocate all the property/sync pairs, but it makes the PMC itself more dense and, if I'm calculating things right, makes it fit on an 8-byte boundary better.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
