Re: Change 27406: Two more TODOs for those with C knowledge.

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 <yc5h0na@prodimension.ro> 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/"

• Re: Change 27406: Two more TODOs for those with C knowledge. by demerphq