Can you just treat these values as a uint16 on the Go side?

Without CPU support for float16 I would be worried that the type would be a trap: it would seem more efficient but would actually be much slower in practice.

To detail the answer above, you could probably use a type alias to solve your problem, namely

package "something/something/gpu"
// 
type Float16 = int16
// or, perhaps, for easy addressing
type Float16Bytes = [2]byte

ianlancetaylor.
Can you just treat these values as a uint16 on the Go side?
Yes, i can treat them as uint16 on the go side, but i currently have no way to convert the float32 -> uint16 representation of a float16. As i recall it would then be something like:
Last bit: Sign.
2nd - 9th last bit: Exponent.
Rest: Mantissa.

Without CPU support for float16 I would be worried that the type would be a trap. You are probably correct. It could easily lead to issues if it was made into a standard type.

beoran.
That could also be done, though i do think it would make sense to make a built in function to convert these, especially considering how popular GPU work has become.

Bitshifting ain't easy! ;)

I guess my proposal should have been:
A function that converts float32/64 -> float16(uint16) and float32/64 <- float16(uint16) for GPU work.

What about adding float16 to some sort of unsafe package?

@gjvnq I don't understand what problem that would solve.

It seems like the missing piece (besides actually adding a float16 type to the language) is a conversion function from float32/float64 to float16 if you don't do the arithmetic in Go itself but use some GPU language. Would a software conversion be too slow?

I just did a benchmark comparison between casting a float64 -> float32 and float32 -> float16.

The float16 conversion is based on: https://github.com/h2so5/half/blob/master/float16.go

BenchmarkFloat64CastToFloat32-8 2000000000 0.34 ns/op
BenchmarkFloat32ConvertToFloat16-8 500000000 3.63 ns/op

Note: Conversion/Casting happens in a function call and benched on i7-6820HQ with GC disabled.

The float16 conversion is not that slow, although it could be faster. Any thoughts on improving it?
@ianlancetaylor "I don't..:", by adding an optimized float16(somef32) casting function, thoughts?

@griesemer I guess that depends on the situation. If bandwidth is an issue, then spending some more time on CPU conversion isn't necessarily a bad thing, especially if you have some time left over before sending the data to the GPU.

Thanks for replying quickly. It looks like software float16 conversion might be acceptable if there are not too many to be done on the CPU (and I suspect the conversion can be sped up with some tricks, especially if the actual number range is limited, and perhaps with the use of assembly).

As @ianlancetaylor mentioned, without widespread CPU support for 16bit floats, having a float16 may not be justified. There doesn't seem to be wide-spread demand for it either.

We aren't going to add this type to the language without widespread hardware support for it.