develooper Front page | perl.perl5.porters | Postings from August 2010

Re: MG slabs?

Thread Previous
From:
Nicholas Clark
Date:
August 2, 2010 05:33
Subject:
Re: MG slabs?
Message ID:
20100802123321.GP48531@plum.flirble.org
On Sun, Jul 18, 2010 at 10:47:50PM +0100, Dave Mitchell wrote:

> Now then, magic is currently attached to SVs using linked lists, and magic
> is attached to lots of SVs for lots of trivial reasons: taint, pos, etc.
> So a lot of processing of SVs involves lots of running through the MG
> linked list, eg
> 
>     $ grep mg_find *.c | wc -l
>     87
> 
> Which may be slow (although I haven't instrumented this with cachegrind or
> anything yet).

I think that that's the key part - instrument how much this actually hurts.
Or do the magic chains get cached adequately by the CPU.

> So... maybe SvMAGIC should point to a singe array (in the C sense, not the
> AV sense) of MG structures. If we need to add more magic, we realloc the
> array.
> 
> Even more radically, given that mg_type is only 8 bits, we could split the
> MG array into two halves - an array of types, and an array of everything
> else. Then an mg_find() or similar would be sooper fast.
> 
> I have no immediate plans to look into this further.

I had also idly wondered a year or two ago (without instrumenting), whether
the speed hit was often "is there even this magic present?" and hence whether
it would be a speedup to use 32 bytes as a bitmap for each of the 256 possible
magic types.

On Mon, Jul 19, 2010 at 01:06:08AM +0300, Yuval Kogman wrote:
> This might break code that uses sv_magicext with multiple MGs of the
> same mg_type (mg_find is meaningless for these anyway).
> 
> If the linked list pointers are preserved but the memory layout is
> improved in sv_magic without breaking sv_magicext, I think that should
> be fine though.
> 
> If sv_magic special cases a few commonly used mg_types to allocate a
> table of MG entries and just makes sure they point at each other
> sensibly, locality of reference can be achieved without changing the
> linked list structure.

Something like using arenas to allocate magic bodies?

> An mg_type based table could also be added, but not as the actual
> storage mechanism, instead it would just be an index pointing at
> linked list entries.

The trade off on all of these is that they break compatibility with the current
way of doing things, which has been consistent since 5.000. I'm not sure how
much code out there "knows" that it can allocate magic structures with
malloc() and then attach them to the list, but I believe that SWIG certainly
does.

On Mon, Jul 19, 2010 at 01:01:55AM +0200, Leon Timmermans wrote:

> How often do SVs really have more than one kind of magic? How much can
> that be reduced by making taint a flag instead of a kind of magic?
> Would this really be worth the effort?

I'm not convinced that it would be worth the effort.
Right now, the implementation of taint with magic is effectively quite robust
and fail-safe - whenever a tainted value is read (however nested), then any
values written during that statement's execution will be marked tainted
(however nested). As long as the reading code honours the "call get magic"
expectation, taint will work. Whereas changing things, presumably so that all
the sv_2[ipnu]v_* functions read a "taint flag bit" instead of magic means that
any other code reading values *also* needs to be changed, or taint will silent
by lost along those code paths.

On Mon, Jul 19, 2010 at 01:03:05AM +0200, Vincent Pit wrote:
> 
> >Now then, magic is currently attached to SVs using linked lists, and magic
> >is attached to lots of SVs for lots of trivial reasons: taint, pos, etc.
> >   
> At some time, there was the idea of reimplementing taintedness as a sv 
> flag floating into the air. But nobody dared to try it.
> 
> Otherwise, the idea is interesting, even if I don't know if magic is 
> used that enough to be really a hot spot to optimize. That is, besides 
> tainting and tieing.

Yes, that's generally my view. It feels sufficiently unlikely that I've not
even tried benchmarking it to what proportion of time is currently consumed
within the magic code, and so what the absolute best-case speedup might be.

Nicholas Clark

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About