[HN Gopher] Function multi-versioning in GCC 6 (2016)
___________________________________________________________________
Function multi-versioning in GCC 6 (2016)
Author : pkkm
Score : 21 points
Date : 2023-04-30 16:38 UTC (6 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| jeffbee wrote:
| Hopefully we are looking back at GCC ifunc as a mistake / warning
| to future civilizations. Indirectly dispatching functions via the
| PLT only makes sense for operations where the uarch
| specialization is sure to be profitable, like bulk cryptography
| or string ops statically determined to have large inputs. But
| dispatch to a specialized AVX memcpy for inputs of unknown length
| in not profitable. The dispatch mechanism costs more than the
| specialization saves. Unfortunately ifunc usually looks great on
| microbenchmarks and the drawbacks don't become apparent until
| observed in a full-scale program.
| dundarious wrote:
| I'm an "auto-vectorization skeptic" in many ways, but it's also
| the case that there will be other parts of your program that
| will benefit from being able to generate (for example) AVX2
| instructions beyond a few specialized functions.
|
| If there is to be a CPU-specific dispatch mechanism, it should
| be more like a small binary/shell script that exec-s an
| entirely CPU-specific binary, dependent on runtime detection
| (cpuid, etc.). Dependent on your distribution mechanism, you
| might only download the appropriate binary. But if you do this,
| please remember to keep your binary sizes reasonable.
| saagarjha wrote:
| This doesn't make sense to me. memcpy is typically called
| through the PLT anyways; all the ifunc does is change what it
| points at. Even if there was some extra cost here one indirect
| call is not that expensive?
___________________________________________________________________
(page generated 2023-04-30 23:01 UTC)