Re:C++26 Disapproved
by smitherfield on Wednesday November 04, 2026 @01:10AM
(#50361979)
Couldn't SIMD features include marking data as "the compiler is free to rearrange"?
Only in the trivial cases where the compiler already knows that. Data used inside a single function can already be rearranged. Data that is used across more than one function can be rearranged only in the case where the compiler can prove the function is only used in the one translations unit (that is files). If data is used across translations units, there is no way for the compiler to talk with the compiler of the other translations unit to agree on the data rearrangement.
There is some effort in whole program optimization which can solve the above problem in theory. However I don't know how well it works in practice.
Re:C++26 Disapproved
by throwaway17_17 on Wednesday November 04, 2026 @01:25AM
(#50362074)
My imagination is failing me, can you give me an example of the type of work being done where SIMD is ‘deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types’? I don’t doubt you know what you mean, but I can’t wrap my head around it.
For me I can only think of the simplest example of SIMD being used to ‘parallelize loops’ as what SIMD is for. If it turns out I’m missing a large problem or application space for SIMD I will be excited to research it. Any pointers to topics would be appreciated.
Re:C++26 Disapproved
by AlotOfReading on Wednesday November 04, 2026 @01:48AM
(#50362203)
One example is OLAP databases, which often heavily exploit SIMD for query processing. You can also turn parsing into a SIMD problem, which is applicable to things like handling XML, JSON, and CSV. Simdjson comes to mind, or parabix for XML.
Re:C++26 Disapproved
by throwaway17_17 on Wednesday November 04, 2026 @02:18AM
(#50362375)
The parsing stuff I am aware of, but the query processing is a big blank for me to dig into.
Re:C++26 Disapproved
by jandrewrogers on Wednesday November 04, 2026 @01:51AM
(#50362218)
SIMD is often used to evaluate complex data structures in parallel. A common case is given a row with an arbitrary mix of data types and a query with an arbitrary mix of independent constraints on those data types, to evaluate all of the constraints in parallel in the same SIMD instruction(s).
The idea that SIMD is only good for parallelizing operations over arrays of the same type is empirically false and seriously understates the capabilities of good SIMD implementations. Some SQL-ish implementations work this way on row-structured data.
Most devs seriously underestimate what good SIMD is capable of.
Re:C++26 Disapproved
by throwaway17_17 on Wednesday November 04, 2026 @02:17AM
(#50362369)
Thanks for the response, I’ll have some reading to do in this area.
I wrote an example answer, but it was shadowbanned
The ability of compilers to use SIMD is no better than it was 20 years ago. Total stagnation for all practical purposes, and the reason is that compilers fundamentally lack the context and freedom to rewrite the code architecture appropriately for SIMD optimization (even if they could).
I think a point people miss is that highly optimized SIMD code is almost never about parallelizing loops. It is about deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types. SIMD allows you to do this, and it is fantastically efficient, but a compiler has no conceivable way of understanding this.
For this reason, SIMD optimization has often been classified as an AI-Complete problem in computer science.