C++17 and alignment...

[Chris M. Thomasson]

Thanks to Bonita, I learned that C++17 actually works with alignas wrt
using new. This is very nice and am looking forward to using it quite a
bit. Here is some crude sample code:

can you compile it, and what is your output? Do you get any Crap? ;^)
_________________________
#include <iostream>
#include <atomic>
#include <cstdint>
#include <cstdlib>


static constexpr std::size_t ct_page_size = 8192;
static constexpr std::size_t ct_l2_cacheline_size = 64;


struct alignas(ct_l2_cacheline_size) ct_cacheline
{
std::atomic<std::uint64_t> m_state;
};


struct alignas(ct_page_size) ct_page
{
ct_cacheline m_line_0;
ct_cacheline m_line_1;
};


int main()
{
if (sizeof(ct_cacheline) != ct_l2_cacheline_size)
{
std::cout << "Crap! ct_cacheline is not padded!\n";
}

if (sizeof(ct_page) != ct_page_size)
{
std::cout << "Crap! ct_page is not padded!\n";
}

ct_page* page = new ct_page;

std::cout << "page = " << page << "\n";

if ((std::uintptr_t)(page) % ct_page_size)
{
std::cout << "Crap! page is not aligned!\n";
}

if ((std::uintptr_t)(&page->m_line_1) % ct_l2_cacheline_size)
{
std::cout << "Crap! page->m_line_1 is not aligned!\n";
}

delete page;

return 0;
}
_________________________


Now it seems as if alignas, at least on MSVC has a "limit". For instance
I am getting a compile time error using a ct_page_size of 8192 * 4.

_________________________
Error C2345 align(32768): illegal alignment value

Well, I am wondering why this would be a limitation?
_________________________


Thanks.

[Chris M. Thomasson]

On 1/21/2021 3:17 PM, Chris M. Thomasson wrote:
> Thanks to Bonita, I learned that C++17 actually works with alignas wrt
> using new. This is very nice and am looking forward to using it quite a
> bit. Here is some crude sample code:

[...]

Liking C++17 more and more. Thanks Bonita! std::vector seems to work
fine with alignas. The way new works with alignas is very interesting.
Love it. MSVC 2019 has a limit on alignas, but that's okay.

_______________________
#include <iostream>
#include <atomic>
#include <cstdint>
#include <cstdlib>

#include <vector>


static constexpr std::size_t ct_pages_n = 3;

static constexpr std::size_t ct_page_size = 8192;
static constexpr std::size_t ct_l2_cacheline_size = 64;

template<typename T>
static inline bool
ct_assert_align(T const* ptr, std::size_t alignment)
{
return ! ((std::uintptr_t)(ptr) % alignment);

}


struct alignas(ct_l2_cacheline_size) ct_cacheline
{
std::atomic<std::uint64_t> m_state;
};


struct alignas(ct_page_size) ct_page
{
ct_cacheline m_line_0;
ct_cacheline m_line_1;

ct_cacheline m_line_2;
ct_cacheline m_line_3;
};


static_assert(sizeof(ct_page) == ct_page_size);
static_assert(sizeof(ct_cacheline) == ct_l2_cacheline_size);


static void
ct_page_iter(
std::vector<ct_page> const& pages,
std::size_t n
) {
for (std::size_t i = 0; i < n; ++i)
{
ct_page const& page = pages[i];

if (! ct_assert_align(&page.m_line_2, ct_l2_cacheline_size))
{
std::cout << "Crap!\n";
}
}
}


int main()
{
std::vector<ct_page> page(ct_pages_n);

// validate first element wrt page alignment
if (! ct_assert_align(&page[0], ct_page_size))
{
std::cout << "Big Time Crap!\n";
}

// validate cache lines
ct_page_iter(page, page.size());

return 0;
}
_______________________

Can you run this with outputting any Crap on your end?

[Bonita Montero]

> Now it seems as if alignas, at least on MSVC has a "limit". For instance
> I am getting a compile time error using a ct_page_size of 8192 * 4.
> _________________________
> Error    C2345    align(32768): illegal alignment value

