4 ms·

> This is a lot like the ages-old trick of a compiler being rigged to recognize particular source file (benchmark program) and pulls out a hand-optimized assemb

> This is a lot like the ages-old trick of a compiler being rigged to recognize particular source file (benchmark program) and pulls out a hand-optimized assembly program. I never knew compilers did this, but I remember it being the case for some games (There was a debacle once upon a time where renaming 'Quake3.exe' to 'Quack3.exe' would reveal such shenanigans on some drivers.)

dotnet00 4y ago
This is still the case with games, pretty much every new big release comes with an associated 'game ready driver' release where the driver can detect and adjust some behaviors to better suit that game.
- kazinator 4y ago
  But that provides a real benefit whereas the compiler trick's objective is to look good in a benchmark.
remram 4y ago
A less-evil example is that most compilers can recognize when you wrote a memcpy() and replace it with an actual memcpy() call, which is usually very carefully optimized for your specific processor. This can cause fun issues like your version of memcpy() (e.g. embedded libc) being replaced by the compiler with a call to itself: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
- tialaramex 4y ago
  The ability to figure out what you're doing and then just do that well, rather than attempting to optimise the code you wrote is called Idiom Recognition and has been around for a very long time, like, 1970s or maybe before. A relatively modern example was people writing code to count set bits in a value, because older languages don't provide an intrinsic to do that and it's often useful, these days your CPU probably has a CPU instruction specifically for that, it's called "popcount" (sometimes spelled popcnt) and so it's valuable to recognise what's going on in the say six lines of C++ in your program and emit a single POPCOUNT instruction instead. If your fancy method to count bits isn't recognised your program goes slower. The memcpy case is special because C is weird in actually trying to define this as a function, copying memory is so commonly necessary that compilers need to have a pre-baked implementation for the rest of what they do anyway, it's not a surprise that idiom recognition results in your custom memcpy being turned into the built-in memcpy, although in the case you linked that's indeed a bug.
- kazinator 4y ago
  That's due to the run-time and compiler being different projects. In Lisps it's not unusual to see (defun car (x) (car x)). Arguably, memcpy belongs in libgcc and not the C library. Glibc should not have to do anything in regard to memcpy, other than include the right compiler header in its stdlib.h.

dotnet00 4y ago

This is still the case with games, pretty much every new big release comes with an associated 'game ready driver' release where the driver can detect and adjust some behaviors to better suit that game.

kazinator 4y ago
But that provides a real benefit whereas the compiler trick's objective is to look good in a benchmark.

remram 4y ago

A less-evil example is that most compilers can recognize when you wrote a memcpy() and replace it with an actual memcpy() call, which is usually very carefully optimized for your specific processor. This can cause fun issues like your version of memcpy() (e.g. embedded libc) being replaced by the compiler with a call to itself: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

tialaramex 4y ago
The ability to figure out what you're doing and then just do that well, rather than attempting to optimise the code you wrote is called Idiom Recognition and has been around for a very long time, like, 1970s or maybe before. A relatively modern example was people writing code to count set bits in a value, because older languages don't provide an intrinsic to do that and it's often useful, these days your CPU probably has a CPU instruction specifically for that, it's called "popcount" (sometimes spelled popcnt) and so it's valuable to recognise what's going on in the say six lines of C++ in your program and emit a single POPCOUNT instruction instead. If your fancy method to count bits isn't recognised your program goes slower. The memcpy case is special because C is weird in actually trying to define this as a function, copying memory is so commonly necessary that compilers need to have a pre-baked implementation for the rest of what they do anyway, it's not a surprise that idiom recognition results in your custom memcpy being turned into the built-in memcpy, although in the case you linked that's indeed a bug.
kazinator 4y ago
That's due to the run-time and compiler being different projects. In Lisps it's not unusual to see (defun car (x) (car x)). Arguably, memcpy belongs in libgcc and not the C library. Glibc should not have to do anything in regard to memcpy, other than include the right compiler header in its stdlib.h.