[Accepted] SE-0277: Float16

Evolution Announcements
1

The review of SE-0277 — Float16 has concluded and the proposal is accepted.

Thanks to everyone who participated!

Ben Cohen
Review Manager

15 Likes
2

I tried to use Float16 today in Xcode 12.5 (Swift 5.4) on macOS 11.3, and…it doesn't work. According to Apple's docs it's in the Swift Standard Library. But if I write:

let f: Float16 = 1

I get 'Float16' is unavailable in macOS. If I grep through Xcode.app/, I find x86_64-apple-macos.swiftinterface:

@available(macOS 11, iOS 14, tvOS 14, watchOS 7, *)
@available(macOS, unavailable)
@available(macCatalyst, unavailable)
@frozen public struct Float16 {
  @_transparent public init() {
    fatalError("Float16 is not available")
  }
}

My macOS app targets only macOS 11.

I'm not at all sure how I can use it.

1 Like
3

It has been made unavailable specifically for macOS on x86 because LLVM doesn't have a stable ABI for Float16 on x86 (waiting on Intel, as I understand) and Swift’s ABI needs to be stable on that platform.

2 Likes
4

Exactly.

It's supported on Apple Silicon because we have a stable ABI for Float16 on ARM64. It's supported on Windows and Linux because we don't need binary stability on those platforms. But Intel has to define the calling conventions in the x86_64 ABI document and implement them in LLVM before we can make it available in the SDK for macOS on x86.

Note that there is no hardware support for Float16 arithmetic on Intel, so you are better off using Float for computation anyway. You can convert between half-precision storage and Float using vImage bulk conversion routines, which are well-optimized and take advantage of F16C conversion support available in Ivybridge and later CPUs: vImageConvert_PlanarFtoPlanar16F and vImageConvert_Planar16FtoPlanarF.

3 Likes
5

Is there really no mechanism for specifying “this is not yet ABI stable”?

I would expect something similar to the @_alwaysEmitIntoClient attribute to allow the use of Float16.

If there’s really no such capability, I might suggest a spelling along the lines of @abiStable(macOS 9999). Then on versions below the one listed, as well as any other platforms not listed, the declaration would be emitted into the client.

6

The mechanism for specifying "this is not yet ABI stable" is for a package to provide an implementation rather than the SDK. I haven't reviewed it carefully, but @SusanCheng has one (GitHub - SusanDoggie/Float16) that would be a good place to start. The SDK, by its nature, is always binary-stable.

alwaysEmitIntoClient "works" for the operations, but not for the type metadata and protocol witnesses¹. In addition, any third party libraries that used the type would not have stable calling conventions, contra expectations for the platform.

¹ This is something that should be supported eventually, but it's not today, so.

3 Likes
7

This is a very interesting discussion. :face_with_monocle:

3 Likes
8

Hmm, I might have to do that.

In my case I'm working with very large elevation data that comes in the form of SInt16 one-component pixels in a GeoTIFF file. Sadly, Core Image doesn't support this, and there seems to be no good way to get it into a form that's usable. DTS had suggested working in Fh, but there were only vImageConvert_ calls from S16 to F, and I thought I'd have to do it myself.

The real problem is loading the data, since looking at the full extent can be done reasonably quickly only if you skip pixels and load a decimated version. So I will just do the conversion as I load.

1 Like
9

Apologies for bringing back an old thread, but I believe this is the best place to do so.

Currently checking out the use of Binary16/Float16/float16/_Float16 within a simple swift project to evaluate half precision GEMM. With that comes the use of Float16.

I'm testing on an older platform due to HW availability (Haswell, 2015 MBPr 15).

I've run into the same "issue" as [Accepted] SE-0277: Float16 - #2 by JetForMe, namely that macOS on x86 does not have native arithmetic support for Float16, only the f16c instructions. At the same time, x86-64 has now stabilized _Float16 within the x86-64 ABI, which was raised as the reason to not support Float16 at launch.

Checking for the version of clang/llvm that swiftc is using:
[~/developement]$ swiftc --version swift-driver version: 1.62.15 Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51) Target: x86_64-apple-macosx12.0

And checking the docs for clang14 (Clang Language Extensions — Clang 14.0.0 documentation) demonstrates that for Clang14, AVX512FP16 is required for FP16 support on x86-64

This is in contrast to clang 15 (Clang Language Extensions — Clang 15.0.0 documentation) which introduced SSE2 based softfloat support for FP16 arithmetic.

Since swift/clang for MacOS 12 seem to no longer be receiving feature development, instead being bugfixes only, fair to assume I'm DoA for testing BNNS on this older machine?

1 Like
10

Is this still an issue?

1 Like