Sorry, that's stpuid. I'd never expect a support for alignment at the
size of a page.
BTW: a page is 4kB on x86.

[Chris M. Thomasson]

Why? The larger the alignment the more one can steal from the aligned
pointer.

[Bonita Montero]

> Why? ...

Because there isn't any native type, even those platform-specific
like those __512*-datatypes, which need an alignment of kBs.

[Chris M. Thomasson]

One can over align on purpose to steal bits and do other fancy things
wrt, say, memory allocators.

[Bonita Montero]

>> Because there isn't any native type, even those platform-specific
>> like those __512*-datatypes, which need an alignment of kBs.

> One can over align on purpose to steal bits and do other fancy
> things wrt, say, memory allocators.

There's no reason to declare data structures to be aligned beyond
any native data type.

[David Brown]

Of course there is. What's the biggest native type? A 16-byte quad
precision floating point, or 128-bit integer? Some sort of 64-byte SIMD
vector? In the PC world, for high-performance code you would often want
alignment based on cache line sizes. Once non-volatile ram becomes more
common, it may be of interest to align to flash erase block lines.
Certainly 4 KB alignment could be of interest in many cases. Alignments
bigger than that are probably a lot less useful, however.

In my embedded programming I have found use for large aligned data in
circular buffers, especially when handled by DMA.

And then there is the possibility of using the low bits in an aligned
address for odd purposes - the bigger the alignment, the more bits you
have to play with.

[Bonita Montero]

> Of course there is. What's the biggest native type? A 16-byte quad
> precision floating point, or 128-bit integer? Some sort of 64-byte SIMD
> vector? In the PC world, for high-performance code you would often want
> alignment based on cache line sizes. Once non-volatile ram becomes more
> common, it may be of interest to align to flash erase block lines.

You can't directly address non-volatile RAM. They have a register-based
block-level interface.

> Certainly 4 KB alignment could be of interest in many cases.

No, not for a single data structure.

[Chris M. Thomasson]

Why not?

[Bonita Montero]

Because from the language-perspective a structure only needs to be
aligned to the structure element with the largest alignment-requirement.

[David Brown]

On 22/01/2021 08:53, Bonita Montero wrote:
>> Of course there is.  What's the biggest native type?  A 16-byte quad
>> precision floating point, or 128-bit integer?  Some sort of 64-byte SIMD
>> vector?  In the PC world, for high-performance code you would often want
>> alignment based on cache line sizes.  Once non-volatile ram becomes more
>> common, it may be of interest to align to flash erase block lines.
>
> You can't directly address non-volatile RAM. They have a register-based
> block-level interface.

No - NVDIMM devices are directly addressable. Non-volatile ram is
"randomly accessible memory".

(That is different from SSDs and other non-volatile devices, which are
viewed as block devices by the OS.)

>
>> Certainly 4 KB alignment could be of interest in many cases.
>
> No, not for a single data structure.
>

You are very categorical about what you think people would never want to
do. Don't you realise that you only ever see a very small section of
the programming world?

I've had occasional use for buffers with alignment a good deal bigger
than 4 KB (in connection with DMA cyclic buffers in embedded systems).

On PC's, I'd imagine that aligning to page boundaries could be useful in
some types of coding.

[Bonita Montero]

> You are very categorical about what you think people would never want
> to do.

No, I think that the compiler only has to support alignment up to its
built-in datatypes.

> I've had occasional use for buffers with alignment a good deal bigger
> than 4 KB (in connection with DMA cyclic buffers in embedded systems).

Kernel-programming is beyond the means of C or C++. And you use
the allocation-functions of your OS that give you aligned blocks.

[David Brown]

On 22/01/2021 12:57, Bonita Montero wrote:
>> You are very categorical about what you think people would never want
>> to do.
>
> No, I think that the compiler only has to support alignment up to its
> built-in datatypes.
>

What a compiler /has/ to support is not the same as what developers
might find useful. A quick check of the C11 standards (since I have
that document open, but not C++17 standards) shows that the compiler
/has/ to support alignment up to the size of "max_align_t" (which is
implementation dependent). It does not have to support anything bigger,
but it can. Compilers are also free to have other alignment support
beyond "alignas" (most do, since most have support that preceded the
standardised "alignas").

