> This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely

> This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely on their exact behaviour. The vendors really only expect you to use their API (Vulkan/Metal/Direct3D/etc) because that abstraction layer allows them to radically and incompatibly change their hardware on a regular basis to improve performance or functionality. GPUs are external processors, that require DMA transport, and can perform useful jobs in parallel with the CPU, and are produced by multiple vendors. This almost certainly requires a HAL, and there's little impact of making dynamic libraries calls compared to the benefit received. Compare this to a co-processor, that basically can be called directly from CPU instructions, without DMA and a remote instruction queue. Something like this gains great benefits from a compiler intrinsic, as a function call, particularly as a dynamic library is quite expensive. This compiler intrinsic can just map to bitcode, which can then map to whatever at compile-time on the app store deployment side. Why would people not want this option? Why should this only be available to Apple's internal products? Why should Photoshop/Lightroom/Blender/physics simulation/video encoding/AAA Games etc. run slower? There's no excuse for Apple not providing a way to use these instructions, either via bitcode, or providing a mechanism to detect relevant CPU metadata. At a minimum, I expect hackers to take advantage of this to speed up their own applications, as well as open source forks.