The machine learning space probably has the easiest time to adopt a new number format. The players are big enough to define their own silicon and training/inference don't even need the same number format. As long as it works on their new specialized training hardware it's good to go.

The real challenge is probably in the power efficiency. As far as I know right now power consumption is the biggest cost factor when training new models. Everything else seems like a minor trade-off but when accounting for the power consumption there is real money involved.

Hardware is not cheap either at this scale. Reallly rough math follows, please anyone correct me if I err. A100 cards are >$10,000 each. A node is typically 8 and a cluster might be 64 A100s. So about a million in hardware for the medium cluster of 64 A100s. (Cross checking, a machine from lambda labs is apparently ~175k for 8 gpus, so 1.4m for the cluster above)

Those A100 use 300watts each, plus let’s say 500watts for the rest. (8gpus300+500)8servers ≈ 25Kw * 8760 hours = 219k KwH / year. So if your costs are $0.15/KwH that’s only on the order of $32k/year.

I see your numbers with the A100. However, consider the 3090 which is down to $1000 and uses 350W. Double that if you consider cooling and overhead in a data center. In Europe the electricity prices are through the roof and easily cost >0.5$/kWh. If you use those numbers a single card would cost you 0.35kW * 2 * 0.5$/kWh * 24h * 365 = 3066$ per year. So I guess it highly depends on your specific location and circumstances.

It’s still more complicated because you have to amortize costs over several years and then also keep in mind that big players will design their own hardware to avoid the A100 cost and energy. Disks and other devices will also consume power. And you datacenter cooling is now more expensive, etc.

Yes, it’s complicated, for sure. But if we amortize over 3 years, and triple costs for the power: it’s ~500k/yr for hardware and ~100k/yr for power.

In terms of TPUs or other custom accelerators, sure, they exist. However most definitely aren’t building their own hardware.

ETA: I’m not saying power is irrelevant, it clearly matters. But saying it’s the dominant financial constraint is clearly wrong, at least below Google/Amazon/Apple scale. Never mind the cost of the people running these trainings!

It might. The whole reason behind gamma correction is human brightness perception is logarithmic. By having more resolution at lower values, posits could correct for the reason we need in gamma in the first place, though maybe, not as well as gamma itself.

But if it mitigates error accumulation in perceptually-friendly ways, it might still have value in calculations (once there’s native support).

I've been studying color theory (its harder than you would think) on my spare time; and I did my undergraduate thesis was on posit few years ago. I think using posits may be a good idea to compress the luminosity, but I'm not sure how good it would be for the ab on a Lab-like format.

A format close to the cone fundamentals, like XYZ, could have benefits being encoded in some kind of non-standart posit.

I'll add this into the stack of things I eventually I'll look into.

1. IEE754 floats are already nonlinear. The precision is the highest around zero.

2. Bitmap images are not using floating-point values, except in some super niche use cases like GIS data, so “posits” are irrelevant for the use case you’ve posited. (ba-dum-ts)

3. Non-linear gamma is completely unnecessary for bit depths >= 16.

Floating point bitmaps are a lot more common than you think. A lot of consumers don't see them, but their software will internally use floats. Floating point bitmaps are standard practice in visual effects and animation. The OpenEXR format exists for the exchange of images with floating point bit depths up to 32.

Posit always have more precision than a IEEE floating with same number of bits because it has more bits for the mantissa.

Posit would likely enable to better compression with Huffman encoding.

If point 1 is true then why is 0.1 + 0.2 = 30000000000000004? Is that not close enough to zero?

Edit: It seems I’m conflating “precision” with “accuracy”, which is a separate concept in math.

That result happens for the same reason that 1 / 3 * 3 != 1, if you use decimal: 1 / 3 = .333, .333 * 3 = .999, which is different from 1.00.

0.1 is the same as 1 / 10, which does not have a finite representation in binary notation, just as 1 / 3 does not have a finite representation in binary or decimal notation.

This is a problem for all number systems. The true issue here is not a precision in the underlying bit representation of IEEE-754, it's that 0.1 and 0.2 aren't actually a valid IEEE-754 numbers, and so they get casted to their best approximations.