A quick check with gcc shows it is quite happy with alignments up to
0x10000000, or 2 ^ 24. (I'm not suggesting that is likely to be
useful.) Different compilers can have different limits.

>> I've had occasional use for buffers with alignment a good deal bigger
>> than 4 KB (in connection with DMA cyclic buffers in embedded systems).
>
> Kernel-programming is beyond the means of C or C++. And you use
> the allocation-functions of your OS that give you aligned blocks.

Kernel programming is almost always done in C or C++. It is not "beyond
their means". And I didn't use the large alignment in kernel
programming - it was application code (though on such embedded systems
there is usually no separate "kernel space" and "user space"). And I
most certainly would /not/ use an allocation function for such purposes,
even if I had an OS on the system.

Quite clearly, there are uses of aligned data that are well beyond the
levels of your knowledge and experience. That's fine, of course - you
no doubt have done coding that is well outside the range of my knowledge
and experience too.

But you really should learn that there is a world beyond what you know -
stop making up nonsense about what you think people do or do not want to
do, based solely on your own small section of the programming world.

[Bonita Montero]

> What a compiler /has/ to support is not the same as what developers

> might find useful. ...

We're talking about C++, and not about your wishlist.

> A quick check with gcc shows it is quite happy with alignments up to
> 0x10000000, or 2 ^ 24. (I'm not suggesting that is likely to be
> useful.) Different compilers can have different limits.

For userland that's not necessary because if someone needs such an
alignment, f.e. if he writes his own memory-allocator for an aligned
pool, he uses VirtualAlloc(), mmap() or something else. But I don't
see any need for a new to support an alignment of 24 bits.

> Kernel programming is almost always done in C or C++. It is not "beyond
> their means".

Kernel-programming in C or C++ is totally different than in user-mode.
You can only use a small portion of the standard library. And you have
a totally different memory-allocation scheme.
So you can't say kernel-programming is directly supported in C or C++.

[David Brown]

On 22/01/2021 16:00, Bonita Montero wrote:
>> What a compiler /has/ to support is not the same as what developers
>> might find useful. ...
>
> We're talking about C++, and not about your wishlist.

Yes, C++ - not your unwarranted guesses about what people might want,
need and use, and what tools might support.

>
>> A quick check with gcc shows it is quite happy with alignments up to
>> 0x10000000, or 2 ^ 24.  (I'm not suggesting that is likely to be
>> useful.)  Different compilers can have different limits.
>
> For userland that's not necessary because if someone needs such an
> alignment, f.e. if he writes his own memory-allocator for an aligned
> pool, he uses VirtualAlloc(), mmap() or something else. But I don't
> see any need for a new to support an alignment of 24 bits.

I don't care if /you/ think it is useful or not. The point is that at
least some compilers support it.

>
>> Kernel programming is almost always done in C or C++.  It is not "beyond
>> their means".
>
> Kernel-programming in C or C++ is totally different than in user-mode.
> You can only use a small portion of the standard library. And you have
> a totally different memory-allocation scheme.
> So you can't say kernel-programming is directly supported in C or C++.

I don't know why you are so convinced that you know everything, no
matter how easily people demonstrate your ignorance. But obviously you
have no interest in learning anything beyond your small section of the
programming world - not even an interest in learning that there /is/ a
world beyond it.

I'll go back to my usual policy of ignoring you.

[Bonita Montero]

>> For userland that's not necessary because if someone needs such an
>> alignment, f.e. if he writes his own memory-allocator for an aligned
>> pool, he uses VirtualAlloc(), mmap() or something else. But I don't
>> see any need for a new to support an alignment of 24 bits.

> I don't care if /you/ think it is useful or not. The point is that at
> least some compilers support it.

There's no need for a support of 24 bit aligned allocations because if
you need it that way you don't use new.

>> Kernel-programming in C or C++ is totally different than in user-mode.
>> You can only use a small portion of the standard library. And you have
>> a totally different memory-allocation scheme.
>> So you can't say kernel-programming is directly supported in C or C++.

