4 ms·

I think that the days where hand tuned assembly language outperform compiler generated code are largely behind us (let loose the contrary anecdotes). Compilers

• tubs 4y ago
  https://codegolf.stackexchange.com/questions/215216/high-throughput-fizz-buzz/236630#236630 https://codegolf.stackexchange.com/questions/215216/high-thr...
• makapuf 4y ago
  ... and yet in this article, the author beats by 10x a C compiled code with hand tuned assembly. (By using SIMD and unrolling, which the compiler did not. Granted linear compiler code is faster than hand made linear assembly)
  • zokier 4y ago
    Author beats compiler because floating point constraints, with -ffast-math compiler vectorizes the code.. I don't have arm64 hardware to test the result, but its probably again pretty fast: https://gcc.godbolt.org/z/xvjY8P4cM https://gcc.godbolt.org/z/xvjY8P4cM
• wolf550e 4y ago
  compiler autovectorization is poor, people often outperform it when writing SIMD code. intrinsics are so low level they might as well be assembly.
  • JonChesterfield 4y ago
    I've had really good results from the two in LLVM (one works on loops, one within basic blocks). Optimal loop body when the pointers had alignment metadata attached, though at the time it failed to unroll the tail. Using intrinsics with the control flow in C or C++ works really well - you get the right instruction selection from the intrinsics, easy to reason about control flow and the compiler deals with register allocation (and possibly instruction scheduling) which are a pain to do by hand.
• jcalvinowens 4y ago
  I think about it like this: If I ask you to write assembler faster than what the compiler emits for one very specific CPU model, you'll pretty much always be able to do that (given enough time). But as CPUs become more complex, and compilers get better, achieving that win requires more and more "overfitting" to implementation details of the specific hardware, in ways that are not helpful or even counterproductive on older or newer models of the same CPU family. It's still worth it sometimes, of course. It's just more work and a lower value proposition on average.
• ravi-delia 4y ago
  The only exception (pointed out in this post) is leveraging SIMD instructions, which aren't nearly as well exploited by compilers. I doubt, of course, that this will last all that long, but for now there are too many subtle differences that might matter and totally different instruction sets between cpus and even generations.
  • Agentlien 4y ago
    I feel like I've been hearing complaints that compilers aren't leveraging SIMD instructions for years. I wonder when this will be solved.
    • ravi-delia 4y ago
      Probably a decade after the interfaces stabilize and everyone figures out which minor quirks of behavior they're willing to permit with the right optimization flag. As of now things are highly dependent on platform- I've had great luck with the older x86 SIMD sets, but on ARM there's still a ways to go.
• rowanG077 4y ago
  I used to think that was true. Then I had a crypto course in uni which required us to write and optimize 3 different hashing and encryption algorithms. I was stunned by the first once, which I first did in C and then moved to ASM. The C code was pretty straightforward. But it was trivial to beat in ASM by something like 120%. That course taught me how bad compilers(Or rather GCC) are at high-level register optimization and using the barrel shifter. Basically all the performance I squeezed out of ASM was because the compiler just wasn't figuring basic stuff out. Mind you I was(am) not an ASM expert. That piece of code was the first thing I ever write in ASM. And yet I was able to easily beat a decades old world class compiler.
• userbinator 4y ago
  If you're optimising for size, you can still very easily beat the compiler.