4 ms·

In the abstract, it's the inverse of the argument that "configuration formats should be programming languages"; the more general something can be, the less you

by dwattttt 10mo ago

In the abstract, it's the inverse of the argument that "configuration formats should be programming languages"; the more general something can be, the less you can assume about it. A way to express the operations you want, without unintentionally expressing operations you don't want, would be much easier to auto-vectorise. I'm not familiar enough with SIMD to give examples, but if a transformation would preserve the operations you want, but observably be different to what you coded, I assume it's not eligible (unless you enable flags that allow a compiler to perform optimisations that produce code that's not quite what you wrote).

Earw0rm 10mo ago
That's very much an issue with SIMD, especially where floating point numbers are concerned. Matt Godbolt wrote about it recently. https://xania.org/202512/21-vectorising-floats https://xania.org/202512/21-vectorising-floats TLDR, math notation and language specify particular orders in which floating point operations happen, and precision limits of IEEE float representation mean those have to be honoured by default. Allowing compilers to reorder things in breach of that contract is an option, but it comes with risks.
- 9029 10mo ago
  I like that Zig allows using relaxed floating point rules with per block granularity to reduce the risk of breaking something else where IEEE compliance does matter. I think OpenMP simd pragmas can be used similarly for C/C++, but that's non-standard.
  - galangalalgol 10mo ago
    You can do the same thing with types or the wide crate. But it isn't always obvious when it will become a problem. Usung these types does make auto vectorization fairly reliable.
- pklausler 10mo ago
  Fortran requires compilers to “honor the integrity of parentheses” but otherwise doesn’t restrict compilers from rearranging expressions. Want a specific order of operations and rounding? Use parentheses to force them. This is why you’ll sometimes see parens around operations that already have arithmetic precedence, like `(x times x)-(y times y)`, to prevent the use of FMA for one of the multiplications but not the other.

Earw0rm 10mo ago

That's very much an issue with SIMD, especially where floating point numbers are concerned. Matt Godbolt wrote about it recently. https://xania.org/202512/21-vectorising-floats https://xania.org/202512/21-vectorising-floats TLDR, math notation and language specify particular orders in which floating point operations happen, and precision limits of IEEE float representation mean those have to be honoured by default. Allowing compilers to reorder things in breach of that contract is an option, but it comes with risks.

9029 10mo ago
I like that Zig allows using relaxed floating point rules with per block granularity to reduce the risk of breaking something else where IEEE compliance does matter. I think OpenMP simd pragmas can be used similarly for C/C++, but that's non-standard.
- galangalalgol 10mo ago
  You can do the same thing with types or the wide crate. But it isn't always obvious when it will become a problem. Usung these types does make auto vectorization fairly reliable.
pklausler 10mo ago
Fortran requires compilers to “honor the integrity of parentheses” but otherwise doesn’t restrict compilers from rearranging expressions. Want a specific order of operations and rounding? Use parentheses to force them. This is why you’ll sometimes see parens around operations that already have arithmetic precedence, like `(x times x)-(y times y)`, to prevent the use of FMA for one of the multiplications but not the other.