> I don't know why you are so convinced that you know everything, no
> matter how easily people demonstrate your ignorance. But obviously you
> have no interest in learning anything beyond your small section of the
> programming world - not even an interest in learning that there /is/ a
> world beyond it.

You simply didn't understand what I said above.

[Chris M. Thomasson]

Keep in mind that I am over aligning on purpose. This allows me to do
some fun things. For instance... Think about being able to get at a page
"header" by simply rounding down any address in said page to a page
boundary. This is extremely useful. Think about a memory allocator where
a free consists of rounding down to page boundary, where a header exists
that has a lock-free stack. Now, I can just add the freed memory to that
list.

over aligning has many uses.

[Chris M. Thomasson]

Exactly. I remember using the low bits for a very special reference
counter. Also remember using them to embed state for a mutex. I used
them for many other things, but that was a while ago. 15+ years.
However, all of the code was non-standard. I like the fact that C++17
allows for over alignment, and that it integrates it directly with new
and delete.

I might port an old proxy garbage collector thing I did way back into C++17.

I have some older memory allocators that could simply round freed memory
down to a page boundary where a header is, and link it into a lock-free
list. This allowed the granularity of a memory block to be the size of a
pointer. Pretty nice, and fast.

[Chris M. Thomasson]

On 1/22/2021 2:10 PM, Chris M. Thomasson wrote:
> On 1/21/2021 11:43 PM, David Brown wrote:
>> On 22/01/2021 08:22, Bonita Montero wrote:
>>>>> Because there isn't any native type, even those platform-specific
>>>>> like those __512*-datatypes, which need an alignment of kBs.
>>>
>>>> One can over align on purpose to steal bits and do other fancy
>>>> things wrt, say, memory allocators.
>>>
>>> There's no reason to declare data structures to be aligned beyond
>>> any native data type.
>>
>> Of course there is.

[...]

> I have some older memory allocators that could simply round freed memory
> down to a page boundary where a header is, and link it into a lock-free
> list. This allowed the granularity of a memory block to be the size of a
> pointer. Pretty nice, and fast.

Wrt my older memory allocators and special free lists... Well, I could
tell if the memory being freed was allocated from the same thread that
allocated it to begin with. Iirc, it went something like:

round the freed address F down to a page boundary.

Get the per thread page, TLS and such.

Okay, now we compare the freed rounded down address F to the freeing
threads main page address. If they are the same, aka (local memory),
then we could free the memory F directly to our local stack without
using any membars or atomics. Now, if they were different (remote
memory), then I had to use a lock-free stack to pass the memory back to
the remote thread that allocated it to being with.

So a page "header" had two free lists, local and remote. When malloc
failed to grab local memory from the local list, it flushed the remote,
transferred to local, and tried the local free list again. If that
failed it tried to grab another page from the global pool. If that
failed it would allocate new memory from the system. If that failed, it
returned NULL to the calling thread.

A multi-layered approach wrt malloc and free.

This is bringing up many old memories! This thread is cool. Thanks
everybody.

Wrt my old experimental memory allocator, this made all memory
allocations be at least as big as a pointer. So, allocating memory >= to
a pointer size does not incur any extra overhead. However, allocating a
single char, will be rounded up to a pointer size.

[Bonita Montero]

> Keep in mind that I am over aligning on purpose.

If you need to allocate a data structure you never need a larger algin-
ment than the largest alignment-requirement of a native member. And if
you allocate a data structure which need to be aligned beyond that and
extend it later by offsetting the pointer to the object you don't use
new but VirtualAlloc() or mmao(). So where's the problem: new never
needs to be aligned beyond the alignment requirement of its members.

> For instance... Think about being able to get at a page "header"
> by simply rounding down any address in said page to a page boundary.

Then use VirtualAlloc() or mmap().

[Chris M. Thomasson]

On 1/22/2021 9:42 PM, Bonita Montero wrote:
>> Keep in mind that I am over aligning on purpose.
>
> If you need to allocate a data structure you never need a larger algin-
> ment than the largest alignment-requirement of a native member.

