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.
The hacky code runing right inside the phones detecting objects, identifying faces and whatnot is often called AI.
Should have always been called "fancy algorithms" from the get-go, calling it "intelligence" opens the interpretation up for a world of misunderstandings
How do you do squinting between an engineered process and a discovered relationship. Because the neural networks are much closer to discovered than engineered.
>Because the neural networks are much closer to discovered than engineered
So is most code. Programmers in general can't engineer for shit, (half blindly) guided trial and error is the most common development paradigm
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.)
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
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.
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.
This is actually a common mode of breakage of standard vision models.
It's like saying face recognition didn't recognized when you photoshopped a ear in the photo.