At 9:35 PM -0500 1/3/03, Mitchell N Charity wrote:
That's an interesting idea. I'd originally wanted to yank a lot of stuff out of band and get it in a separate segment of the PMC arena, to make the commonly used parts of PMCs denser, but I'd given up that idea because of the cost of figuring out where the extra bits were held. I'm leaning more and more towards ebbedding a pointer to the extra info into the main PMC body and taking the dereference hit on those occasions when we actually need to get to it from the main PMC body.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.It does seem a lot of time is being spent by free_unused_pobjects walking arrays of PMCs (pool arenas) to twiddle flags. An similar alternative might be to yank the gc flags to the head of their arena. It looks like they might even fit in a short. So an arena has an array of flag ints, and a corresponding array of PMCs. The contiguous flags would speed the walk, and _might_ stick in cache enough that the cache miss cost wouldn't just reappear in random PMC access. One would need a fast way to get from a PMC address to its arena address, eg page aligned arenas.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
