Advice to use alignas for cache alignment about arm-learning-paths

[jasonrandrews]

Thanks for the feedback.

@markos please take a look at the information above and decide if you recommend any changes.

[markos]

@pan- @jasonrandrews I agree that it will hurt performance, however that's exactly one of the points of the LP, that it will do that. I wanted to show that cache alignment is important if someone is focuses on performance. The suggestions for the code, were to demonstrate the point, as you probably have noted in the end of that page you linked. Bad alignment will make the same code much slower.

Sometimes a developer may have to maintain or improve existing software with such packed structures. Also, it was specifically meant for Linux systems -as noted in the first page of the LP. Windows on Arm is a very recent thing and not my expertise, if I am honest. And not being available on Windows is not really an argument not to use a feature, there are plenty of GCC/LLVM specific features that are used in general because they are useful and solve a problem.

Furthermore, alignas (available only recently in C23 even though it's part of C++11) is not a substitute for packed attribute, it does not do the same thing (you probably mean the __attribute__(aligned))).

[pan-]

@markos _Alignas is available since C11; C23 just adds an alias to it as alignas.

Furthermore, alignas (available only recently in C23 even though it's part of C++11) is not a substitute for packed attribute, it does not do the same thing (you probably mean the attribute(aligned))).

Of course alignas is not the same as packed. alignas will guarantee that the type is properly aligned while the packed attribute destroys type alignment (example) and exposes your fields to unaligned access which may decrease performance as latter in the document or worse results in a crash on V8M or if the compiler decides to use load/store multiple...

In other terms, if a an array of the data structure is declared on the stack, if you use packed it won't be aligned at all and you expose yourself to undesirable side effects whereas if alignas is used it will be aligned as requested without ill side effects.

Things are getting slightly more complex for dynamic allocation as malloc/free don't offer over alignment guarantees beyond what is in the ABI. However there are standard functions for this: Aligned alloc available in C11 is one of them combined with _Alignof it becomes easy to allocate properly aligned arrays: (aligned_alloc(sizeof(T) * count, _Alignof(T))) . The new operator also supports an alignment argument since C++17.

To summarise my point I believe we (I'm working for Arm) should recommend good practices and use language standard API and constructs where applicable to promote portable solutions.

[jasonrandrews]

Hi @pan-

Would you be interested to write a short Learning Path to share your points? This would be a great outcome.

It looks like you have some good knowledge and are already pointing to example code in your comments. Because this is a community project, it's good for multiple people to share knowledge, even if the material covers similar topics.

I'm happy to help you get started if you need any help.

Thanks,
Jason

[markos]

Of course alignas is not the same as packed. alignas will guarantee that the type is properly aligned while the packed attribute destroys type alignment (example) and exposes your fields to unaligned access which may decrease performance as latter in the document or worse results in a crash on V8M or if the compiler decides to use load/store multiple...

Erm, which is exactly the point I was trying to make in that section in the LP. I used on purpose bad alignment to show that there is measurable performance degradation. This was not an "accident". I tried to write something short and simple that will show the worst impact in performance. And packed structures are very common especially in networking protocols and storage file formats, on purpose.

Things are getting slightly more complex for dynamic allocation as malloc/free don't offer over alignment guarantees beyond what is in the ABI. However there are standard functions for this: Aligned alloc available in C11 is one of them combined with _Alignof it becomes easy to allocate properly aligned arrays: (aligned_alloc(sizeof(T) * count, _Alignof(T))) . The new operator also supports an alignment argument since C++17.

To summarise my point I believe we (I'm working for Arm) should recommend good practices and use language standard API and constructs where applicable to promote portable solutions.

Regarding the portable part, I specifically mentioned Linux as a requirement for the LP, and it was accepted as such. In fact it will run also on the BSD as well. I never even implied that the code would work on Windows.

In any case, I don't want to engage in a needless debate here. I don't disagree with you that I could add a few notes about alignas or even align_alloc here (which btw, according the link you pasted is also not available on MS Windows C Runtime). I will finish my current LPs and then I'll revisit this one with the requested additions. But I'll be honest, in general I do not plan to do anything special to ensure portability with Windows, as I have zero interest in it. Someone else will have to do that part.

[jasonrandrews]

Hi @markos ,

There is no required action here, but please submit PRs for improvement or new Learning Paths as you are able to contribute.

Thank you for your effort and participation.

Jason