develooper Front page | perl.perl5.porters | Postings from November 2014

Re: Do pad name string buffers need to be pointer-aligned?

Thread Previous | Thread Next
Father Chrysostomos
November 30, 2014 19:53
Re: Do pad name string buffers need to be pointer-aligned?
Message ID:
Aaron Crane wrote:
> Father Chrysostomos <> wrote:
> > I could fiddle things a bit to get the string buffer to begin at
> > xpadn_flags+1.  That would get us down to 6 pointers for four-char
> > names like $self
> >
> > A couple of years ago someone pointed out that memcmp is faster at
> > pointer-aligned addresses.  But how much faster?  Is it noticeable?
> My apologies for not replying to this sooner.
> I see that your current smoke-me/pn branch contains code for both
> options, selectable at compile time, and finds the low-memory version
> slightly faster than the version that pointer-aligns the buffers. My
> understanding is that, although memcmp() is faster for pointer-aligned
> arguments on at least some platforms, it's hard for that advantage to
> kick in for short buffers, since most of the cost is in loading the
> relevant cache lines. Since many (most?) pad names are less than a
> dozen or so bytes long, I don't find it terribly surprising that
> saving memory is a slight win over pointer-aligning the buffers.

Thank you.

> That said, it would be interesting to use DaveM's new cachegrind-based
> Porting/ to compare Perls compiled with PERL_PADNAME_MINIMAL
> and PERL_PADNAME_ALIGNED, on code using lexical variables with names
> of a variety of lengths.
> One other note on smoke-me/pn: there seems to be a missing line in the
> commit message for 549200d "Minimise the size of padname + string
> buffer" -- perhaps the line began "#if" and was therefore swallowed by
> "git commit"?

Yes, it often bites me.  I wish I could disable that feature

I have merged the pad name stuff in commit d48603664.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About