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
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 |