6 ms·

When Apple have decided not to document an instruction set to give them freedom to change it, I don't think they will cry about breaking your application in the

When Apple have decided not to document an instruction set to give them freedom to change it, I don't think they will cry about breaking your application in the next hardware version. 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.

uncledave 6y ago
Exactly this. You buy hardware for the API that ships with the software on it these days.
- simonh 6y ago
  Or if you do choose to rely on implementation details of specific hardware, you have to take on responsibility for managing breaking changes yourself. e.g. Implementing your own compatibility checks and fallback code paths, or knowing you will have to tweak and recompile for each hardware version.
h0l0cube 6y ago
Problem is that these matrix instructions are way more useful that the use cases they've catered for in their library. You could have a library that has a function call for each matrix instruction, but that's not worth the penalty of a function call. If your game, graphics software, physics simulation, render farm, video encoder etc can get a boost from these commands, it should be permitted, not just the software that Apple makes. Not sure why people are hostile to this.
h0l0cube 6y ago
> 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.

uncledave 6y ago

Exactly this. You buy hardware for the API that ships with the software on it these days.

simonh 6y ago
Or if you do choose to rely on implementation details of specific hardware, you have to take on responsibility for managing breaking changes yourself. e.g. Implementing your own compatibility checks and fallback code paths, or knowing you will have to tweak and recompile for each hardware version.

h0l0cube 6y ago

Problem is that these matrix instructions are way more useful that the use cases they've catered for in their library. You could have a library that has a function call for each matrix instruction, but that's not worth the penalty of a function call. If your game, graphics software, physics simulation, render farm, video encoder etc can get a boost from these commands, it should be permitted, not just the software that Apple makes. Not sure why people are hostile to this.

h0l0cube 6y ago

> 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.