3 ms·

It’s more of a comment on how messy that code gets at -O3… it looks a lot messer than the -O2 code. (I think, it’s time, to say that “‘X considered harmful’ co

It’s more of a comment on how messy that code gets at -O3… it looks a lot messer than the -O2 code. (I think, it’s time, to say that “‘X considered harmful’ considered harmful”.)

dzaima 4y ago
-O2 doesn't have any usage of SIMD/vectorization though. Of course it'd be simpler.
- dietrichepp 4y ago
  ...Have you looked at the -O3 assembly that I'm talking about? There's a short SIMD loop, which is simple, and fairly easy to understand. At -O2, you get a short scalar loop, which is simple, and fairly easy to understand. If you were writing this function by hand, you might combine the SIMD loop with the scalar loop. That's not what happens, though. Instead, you get two versions of the SIMD loop which handle different alignments (unnecessary) and then, what appears to be an unrolled version of the scalar loop. What’s going on here is that there are a bunch of transformations enabled at -O3 that come along with autovectorization. You don’t just get autovectorization by itself, you also get transformation passes that are designed to put your code into a state where vectorization is easier. You also sometimes get a number of transformations which are (empirically) dubious, in the sense that the resulting code is both larger and slower.
  - dzaima 4y ago
    There's only one SIMD loop - a 128-bit one. There's a 64-bit SIMD segment for handling handling when the tail has ≥8 items (which is gonna be a pretty decent speedup for 8≤n≤15 byte inputs). If you're gonna operate on only very large inputs, it's quite unnecessary, yeah, but for a lowercasing function small inputs will be very common. The unrolling of the scalar tail is quite unnecessary though (gcc does so even with -fno-unroll-loops). clang doesn't[0], though it does unroll the main loop (though that can be disabled with -fno-unroll-loops). [0]: https://gcc.godbolt.org/z/n85aavnEo https://gcc.godbolt.org/z/n85aavnEo
    - dietrichepp 4y ago
      You're right, only two loops. It is still messy, though. And "it has SIMD" is not really a sufficient explanation for the messiness. I think of -O3 as a kind of "throw everything at the wall and see what sticks". You're pressing a button that makes your code big, messy, and fast (although not always big, not always messy, and not always fast). You can spend as much time as you like explaining the reasoning behind these code transformations, but in the end, there are very good reasons why people don't use -O3 as the default optimization level.

It’s more of a comment on how messy that code gets at -O3… it looks a lot messer than the -O2 code. (I think, it’s time, to say that “‘X considered harmful’ considered harmful”.)

dzaima 4y ago

-O2 doesn't have any usage of SIMD/vectorization though. Of course it'd be simpler.

dietrichepp 4y ago
...Have you looked at the -O3 assembly that I'm talking about? There's a short SIMD loop, which is simple, and fairly easy to understand. At -O2, you get a short scalar loop, which is simple, and fairly easy to understand. If you were writing this function by hand, you might combine the SIMD loop with the scalar loop. That's not what happens, though. Instead, you get two versions of the SIMD loop which handle different alignments (unnecessary) and then, what appears to be an unrolled version of the scalar loop. What’s going on here is that there are a bunch of transformations enabled at -O3 that come along with autovectorization. You don’t just get autovectorization by itself, you also get transformation passes that are designed to put your code into a state where vectorization is easier. You also sometimes get a number of transformations which are (empirically) dubious, in the sense that the resulting code is both larger and slower.
- dzaima 4y ago
  There's only one SIMD loop - a 128-bit one. There's a 64-bit SIMD segment for handling handling when the tail has ≥8 items (which is gonna be a pretty decent speedup for 8≤n≤15 byte inputs). If you're gonna operate on only very large inputs, it's quite unnecessary, yeah, but for a lowercasing function small inputs will be very common. The unrolling of the scalar tail is quite unnecessary though (gcc does so even with -fno-unroll-loops). clang doesn't[0], though it does unroll the main loop (though that can be disabled with -fno-unroll-loops). [0]: https://gcc.godbolt.org/z/n85aavnEo https://gcc.godbolt.org/z/n85aavnEo
  - dietrichepp 4y ago
    You're right, only two loops. It is still messy, though. And "it has SIMD" is not really a sufficient explanation for the messiness. I think of -O3 as a kind of "throw everything at the wall and see what sticks". You're pressing a button that makes your code big, messy, and fast (although not always big, not always messy, and not always fast). You can spend as much time as you like explaining the reasoning behind these code transformations, but in the end, there are very good reasons why people don't use -O3 as the default optimization level.