On Jan-09, Leopold Toetsch wrote: > I have here now ~15 files different to CVS, which I would like to sync > in either direction for easier future changes. > 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 > > The first two are pretty much encapsulated and disabled by default. They > can be easily removed at any time. SPMCs could get really functional > after vtable var/value changes.
My personal opinion, worth the paper it's printed on: all of those sound very good except for the first, which makes me nervous. 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. 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)? For example, make every other PMC allocated fall on a different alignment. I haven't been paying much attention recently, so I'm probably just being naive and dumb, but my intuition is concerned about adding this complexity when we're not totally confident of what's going on. Have you tried running cachegrind or something similar on the two versions?
