Re: Question on alignment

From: Antonin Houska <ah(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question on alignment
Date: 2019-04-05 15:25:51
Message-ID: 13579.1554477951@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Antonin Houska <ah(at)cybertec(dot)at> writes:
> > Antonin Houska <ah(at)cybertec(dot)at> wrote:
> >> Since palloc() only ensures MAXIMUM_ALIGNOF, that wouldn't help here anyway.
>
> > After some more search I'm not sure about that. The following comment
> > indicates that MAXALIGN helps too:
>
> Well, there is more than one thing going on here, and more than one
> level of potential optimization. On just about any hardware I know,
> misalignment below the machine's natural word width is going to cost
> cycles in memcpy (or whatever equivalent the kernel is using). Intel
> CPUs tend to throw many many transistors at minimizing such costs, but
> that still doesn't make it zero. On some hardware, you can get further
> speedups with alignment to a bigger-than-word-width boundary, allowing
> memcpy to use specialized instructions (SSE2 stuff on Intel, IIRC).
> But there's a point of diminishing returns there, plus it takes extra
> work and more wasted space to arrange for anything to have extra
> alignment.

Thanks for this summary.

> So we generally only bother with ALIGNOF_BUFFER for shared buffers.

ok, I'll consider this a (reasonable) convention.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robbie Harwood 2019-04-05 15:31:25 Re: [PATCH v20] GSSAPI encryption support
Previous Message Antonin Houska 2019-04-05 15:22:42 Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3