[fpc-devel] State of SSE/AVX intrinsics

[J. Gareth Moreton]

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[0] 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.
>
> Tomas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus