[fpc-devel] CMem allocator memory alignment experiment

[Marco van de Voort]

In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > > At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
> > > 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
> > > to 4 bytes and 8 bytes, respectively.
> >
> > Since cmem is intended for use by FPC, I don't see this as a serious issue
> > unless somebody is exchanging malloc()ed blocks between Pascal and C code.
> 
> Since the RTL's allocator is documented to align to 16 bytes, it's
> definitely an issue also with Pascal code. We do have code where also
> Pascal side triggers the aligment issue, but indeed, the main issue is
> with linked C libs, depending on pointers from the Pascal side.

I'm not an alignment expert, but only when loading types that are larger
than the pointer size, since only those are not naturally aligned and so
could cross cacheline bounderies?

Note that 16-byte is not enough, certain AVX instructions are iirc
documented to require 32-byte alignment, and it is also recommended for
speed(https://software.intel.com/en-us/articles/practical-intel-avx-optimization-on-2nd-generation-intel-core-processors)

Anyway, I don't see a problem with having a cmemalign16 (or -32 or whatever)
unit, but I wouldn't blow up allocation unnecessary if there hasn't been a
real problem in most cases.
 
Since cmem is documented to be used from the main program file (iow the
users code), that would nicely put the responsibility there.