3 ms·
In my opinion, the worst long-term consequence will be that even having newer CPUs with the issues fixed in hardware, we'll have a performance impact because of
by faragon 9y ago
In my opinion, the worst long-term consequence will be that even having newer CPUs with the issues fixed in hardware, we'll have a performance impact because of code compiled to work with both old and new CPUs. Just like the case of having a new CPU with fancy features unused because of code compiled to be backwards compatible.
- josefx 9y agoIntels C compiler could generate code that detects CPU features at runtime years ago, I think the current GCC can do the same. Binaries only have to become a bit more bloated to store both versions of the compiled code.
- faragon 9y agoRuntime checks cost CPU cycles as well.
- em3rgent0rdr 9y agoThe runtime check only needs to be done one during program execution.
- faragon 9y agoSo you mean having two executables in one? A la Apple "fat executables"?
- davidcuddeback 9y agoProbably something like a table of function pointers for "hot" code that gets setup at program start. But compiler writers are way more clever than I am at this sort of thing, so I'm actually curious what solutions they came up with.
- jabl 9y agoNo, it's on a per-function basis. On program startup it does the necessary checks (CPUID etc.) and sets up the function pointers appropriately (see the IFUNC mechanism in the linker). See e.g. https://lwn.net/Articles/691932/ https://lwn.net/Articles/691932/
- davidcuddeback 9y agoThanks! I was trying to find some information on this, but didn't know the right search terms.
- faragon 9y agoThat's OK for code e.g. you know it could benefit from SIMD usage. However you can not tag every function of user code for safe/unsafe mode. Also, optimizations would increase the mess (inlining, unrolling, etc.). Generated code would be a "Frankenstein".
- deleted 9y ago[deleted]