Improving the SIMD module

[seiko2plus]

Recently, NumPy is working on moving to Mason, and one of the most important
obstacles standing in front of us is the support of SIMD.

The current unstable SIMD module lacks many vital features:

• Current x86 & Arm CPU features are few and there's no way to extend them without modifying the SIMD module.
• Many architectures aren't supported such as ppc64 and zsystem.
• Managing the relationship between the baseline(static) features and dispatched(dynamic) features.
• Implied features of each target aren't supported
• The ability to provide multiple targets for a single source

NumPy has Python/Distutils module that already handles all the above features,
so it will be not difficult for us to move them to meson. check CPU/SIMD Optimizations for more clarification.

I was wondering if any of the team could answer the following questions:

• Is there a willingness to accept significant contributions to the SIMD module?
• What are the main obstacles that we may face with the addition of these improvements?
• Do we have to support all languages ​​from the first moment? C/C++ is our main target.

[xclaesse]

* Is there a willingness to accept significant contributions to the SIMD module?

Of course, PRs welcome!

* What are the main obstacles that we may face with the addition of these improvements?

I never used simd module, so I'm not sure.

* Do we have to support all languages ​​from the first moment? C/C++ is our main target.

Baby steps are always easier for reviewers as well.

[eli-schwartz]

👍 absolutely agree.

Is there a willingness to accept significant contributions to the SIMD module?

Not only is there willingness to accept significant contributions -- you will be doing us a HUGE favor if you provide them. The SIMD module is currently marked as unstable, specifically because we don't have a lot of feedback from people using it regarding how well they feel it solves their problems.

Maybe it does solve their problems, maybe not, we don't know! :D So, having people tell us their challenges encountered when using it, and especially offering to help implement solutions, is kind of something that has TBH been overdue for years.

The upside to this is that we are very very willing to entertain sweeping changes to how it works, including the API, because it's explicitly a provisional one today.

What are the main obstacles that we may face with the addition of these improvements?

Obstacles in the sense of implementation issues that you'll need to establish solutions for? Off the top of my head, I realized at one time that Meson's assumption of "compile a specific set of files with optimizations for a specific arch, and another specific set of files for a different arch" does handle some use cases -- but not all use cases. Other people have existing sources where multiple arches are handled via defines, for example to mostly implement the same functions, and compute the function name based on the currently targeted optimization.

I wasn't sure what the best solution to that problem was. One possibility is to grow an additional API to ask the simd module which simd instructions it's currently possible to compile support for, and the additional flags to use for them. But that would ultimately end up in a bit of manual busywork to define targets that Meson can already do...

I'm also wondering whether it makes sense to support a "march=native" only mode, possibly as a Meson builtin option -Dsimd.native={true|false}.

tl;dr I suspect there's a loooot of room for improvement, and it's hardly limited to "support for X cpu and Y architecture". I seem to recall I started poking at these issues several years ago but lost focus due to lack of immediate personal use.

Do we have to support all languages ​​from the first moment? C/C++ is our main target.

I would start off with that too. The current SIMD module takes a compiler: argument anyway and then consults that found compiler to figure out what the compiler supports -- so the natural way to implement or extend that is to start off by implementing the support functions for the compilers you care about, and leaving other compilers for later (or for someone who is interested in those compilers).

[seiko2plus]

I sincerely appreciate your support.

Obstacles in the sense of implementation issues that you'll need to establish solutions for? Off the top of my head, I realized at one time that Meson's assumption of "compile a specific set of files with optimizations for a specific arch, and another specific set of files for a different arch" does handle some use cases -- but not all use cases.
Other people have existing sources where multiple arches are handled via defines, for example to mostly implement the same functions, and compute the function name based on the currently targeted optimization.

Similar to what we faced, both cases can be handled by allowing specify multiple targets for each source. Internally the source code can be compiled multiple times based on the specified targets.

I'm also wondering whether it makes sense to support a "march=native" only mode, possibly as a Meson builtin option -Dsimd.native={true|false}.

It's totally important at least for us, most HPC users expect statically dispatching (compile-time) the host CPU features. We already support it but it is limited to Unix-like compilers.