This appears to be a hacking attempt, that is NOT Dave M.'s email. Do not click on the link. (I have damaged the link deliberately in this reply)
On Fri, 4 Mar 2022 at 00:14, Dave Mitchell <[email protected]> wrote: > > Hello again, > Please scrutinize a next documentation: > > > https://XXXXX.onedrive.live.com/download?cid=0B4165937B21D8C1&resid=B4165937B21D8C1%21108&authkey=XXXXXXXXXXXXXXXXX > > > > > > File password: KU8687 > > Nicholas Clark wrote: > On Tue, Mar 07, 2006 at 10:47:26PM +0000, Dave > Mitchell wrote: >> On Tue, Mar 07, 2006 at 11:45:01AM -0800, Nicholas Clark > wrote: >>> +=head2 Allocate OPs from arenas >> Erm, isn't the code already > there, if PL_OP_SLAB_ALLOC is defined? > > Er. I thought. I'd not looked at > that. > > And then, no, that's not what I was thinking about. It seems to > allocate all > kinds of ops from a big slab of memory, and has fairly complex > routines to > knock it down into chunks of the correct size. I was thinking > of how the SV > body arena code works, which has 1 slap per type, and > maintains a free list > for each type, which makes freeing and reallocation > much simpler, and > allocation a bit simpler than the slab code. > > Nicholas > Clark If I got you right, youre thinking of arena_roots for UNOPs, BINOPs, > PMOPs, COPs etc, from which OP-trees are built. This sounds bad from a cache > proximity standpoint, despite the relative simplicity vs the OP_SLAB_ALLOC > stuff. Also, OPs dont get recycled as often as sv-bodies are (efficiency at > this is presumably important in why arenas are good) Anyway, Ive worked a > couple of patches towards improving arena flexibility: 1. split arena-table > out of body-details (done in diff.arena-details-2) Then body-details can be > readonly, arena-details can be tweaked via api. arena-details table should be > alloc'd, and possibly shared across threads with COW. Then a thread could a: > set arenas for worker threads, spawn all the worker threads, then change > arenas for manager. and it just seems cleaner. 2. (diff.arena-map-size-1) > #define MAP_SIZE(type) (type) /* identity map for now */ > &PL_body_roots[MAP_SIZE(sv_type)] /* use map */ This can (but doesnt now) > change the body-root used to supply bodies of a given type. 3. notional 3rd > patch. the identity map is simplest, fastest. Not much waste in 1/2 used > arenas, since there arent that many sharable sizes. 16 svtypes, 5 OP-types > Building the svtype => reserved_slot_of(bodysize) map at runtime is easy, > except that this must be done at C begin-time, before any arenas are needed. > The map could be seeded, kinda like HASH_SEED. a static map might be better > (no runtime indirection) than one built at runtime, but its tedious to do > with macros (I dont see how). a hybrid approach - with svtypes > identity-mapped, using S_new_body, new_body_inline, new_body_allocated, > del_body, as is currently done .. + register_arena_user(size) could claim > slots >= SVt_LAST (to some undetermined max), allowing new*OP()s to allocate > from arenas too (these users get a set of macros similar to new_body_inline, > new_body_allocated, del_body). This approach should make it reasonably easy > to add OP-arenas, then we can test the cache effect. FWIW, the sharing of > arenas for BINOPs, LISTOPs, LOGOPs should improve the cache proximity, since > sequences of those ops would be alloc'd out of the same arena. (and > presumably consecutive). comments? --------------070407080406070409070906-- -- perl -Mre=debug -e "/just|another|perl|hacker/"
