vectorcamp

Yes, SVE/SVE2 is somehow similar in that way, the same intrinsic has some variants depending on the predicate masks. However, the problem is that we have to make a few changes in the backend in order to do this and we have to do it withouth creating a mess for the other architectures. It will get there, it will just get a bit longer.

integration with std::simd might be doable, but there are no plans at least on our side to integrate with any particular library.

Yeah, that's definitely doable, thanks for the pointer, we will add it in the list :)

You still have to use the library, and it will still work the same way for normal scalar C code. The whole point is that the vectorization is difficult to write and an LLM just might be able to help with some cases, not all.

I agree. Most developers don't need to write SIMD code. Some do however and those need good documentation to write good SIMD code, even more so when it comes to porting.

Interesting that you mention Eigen. Long before I started my company VectorCamp, wrote the original Altivec/VSX, Arm and Z ports for Eigen and it took me a lot more to do a proper port back then -iirc I started that effort in 2008- than it would take me now, because now the tools are far far better. I started this company to provide SIMD optimizations for all architectures and this tool SIMD.info began because I wanted to help other developers find the information that I wish I had back then. It's that simple.

For me and my company, anything that needs to be performant critical to be written in a compiled language like C, C++, Rust -and now Zig- is worth optimizing. How much depends on your time, money and skills. Not everything needs SIMD of course. But it's definitely NOT only for library and compiler developers. You would be surprised how much SIMD code is even in application code out there. It all depends on the expectations and the required performance. Also, some of the libraries don't utilize all available instructions.

My 2c.

Hi, thanks for your feedback, we are being "incorrect" on purpose. All intrinsics up to and including SSE4.2 were including as part of SSE4.2. We have no intention of providing full granularity for any ISA extension esp one that is 20 years old. For the same reason, we are listing VSX as including in Power ISA 3.0, but not eg. Altivec or Power7/Power8 VSX. If you need such granularity, you are better off visiting the Intel Intrinsics Guide or the ISA manuals. So the separation for x86 is split into 3 groups, SSE4.2 (up to and including), AVX2 (including AVX) and AVX512 (also including some but not all variants). Something like x86_64-v1, x86_64-v2, etc that is used on compilers. We will probably do a finer granularity listing the exact extension in the description in the future, but not as part of the categorization.

Now the search is indeed less than ideal, we're working on replacing our search engine with a much more robust that doesn't favour one architecture over the other, especially in such words.

In any case, thank you for your feedback. It's still in beta but it is already very useful for us, as we're actually using it for development on our own projects.

Getting an LLM to translate code is very tricky, we haven't included AVX2 and AVX512 yet in our SIMD.ai because it requires a lot more work. However, translating code between similarly sized vector engines is doable when we finetuned our own data to the LLM. We tested both ChatGPT and Claude -and more- but none could do even the simplest translations between eg SSE4.2 and Neon or VSX. So trying something harder like AVX512 felt like a bit of a stretch. But we're working on it.

I agree, it's always best to use something that already exists and is optimized for your platform, unless it doesn't exist or you need extra features that are not covered. In those cases you need to read large ISA manuals, use each vendor's intrinsic site or use our tool SIMD.info :)

Do you mean Helium from Arm? Yes, that would be nice to include and relatively easy as it's mostly the same as Neon.

Hi, I'm one of the SIMD.info team, thanks for your feedback.

We would actually like to include more information, but our goal is to complement the official documentation not replace it. We actually provide links to Felix Cloutier's and Intel sites anyway, same for Arm and Power, where we can.

The biggest problem is the generation of the diagrams, we're investigating some way to generate these diagrams in a common manner for all architectures, but this will take time.

You make some good points. I represent Vectorcamp (creators of simd.info). It's still in Beta status, because we know there are some limitations currently, but we are already using it in production for our own projects. Now to comment on your points:

1. Empty string -> zero results, obviously a bug, we'll add some default value. 2. The sparse results are because of VSX, VSX provides multiple prototypes per intrinsic, which we thought would increase the size of the results a bit too much. Including the prototypes in the results is not a problem, but we don't want to have too much information on the other hand, that would make it too hard for the developer to find the relevant intrinsic. We'll take another look at this.

The description actually is rather bare, we intend to include a lot more information, like diagrams, pseudo code for the operation etc.

Examples are meant to be run as self-contained compile units, in the Compiler Explorer or locally, to demonstrate the intrinsic hence the extra setup. This will not change.

We also think that nothing will replace the official ISA references, we also include links to those anyway.

3. Regarding the contrast, we're already working on a light/dark theme.

Thank you for your comments.