Humm... You don't seem to be "getting" it. Oh well.

> And if
> you allocate a data structure which need to be aligned beyond that and
> extend it later by offsetting the pointer to the object you don't use
> new but VirtualAlloc() or mmao(). So where's the problem: new never
> needs to be aligned beyond the alignment requirement of its members.

Afaict, C++17 allows for over alignment. Why do you think they did that?
I love the fact that it allows for new to honor alignas.

Just because _you_ think something needs to act in a certain way misses
a lot of really useful use cases, indeed. ;^)

>> For instance... Think about being able to get at a page "header"
>> by simply rounding down any address in said page to a page  boundary.
>
> Then use VirtualAlloc() or mmap().

I understand that, but I am really interested in keeping this as
standard as possible. Imvho, its a shame that MSVC 2019 does not seem to
support std::aligned_alloc directly:

https://en.cppreference.com/w/cpp/memory/c/aligned_alloc

However, they do have an _aligned_malloc:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/aligned-malloc?view=msvc-160

Which works fine.

[Bonita Montero]

> Afaict, C++17 allows for over alignment. Why do you think they did that?

It's not necesary.

> I understand that, but I am really interested in keeping this as

> standard as possible. ..

For what purpose do you need that over-alignment ?

[Chris M. Thomasson]

On 1/23/2021 8:49 PM, Bonita Montero wrote:
>> Afaict, C++17 allows for over alignment. Why do you think they did that?
>
> It's not necesary.

Its really helpful.

>> I understand that, but I am really interested in keeping this as
>> standard as possible. ..
>
> For what purpose do you need that over-alignment ?

Did you read my posts in this thread?

[Bonita Montero]

>>> I understand that, but I am really interested in keeping this as
>>> standard as possible. ..

>> For what purpose do you need that over-alignment ?

> Did you read my posts in this thread?

Ok, you dont't have a purpose as everyone else here.

It's simply if you have such an alignment it's while you have
a much larger block to allocate and you have to put information
along with this structure offsetted someone else. But it yo do
thay you don't use new, but something like VirtualAlloc() or
mmap() or something like the kernel-facilities, wgich micht
also pin the page physically.
So there's no need for such a large alignment.

[Chris M. Thomasson]

C++17 now gives a compiler the ability to support over alignment. I like
that.

> So there's no need for such a large alignment.

There are many reasons to use a "large" alignment.

Its nice that there is a way to create these things in standard C++.
Also, over alignment is useful wrt, say, a cacheline. Iirc, when
hyperthreading first came out one would use 128 byte cachelines, split
in two. Back then there was no way to get this without some hacks. Then
there was the 64k aliasing issue in a threads stack. So we had to use
alloca or something to offset the stack. This is back when I used to
read all of the Intel docs.

https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm

Humm... I really should recreate one of my older memory allocators that
relied on these large alignments. The neat part, at least to me, is the
alignment aspect can use standard C++. Rounding down to a boundary was
key to performance.

Also, keep in mind that there are bits to play with in these type of
"large" alignments. Exotic algorithms can use these.

[Bonita Montero]

>> So there's no need for such a large alignment.

> There are many reasons to use a "large" alignment.

I'm still asking for those reasons and no none tell me them.

> Also, over alignment is useful wrt, say, a cacheline. Iirc, when
> hyperthreading first came out one would use 128 byte cachelines,
> split in two.

That's a differnt thing than alignment on page-sizes; which isn't
needed because you use different allocation-functions then which
do this alignment.

> https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm

Use mmap() or VirtualAlloc ...

[Chris M. Thomasson]

On 1/25/2021 1:01 AM, Bonita Montero wrote:
>>> So there's no need for such a large alignment.
>
>> There are many reasons to use a "large" alignment.
>
> I'm still asking for those reasons and no none tell me them.

I told you several of them in this thread. You have a knack to snip
relevant information. Also, please... Please try to quote properly. ;^)

Remember when you were "convinced" that a mutex is an atomic counter?
Then I showed how you are wrong? This is going down a similar path...

