Steve Fink wrote:
On Jan-09, Leopold Toetsch wrote:So the question is, should I checked it in / partially / forget it.
Changes are:
- SPMC (small or scalar PMC) with half the size of a PMC, no promotion or whatever to a PMC, disabled with one define in pmc.c
- pool flags with aligned pools, disabled in pobj.h
- key.c and list.c flags cleanup
- mark constant PMCs in DOD[1], hash undef PMC changes
- minor cleanups
My personal opinion, worth the paper it's printed on: all of those
sound very good except for the first, which makes me nervous.
key, list and some cleanup is in.
... It adds
a lot of complexity if those PMCs ever need to be promoted, and I'm
not clear on the advantages. The space advantage is obvious, but I
would guess not all that large.
Space advantage is 50% which goes almost directly with same speed advantage.
Promoting wouldn't be too hard, IMHO, when vtable changes and references are in. We make the original PMC a reference to the bigger promoted type, should work as references work on behalf of the referenced object.
... I don't understand the cache advantage
-- is it perhaps doubling the usable size of the cache because the
larger PMCs are all aligned similarly, and so half the cache is never
used? If so, would staggering the alignment of the PMCs be enough to
get the same gain (possibly with reordering the fields)?
You get double the amount of PMCs into the cache - used during marking and freeing. It isn't related to alignment, just more throughput.
... Have
you tried running cachegrind or something similar on the two versions?
No, only stress*.pasm. But: $ 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 $ time parrot -j stress.pbc # half sized (16 byte PMC) $ make -s && time parrot -j stress.pbc A total of 13 DOD runs were made real 0m0.378s leo
