Add aligned_accessor example

[mhoemmen]

1. aligned_accessor uses compiler identification macros to pick from various, possibly nonstandard ways to mark a pointer (its value, and/or its type) as having a specific alignment.

2. "Aligned" benchmarks use overaligned allocation and the aforementioned way to mark a pointer as aligned.

3. "Unaligned' benchmarks access memory aligned only to the element type, by adding 1 (sizeof(ElementType) bytes) to the array start.

[mhoemmen]

Fixes for Clang, MSVC, and Intel here: https://godbolt.org/z/vhGz3zcYn

I still need to incorporate these into the PR.

[mhoemmen]

@crtrott @dalg24 @nliber I updated the PR to fix Clang, MSVC, and Intel builds. Here is the corresponding Compiler Explorer link: https://godbolt.org/z/47dEf59rs

[mhoemmen]

Test with C++14, C++17, and C++20 builds: https://godbolt.org/z/raYsGTq3P

[mhoemmen]

Latest update (just pushed) includes OpenMP fixes: https://godbolt.org/z/PbMWbKMj7

[dalg24]

A few drive by comments

[dalg24]

Looks mostly good
Only question I have is do you care to not cast within the outer repetition loop?
Because if that is acceptable you would be able to get rid of a lot of boiler plate code

[mhoemmen]

@dalg24 wrote:

Only question I have is do you care to not cast within the outer repetition loop?

The "casts" in the various benchmark_ functions don't all have the same form. Some of them actually create an mdspan from a pointer. Others call bless on the pointer, which both casts and calls assume_aligned. Performing the casts or blessings explicitly, outside the outer loop, lets each add_* function be as simple as possible. This hopefully removes any unnecessary barriers to the compiler optimizing it.

This is an example, so the small amount of repetition has educational value. Users can copy and paste as a start to adding their own benchmarks.

[crtrott]

I think we need to change the non-aligned element returning & to element 0 too, I am also wondering if we can reduce code duplication here. For example have the same benchmark function templated on a tag and the casted to type:

template<class ArrayType, class constArrayType, class ElementType,  class BenchmarkTag, class ... ConstructorArgs>
auto benchmark_add_1d(const BenchMarkTag& tag, const std::size_t num_trials,
				      const index_type n,
				      const ElementType x[],
				      const ElementType y[],
				      ElementType z[],
                                      ConstructorArgs ... cargs)
{
  TICK();
  constArrayType x2{x, cargs};
  constArrayType y2{x, cargs};
  ArrayType z2{x, cargs};
  for (std::size_t trial = 0; trial < num_trials; ++trial) {
    add(tag, x2, y2, z2);
  }
  return TOCK();
}

[crtrott]

Not sure if this is what we should do here instead of returning also address to element 0. After all you are now measuring something different, like the number of cachelines/pages touched by each thread might be different. I'd rather like to see that the attribute in and of itself does something.

[mhoemmen]

@crtrott My concern there was that the compiler has complete code visibility, so it could deduce that the allocation is aligned. For the benchmark, I wanted to be able to give it an allocation that I know is aligned to no more than sizeof(ElementType).

[mhoemmen]

@crtrott I like the tag idea for the benchmarks, though! I was a bit worried about possibly needing to do type conversion of x, y, and z on every invocation of the inner loop, but I think I could restructure the code to avoid that.

[mhoemmen]

@crtrott I tried out the tag idea, but I don't think it saves much code. Each benchmark invocation still needs to name the const and nonconst array types and the tag types explicitly.

Perhaps y'all are missing the point a bit -- this is an example. It's code for users to read, that teaches them how to write a custom accessor. It's something more like a tutorial. Reducing code duplication isn't really the point here; the point is simple, readable code that users could easily copy and paste.

[mhoemmen]

@crtrott wrote:

I think we need to change the non-aligned element returning & to element 0 too....

I have addressed this in my latest revision.