4 ms·

Another pro is that it's often possible to beat the performance of said compilers in places where that matters if you're willing to put enough time into it.

bluGill 4y ago
Sure, but by the time you do the CPU manufactures have come out with a different CPU with different ideal optimizations. If your code is compiled you just flip a switch on the compiler and your code is now better optimized for the new CPU than your previously well optimized code. If this really matters you can compile several hundred different versions of your code for the several hundred different X86 variants out there. And if management wants to try ARM, compiled code it is just a small change to your compiler to do that, again possibly hundreds of different executable for all the ARM variants if you feel the need.
PaulDavisThe1st 4y ago
12 years ago, we used asm for the inner loop that does peak metering in Ardour. It is essentially doing a greater_than comparison on every single sample that passes through the program, which could potentially be millions per second. Using SIMD instructions directly from asm with a not-small buffer size reduced the CPU cost by 30%. Last year, someone was updating this code to include ARM and some newer SIMD instruction sets. We discovered that in that time period, gcc has gotten to the point where even our hand-crafted asm is barely any better (and in some cases worse) than gcc's own generated code. Compilers improve!
- sylware 4y ago
  It depends where you draw the complexity lines: some will prefer to do anything otherwise than to depend on those grotesquely and absurdely massive and complex compilers: Rube Goldberg Machine Syndrom.
- StillBored 4y ago
  Its true that compilers improve, but i would be willing to bet that if you took the C code and ran it on the original machine there is a good chance that the assembly would out perform it. Hand optimized assembly doesn't necessarily age well, because a large part of the skillset is conforming the code to the processor micro-architecture. Compilers do a lightweight version of this with the -mtune where they utilize tables reflecting the number and type of functional units, instruction latency and throughput, etc to make various tradeoffs in instruction selection and/or placement. The usual "simple" example is a memcpy operation. There are about a dozen different ways (int register moves, utilizing vectors of various sizes, nontemporal, rep movXX, etc) to implement it, and depending on processor, memory subsystem, alignment, and transfer size there can be significant perf diffrences when picking one alternative over another even before considering whether to try prefetch hints, strip mining, or any of the other things that can made a difference. Bottom line, just like playing with differing compilers, and compiler options can easily provide a 2-5x uplift its likely that an expert assembly programmer can gain that much or sometimes significantly more (because they can fundamentally change the algorithm) against a compilers best output, there remain a fair number of things that can be done with hand tuning that compilers simply aren't yet capable of. Since your using SIMD the compiler could be beating it simply because its utilizing one of the wider vector instruction sets vs the original code. Although, for a software package where you don't know the final machine much of this becomes more difficult unless your willing to have a half dozen optimization targets selected at runtime. Bottom, line if it matters that much, there are still people who can take the best code you get out of a C/C++ compiler and generally provide an uplift. Whether its worth the effort, that is another question.
  - ajb 4y ago
    So, I used to do this for a living. The main reasons assembler worked better were: - The compiler had to make conservative assumptions. Less true now you have things like restrict pointers - The compiler didn't know how to do SIMD. Now it can with intrinsics. - The compiler didn't know how to do the necessary transforms to make use of in-order cores. out-of-order makes the cpu do this itself, and is making its way down to smaller processors.
salawat 4y ago
Isn't this mo ponger an issue with things like Godbolt? When you can actually plug in and see what you get out to vet for correctness, I'd think there shouldn't be as much need to per se ignore the compiler.
sylware 4y ago
Indeed, usually it would be appropriate only in very specific places, and if it _really_ needs to be chip implementation specific, you could install specific machine code for those implementations. This is not perfect, but in all cases, it is much less worse than to depend on compilers like gcc/clang.

bluGill 4y ago

Sure, but by the time you do the CPU manufactures have come out with a different CPU with different ideal optimizations. If your code is compiled you just flip a switch on the compiler and your code is now better optimized for the new CPU than your previously well optimized code. If this really matters you can compile several hundred different versions of your code for the several hundred different X86 variants out there. And if management wants to try ARM, compiled code it is just a small change to your compiler to do that, again possibly hundreds of different executable for all the ARM variants if you feel the need.

PaulDavisThe1st 4y ago

12 years ago, we used asm for the inner loop that does peak metering in Ardour. It is essentially doing a greater_than comparison on every single sample that passes through the program, which could potentially be millions per second. Using SIMD instructions directly from asm with a not-small buffer size reduced the CPU cost by 30%. Last year, someone was updating this code to include ARM and some newer SIMD instruction sets. We discovered that in that time period, gcc has gotten to the point where even our hand-crafted asm is barely any better (and in some cases worse) than gcc's own generated code. Compilers improve!

sylware 4y ago
It depends where you draw the complexity lines: some will prefer to do anything otherwise than to depend on those grotesquely and absurdely massive and complex compilers: Rube Goldberg Machine Syndrom.
StillBored 4y ago
Its true that compilers improve, but i would be willing to bet that if you took the C code and ran it on the original machine there is a good chance that the assembly would out perform it. Hand optimized assembly doesn't necessarily age well, because a large part of the skillset is conforming the code to the processor micro-architecture. Compilers do a lightweight version of this with the -mtune where they utilize tables reflecting the number and type of functional units, instruction latency and throughput, etc to make various tradeoffs in instruction selection and/or placement. The usual "simple" example is a memcpy operation. There are about a dozen different ways (int register moves, utilizing vectors of various sizes, nontemporal, rep movXX, etc) to implement it, and depending on processor, memory subsystem, alignment, and transfer size there can be significant perf diffrences when picking one alternative over another even before considering whether to try prefetch hints, strip mining, or any of the other things that can made a difference. Bottom line, just like playing with differing compilers, and compiler options can easily provide a 2-5x uplift its likely that an expert assembly programmer can gain that much or sometimes significantly more (because they can fundamentally change the algorithm) against a compilers best output, there remain a fair number of things that can be done with hand tuning that compilers simply aren't yet capable of. Since your using SIMD the compiler could be beating it simply because its utilizing one of the wider vector instruction sets vs the original code. Although, for a software package where you don't know the final machine much of this becomes more difficult unless your willing to have a half dozen optimization targets selected at runtime. Bottom, line if it matters that much, there are still people who can take the best code you get out of a C/C++ compiler and generally provide an uplift. Whether its worth the effort, that is another question.
- ajb 4y ago
  So, I used to do this for a living. The main reasons assembler worked better were: - The compiler had to make conservative assumptions. Less true now you have things like restrict pointers - The compiler didn't know how to do SIMD. Now it can with intrinsics. - The compiler didn't know how to do the necessary transforms to make use of in-order cores. out-of-order makes the cpu do this itself, and is making its way down to smaller processors.

salawat 4y ago

Isn't this mo ponger an issue with things like Godbolt? When you can actually plug in and see what you get out to vet for correctness, I'd think there shouldn't be as much need to per se ignore the compiler.

sylware 4y ago

Indeed, usually it would be appropriate only in very specific places, and if it _really_ needs to be chip implementation specific, you could install specific machine code for those implementations. This is not perfect, but in all cases, it is much less worse than to depend on compilers like gcc/clang.