-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small things #30
Comments
It's required if compiling using C++14 or earlier since alignment is not guaranteed for over-aligned types. https://stackoverflow.com/questions/49373287/gcc-over-aligned-new-support-alignas
Just because |
The stackoverflow link you mention is about support for aligned-new support, which is not the same thing as padding. Compilers automatically insert padding at the end of a struct, to ensure that arrays of the struct will be properly aligned. This does not depend on the C++ version.
This is right. At the same time, if T is aligned on kCacheLineSize, then its size is commonly sizeof(T) for the reason mention earlier. |
I see what you are saying, the padding will always be there. If overaligned new is not supported the padding will still be there. Thanks!
Better to waste some memory and be safe than sorry. Using |
First of all, kudos to your cache-aware indices. Though the underlying logic is not obvious (!), it does work and improves performances.
Two small things, not new to version 1.1:
The line:
char padding_[kCacheLineSize - sizeof(writeIdxCache_)]
has no effect as the global structure has a size that is already quantized, because of
alignas(kCacheLineSize)
members.The way you compute
kPadding
is not optimal, because if sizeof(T) == kCacheLineSize, thenkPadding
is 1, while 0 would be better.static constexpr size_t kPadding = (kCacheLineSize - 1) / sizeof(T) + 1;
The text was updated successfully, but these errors were encountered: