Dan Sugalski wrote:
At 1:30 PM +0100 1/6/03, Leopold Toetsch wrote:
1) for linear access half sized PMCs give double mark speed. This is in good relation to stress.pasm
... A region of the PMC pool that's entirely mark area would up the cache density by a factor of three or four.
s/three of four/32/ for current PMC. next_for_gc is not really used that often IMHO, that it should go in the same place.
Marking current PObj headers needs these flags:
live, on_free_list, is_PMC, is_PMC_ptr, is_Buffer_ptr, active_destroy (and ev. is_SPMC i.e. scalar or small PMC). This would fit fine in one byte. Only when we have a more complicated structure (with data, properties, whatever) then we need next_for_gc.
... The worst case behaviour will be total random access to our pools data.
This is a very good point. It might be worth having an "allocate X PMCs into buffer Y" call that could potentially let us do more optimization here, since if we're allocating a full pool's worth of PMCs it may be more prudent to just allocate a full new pool and stuff them all into the single array.
Yes. But will a HL be able to emit such a call? This would need thorough loop analysis or some help of the HL user to declare e.g. array size in advance, which is rather unperlish for example. But OTOH the doc could state, if you know you'll need a really big array, then say so to perl6, you'll get more speed then.
... we might need a free_list per pool->arena, which would need a pool->arena pointer in the PMC.
We could avoid this with properly aligned PMC pools, if we don't mind playing pointer masking games. Whether this would be faster is an open question, though.
Aligned PMC pools don't help for above case of longrunning programs, when newly created PMCs do come from different pool->arena areas, they will be scattered all over the whole allocated regions.
The idea above is to have a free_list per header_pool->arena, which would keep items tighter together then our free_list per header pool does.
Or: At some point it would be cheaper to forget freed PMCs and allocate fresh new pools, cache-friendly and tightly put together.
4) With a pool->arena pointer in the PMC, we could also try to use a spearate flags field, which could be 1 byte per PMC sized.
I don't think a single byte's enough for PMC flags, though it could be for internal use. (Heck, two bits may be enough, in which case it may be worth having a separate mark bitstring for live/dead marks)
S. above and pobject_lives() in dod.c. We need 1 byte per header for marking. Not for all PObj flags, these will still exist.
The bit arithmetic will be faster for big programs ("big" will be defined later ;-)
5) On my system pools of different sizes are in totally different ranges of memory (sbrk vs. mmap). This makes the quick bit mask test in trace_mem_block totally unusable.
Yeah, but I'm not sure that is a problem as such--we're going to have to deal with multiple memory blocks anyway, so...
Or skip this alltogether ;-) leo
