They're not really "grafting" it, they're implementing it as a first-class data type.
Intel Prepares to Graft Google’s Bfloat16 onto Processors
11–20 of 138 posts
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#12I am sorry for Intel. Perhaps John Gustafson’s 16 bit posits or unums would have made a better choice.
Why? Google has certainly researched their floats before committing an entire line of silicon chips. It's easy to just enumerate all possible float16 configurations in a simulator to see which one performs best on a wide range of neural network applications. Then pick the best one. Big data driven organizations do this all the time (brute force through an entire line of solutions, pick best results).
[deleted]
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#13I am sorry for Intel. Perhaps John Gustafson’s 16 bit posits or unums would have made a better choice.
Why? Google has certainly researched their floats before committing an entire line of silicon chips. It's easy to just enumerate all possible float16 configurations in a simulator to see which one performs best on a wide range of neural network applications. Then pick the best one. Big data driven organizations do this all the time (brute force through an entire line of solutions, pick best results).
Also, a format that's just a slight tweak on IEEE-754 is going to be way easier to implement on existing hardware than a wholly new format.
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#14Something about Google being able to influence features in consumer grade CPUs rubs me the wrong way.
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#15It looks somewhat similar to the minimal size of compact float [1] (a format I developed for data communication), but with 2 more bits because I use them for sizing.
[1] https://github.com/kstenerud/compact-float/blob/master/compa...
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#167 bits of precision.... or 2.1 decimal digits. So not quite as good as a 6-inch slide rule. Edit: voters in this thread seem pretty uptight.
What would be the wattage of a typical six inch slide performing calculations as quickly as a top-of-the-line Intel microchip? Or if it would be physically impossible because of speed of light considerations, what would be the wattage of n slide rules in parallel performing such computations such that it adds up to the throughput of a microchip?
Speaking of boiling the ocean . . .
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#17Wait, this was supposed to be the future of floating points: https://www.nextplatform.com/2019/07/08/new-approach-could-s...
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#18> At this point, Intel doesn’t have bfloat16 implemented in any of its processors, so they used current AVX512 vector hardware present in its existing processor to emulate the format and the requisite operations. According to the researchers, this resulted in “only a very slight performance tax.”
Why implement bfloat if you get just slightly less performance emulating it with AVX512, which already exists? Maybe it’s an “us too” claim?
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#19Something about Google being able to influence features in consumer grade CPUs rubs me the wrong way.
Not surprising though, new features shows up where there's money to make.
Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors
#20I am sorry for Intel. Perhaps John Gustafson’s 16 bit posits or unums would have made a better choice.
Why? Google has certainly researched their floats before committing an entire line of silicon chips. It's easy to just enumerate all possible float16 configurations in a simulator to see which one performs best on a wide range of neural network applications. Then pick the best one. Big data driven organizations do this all the time (brute force through an entire line of solutions, pick best results).
I know nothing about ASIC or CPU simulators but I suspect that it's not as easy as you make it sound: for machine-learning related tasks, performance doesn't only come from raw compute numbers: you'll also want to model the actual data movement costs across the caches hierarchy and registers. Because a lot of time training is not necessarily compute-bound: the relative cost of data transfer (VS compute) can be quite high, or even dominate.