3 ms·
The converse is also deserving of a 'sadly': the new hardware features can be widely available but still hard to use since they are not going to be used by plat
by kzrdude 4y ago
The converse is also deserving of a 'sadly': the new hardware features can be widely available but still hard to use since they are not going to be used by platform defaults when you compile your program.
- stephencanon 4y agoF16C has been available for well over a decade (it was introduced in the Ivybridge uArch), and the equivalent conversions are supported on all ARMv7 CPUs since around the same time (and all ARMv8 CPUs unconditionally); most software should be able to safely assume their availability by now. There exist some niches where this doesn’t hold, but that’s why we have software fallbacks.
- corsix 4y agoThe first niche that came to mind was x86 code running under Rosetta 2; despite ARM having an equivalent to F16C, Rosetta 2 doesn’t translate AVX, and F16C doesn’t have a non-AVX encoding.
- stephencanon 4y agoIndeed. Worth noting that Accelerate.framework provides fast and correct bulk f16 <-> f32 conversions as `vImageConvert_Planar16FtoPlanarF` and `vImageConvert_PlanarFtoPlanar16F`, and that the arm conversion instructions are unconditionally available for apps that compile for arm64 (they're part of the base ARMv8 ISA), so any _new_ code shouldn't need to worry about this.