Dan Sugalski wrote:
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 ]
Oh, sorry for misusing your prenome ;)
This test is with a 10% smaller PMC giving 10% increase in speed.
Damn, I was afraid of that. On the one hand I like the speed, on the other... :(
[ differently sized PMCs ]
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.
A little bit more radically:
- a PMC has a PObj and a vtable (= 16 byte)
- if a PMC needs data, metadata or synchronize then
cache.pmc_val points to the "Extra PMC data" (our current PMC ) containing this fields so we do nether resize, but have for aggregates or PMCs with properties one more indirection.
- PerlStrings move from ->data to ->cache.string_val
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.
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.
Not here: current PMC 32 byte, simple PMC 16 byte. BTW tt.c prints these numbers ;-) leo
