Re: BUG #15923: Prepared statements take way too much memory.

At Mon, 29 Jul 2019 18:11:04 +1200, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in <CA+hUKGLfa6ANa0vs7Lf0op0XBH05HE8SyX8NFhDyT7k2CHYLXw(at)mail(dot)gmail(dot)com>
> On Sun, Jul 28, 2019 at 11:14 PM Daniel Migowski <dmigowski(at)ikoffice(dot)de> wrote:
> > * Why are MemoryContextAllocZeroAligned and MemoryContextAllocZero the same function?
>
> It's not really relevant to the discussion about memory usage, but since
> you asked about MemoryContextAllocZeroAligned:
>
> I noticed that stuff a while back when another project I follow was
> tweaking related stuff. The idea behind those functions is that we
> have our own specialised memset()-like macros.
> MemoryContextAllocZeroAligned() uses MemSetLoop(), while
> MemoryContextAllocZero() uses MemSetAligned(). Those date back nearly
> two decades and were apparently based on experiments done at the time.
> The comments talk about avoiding function call overhead and
> specialising for constant lengths, so I suppose we assumed that
> compilers at the time didn't automatically know how to inline plain
> old memset() calls.
>
> These days, you'd think you could add "assume aligned" attributes to
> all memory-allocation-like functions and then change a few key things
> to be static inline so that the constants can be seen in the right
> places, and get all of the same benefits (and probably more) for free
> from the compiler's alignment analysis and inlining powers.
>
> As for what benefits might actually be available, for constants it's
> clear but for alignment, I'm doubtful. When Clang 8 on amd64 inlines
> a memset() with a known aligned destination (for various alignment
> sizes) and constant size, it generates a bunch of movups instructions,
> or with -march set to a modern arch, maybe vmovups, and some
> variations depending on size. Note 'u' (unaligned) instructions, not
> 'a' (aligned): that is, it doesn't even care that I said it the
> destination was aligned! I found claims from a couple of Intel
> sources that this sort of thing stopped making any difference to
> performance in the Nehalem microarchitecture (2008). It still matters
> whether the data actually is aligned, but not whether you use the
> instructions that tolerate misalignment, so there is apparently no
> point in generating different code, and therefore, as far as memset()
> goes, apparently no gain from annotating allocation functions as
> returning aligned pointers. As for other architectures or compilers,
> I don't know.
>
> For curiosity, here's an experimental patch that gets rid of the
> MemSetXXX() stuff, adds some (useless?) annotations about alignment
> and makes palloc0() and MemoryContextAllocZero() inline so that they
> can benefit from inlining with a visible constant size in eg
> newNode(). It didn't seem to do anything very interesting apart from
> remove a few hundred lines of code, so I didn't get around to digging
> further or sharing it earlier. Or maybe I was just doing it wrong.
> (In this patch it's using sizeof(long) which isn't enough to be
> considered aligned for the wider move instructions, but I tried
> various sizes when trying to trigger different codegen, without
> success).

FWIW, I saw gcc/x64 -O2 emit "rep stosq" for memset() having
constant length and "not-aligned" pointer are passed. Of course
aligned(8) didn't make difference at all. Emitted a seris of
movex for smaller chunks. And always emitted "call memset" for
non-constant length.

That makes me think that the "aligned" attribute works some
different way. Anyway I haven't find any further explantion about
the hint than "compiler considers alignment on the
varialbe/type/function"...

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center