Hacker News Reader

Comment by lukeh | Hacker News Reader

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.

View on HN

The 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

How do you write a competing BLAS? Presumably, you need to reverse engineer these to be competitive with Apple's solution.

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

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

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

Not really - they change things much more rapidly, and communicate those changes, but don’t arbitrarily ‘break’ them.

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

They absolutely can and actively do.

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

Since when does Apple care if they are blamed?

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

it 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?

Accelerate.framework uses them today, and provides a public interface.

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

Reply on news.ycombinator.com