>> Also, over alignment is useful wrt, say, a cacheline. Iirc, when
>> hyperthreading first came out one would use 128 byte cachelines,
>> split in two.
>
> That's a differnt thing than alignment on page-sizes; which isn't
> needed because you use different allocation-functions then which
> do this alignment.

What if somebody wants to do page alignment using standard C++? Why do
you insist on telling them they should not be able to do that? Just
because you think something should not be done, does not mean you are
correct. You should write to compiler vendors and tell them that over
alignment on a page should not be supported. :^)

I am happy that some compilers support that.

>> https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm
>
>
> Use mmap() or VirtualAlloc ...
>

The link references offsetting thread stacks to get around the deadly
64k aliasing issue. It would cause false sharing all over the place.

[Chris M. Thomasson]

On 1/25/2021 12:45 PM, Chris M. Thomasson wrote:
> On 1/25/2021 1:01 AM, Bonita Montero wrote:
>>>> So there's no need for such a large alignment.
>>
>>> There are many reasons to use a "large" alignment.
>>
>> I'm still asking for those reasons and no none tell me them.
>
> I told you several of them in this thread. You have a knack to snip
> relevant information. Also, please... Please try to quote properly. ;^)
>
> Remember when you were "convinced" that a mutex is an atomic counter?
> Then I showed how you are wrong? This is going down a similar path...
>
>
>>> Also, over alignment is useful wrt, say, a cacheline. Iirc, when
>>> hyperthreading first came out one would use 128 byte cachelines,
>>> split in two.
>>
>> That's a differnt thing than alignment on page-sizes; which isn't
>> needed because you use different allocation-functions then which
>> do this alignment.
>
> What if somebody wants to do page alignment using standard C++? Why do
> you insist on telling them they should not be able to do that? Just
> because you think something should not be done, does not mean you are
> correct. You should write to compiler vendors and tell them that over
> alignment on a page should not be supported. :^)
>
> I am happy that some compilers support that.

To clarify, I am happy that some compilers support over alignment up to,
and even beyond page alignment.

[Bonita Montero]

>> That's a differnt thing than alignment on page-sizes; which isn't
>> needed because you use different allocation-functions then which
>> do this alignment.

> What if somebody wants to do page alignment using standard C++?

Then he uses mmap() or VirtualAlloc.

[Chris M. Thomasson]

Well, that's not quite standard C++ is it...

[Bonita Montero]

>>> What if somebody wants to do page alignment using standard C++?

>> Then he uses mmap() or VirtualAlloc.

> Well, that's not quite standard C++ is it...

Since you can't rely on alignas(pagesize) that's not standard also.

[Chris M. Thomasson]

A compiler is allowed to support over alignment without resorting to
system specific calls. How many different systems have compilers that
support over alignment? Just like the atomic library and the following:

https://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free

You see? Some compilers may use locks to implement their atomics, others
do not. Does that mean we should not use std::atomic?

[Sam]

Of course not. There's nothing in the C++ standard about anything called
"pages".

[Chris M. Thomasson]

Indeed. Say we want to use alignas to align and pad a structure up to,
say, a 4096 byte alignment. Or even 8192 alignment. The C++ standard
does not mention level 2 cache lines as well. However C++17 explicitly
allows for over alignment. Then there is std::aligned_alloc. Going
outside of C++:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html

I would like to try and do these type of things without resorting to
system specific calls.

[Bonita Montero]

>>>> Then he uses mmap() or VirtualAlloc.

>>> Well, that's not quite standard C++ is it...

>> Since you can't rely on alignas(pagesize) that's not standard also.

> A compiler is allowed to support over alignment without resorting to
> system specific calls. How many different systems have compilers that
> support over alignment?

A compiler can't distinguish between memory allocated with mmap() or
VirtualAlloc() and new from its own pools. So it has to use new also,
even when you have a page-alignment. So the runtime has to do an over
-allocation and round up the pointer to the next page-boundary. With
an alignement of a page-size that's a much of waste.

[Chris M. Thomasson]

Wow. Before I make a proper response, I will let you ponder on what you
just wrote. Signing off for tonight.