Looking for status of SIMD implementation

[Bin.Cheng]

On Thu, Jun 24, 2021 at 4:50 PM Matthias Kretz <m.kretz@gsi.de> wrote:
>
> CC'ing libstdc++, to discuss stdx::simd design in public.
>
> I discussed variable length vectors at length in the C++ committee and so far
> I've not seen any useful progress that could make it work for vector *types*.
> The main issue is that C++ itself would require support for runtime-sized
> types throughout the language. E.g.
>
> template <class T>
> struct Point {
>   T x, y, z;
> };
>
> Now:
> sizeof(Point<float>) == 3 * sizeof(float)
> sizeof(Point<simd<float>>) == 3 * sizeof(simd<float>)
> should both hold. And the expectation is that it holds at compile time.
>
> If sizeof(simd<float>) is not a constant expression this breaks a lot of
> assumptions compilers currently make when constructing types. Suddenly
> offsetof(Point<simd<float>>, y) also isn't a constant expression. This affects
> how members are accessed: everything must be computed at runtime or possibly
> cached somewhere.
>
> Since the simd<T> type's strength, compared to loop vectorization, is the
> ability to define data structures that depend on sizeof(simd<T>) - like
> Point<simd<float>> - it's a non-starter to propose that runtime sized simd<T>
> cannot be used to compose data structures anymore. In a way std::valarray is
> that type which works in C++: if you need something with a size that's only
> known at runtime you have to malloc the memory, you can't use the stack.
>
> So unless C++ solves the runtime sized types issue in general (basically
> support VLAs in C++), I don't see runtime sized std::simd happening.
>
> My plan for SVE (and RISC-V V) was that in the first iteration you have to
> decide at compile time what vector width you want to compile for. My
> understanding, where SVE will be usable, is that you typically have a
> homogeneous cluster or a single machine where you can make this work. In
> engineering and research settings it is often possible to compile for the
> machine you'll work on. The problem becomes harder once a company wants to
> release binaries that are supposed to work on a wide range of customer setups.
> With this model you'd have one binary per supported SVE vector width or it
> would require "fat" binaries that contain a combination of many vector widths.
>
> But there's more we could do if the library and compiler work together. Like
> compile SVE code in such a way that data structures are "compiled" for many
> different vector widths while algorithms that work on the data structures are
> compiled in a vector width agnostic way. The novel (AFAIK) problem to solve is
> how to dispatch and combine these. Probably the best way to make progress is
> to compile everything for multiple vector widths, taking care to not use the
> knowledge about vector widths wherever possible, and then try to shrink the
> resulting "fat" binary by eliminating the resulting duplicated machine code
> regions. How this can move up to higher abstraction levels in the compiler, I
> have no idea...
>
> So -msve-vector-bits=<some number> might be a prerequisite for the first
> stdx::simd implementation.
Hi Matthias,
Thanks for the explanation, actually -msve-vector-bits=128*N is the
method I am using in my prototype implementation.  Considering SIMD
library itself guarantees source code level portability, it might be
fine to do this in the first version implementation.  Although here we
are breaking sub-target binary portability which SVE tries to achieve.

I will let Richard give more comments on this before discussing
details about the -msve-vector-bits method.

Thanks,
bin
>
> But I'd be happy for better ideas and/or research.
>
> --
> ──────────────────────────────────────────────────────────────────────────
>  Dr. Matthias Kretz                           https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research               https://gsi.de
>  std::experimental::simd              https://github.com/VcDevel/std-simd
> ──────────────────────────────────────────────────────────────────────────
>
>
>