6 ms·
I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As
by lukeh 6y ago
I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As long as done in a manner that is not anticompetitive, I don't see the problem.
- deleted 6y ago[deleted]
- toxik 6y agoLike private APIs, they ultimately transfer power from consumers to Apple. They surely do have documentation internally, they just don’t want to commit to anything.
- lumost 6y agoit limits Assembler access and tools written against that particular instruction, but does it really create a closed API? Surely apple will release libraries that make use of it internally with appropriate compatibility guarantees. Is it inherently wrong for a hardware vendor to make a high-level C api the interface?
- my123 6y agoAccelerate.framework uses them today, and provides a public interface.
- deleted 6y ago[deleted]
- josefx 6y agoSupport for different OSes might be interesting given that the C libraries mentioned seem to be Apple OSes only. Then the issue of having hidden instructions for high performance computation when CPU vendors have a history of bad performance/security tradeoffs. Other than that some languages have a bad time interacting with C or a high overhead when calling C functions.
- vbezhenar 6y agoWhat’s wrong with releasing documentation clearly stating that those instructions are not guaranteed to be present in the future? Apple does not hesitate to break compatibility anyway.
- colejohnson66 6y agoExhibit A is Windows. Microsoft publishing APIs and saying not to rely on them doesn’t work. Sure, Apple doesn’t care about backwards compatibility like Microsoft, but Apple will be blamed for breaking changes; They already are every time they change things.
- Ericson2314 6y agoSince when does Apple care if they are blamed?
- _-___________-_ 6y agoReleasing documentation makes them de facto public APIs. People will code against them anyway, apps will break when Apple changes the not-really-private APIs, and Apple will get blamed.
- Ericson2314 6y agoThis isn't the Windows ecosystem. Apple breaks everything all the time, and there's hardly a squeal. There is no company less afraid of "de facto stable" than Apple.
- zepto 6y agoNot really - they change things much more rapidly, and communicate those changes, but don’t arbitrarily ‘break’ them.
- phone8675309 6y agoIn that case they can do what they do for iOS apps - scan for the use of those instructions in any binary released through the App Store and refuse the update if they are used. Apple can't control random software people download off the Internet.
- GeekyBear 6y agoThe point of the Accelerate.framework is that it is the API and also abstracts away hardware differences between the processors of macOS, iOS, tvOS, and watchOS devices. >Accelerate provides high-performance, energy-efficient computation on the CPU by leveraging its vector-processing capability. The following Accelerate libraries abstract that capability so that code written for them executes appropriate instructions for the processor available at runtime https://developer.apple.com/documentation/accelerate https://developer.apple.com/documentation/accelerate
- dooglius 6y agoHow do you write a competing BLAS? Presumably, you need to reverse engineer these to be competitive with Apple's solution.