[fpc-devel] State of SSE/AVX intrinsics
J. Gareth Moreton
gareth at moreton-family.com
Wed Apr 22 17:22:07 CEST 2020
A global property inside the System unit I don't think would be wise
because anything could set it and it wouldn't be threadsafe (for a
single-thread example, two different units might set it to what they
require, but one may get its value overwritten and have a smaller
alignment than asked - you could have a procedure that sets it to the
largest alignment requested, but if you have one unit that asks for 32
bytes and another that asks for 4,096 bytes, you're going to get a lot
of wasted memory). At least for C11 and C++17, you get an error if you
specify a size that is not a multiple of the alignment (C11 originally
specified 'undefined behaviour', but this was later corrected), but
personally I think it would be better to silently round the size up
(assuming it is impossible, non-portable or prohibitively slow to
reserve the exact size asked).
I am personally leaning towards an optional parameter for GetMem and
ReallocMem because that would show up in the code completer, thus
informing users that it exists, and a little easier to document too.
Also, because you're specifying the alignment at the moment you are
allocating a block of memory, there won't be any problems with global
variables being overwritten. I do have some unanswered questions
though, like what happens if you reserve aligned memory and then you
pass it through ReallocMem without the alignment setting, and vice versa
(reserve unaligned memory, then reallocate it with an alignment,
especially a smaller size which doesn't usually require relocation) -
should the compiler attempt to honour the original or new alignment, or
throw an exception for mixing aligned and unaligned allocations this way
(that would likely require storing extra information in the memory manager)?
Most objects don't need specialised alignment, although Denis Golovan
earlier in this e-mail thread does want aligned dynamic arrays (e.g.
"VectorArray: array of Double align 32;"), where the variable
VectorArray itself might not be aligned (it might be on the stack), but
VectorArray is aligned to the required alignment - such a feature
could reuse, and would greatly benefit from, an aligned GetMem's
internal functionality. For one thing, it means you can use standard
Pascal constructs for such specialised tasks instead of having to play
around with pointers.
Gareth aka. Kit
On 22/04/2020 16:05, Tomas Hajny wrote:
> On 2020-04-22 15:45, J. Gareth Moreton wrote:
>> A global option, like a preprocessor directive or command line option,
>> feels a bit dangerous and can easily introduce unexpected bugs if it's
>> left out, so an explicit optional parameter (e.g.
>> GetMem(AlignedVector, 4096, 64);) would feel like the way to go.
> I didn't mean a preprocessor directive or a command line option (that
> wouldn't work for previously compiled units anyway). I rather meant a
> property inside unit system (probably within the memory manager
> structure) that would allow setting the required behaviour. But I
> don't know if it's a better option than a new optional parameter for
> the respective routines, it was just an idea towards reducing the
> impact to existing code and possibly also the amount of knowledge
> required for using this feature.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
This email has been checked for viruses by Avast antivirus software.
More information about the fpc-devel