Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Prepares to Graft Google’s Bfloat16 onto Processors

nextplatform.com

Post reply on HN
Print view View original

31–40 of 138 posts

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#31

Post by smitty1110 »

jchw wrote: post #24
eatbitseveryday wrote: post #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…

They did not specify what the tax was relative to. Maybe they meant relative to 32-bit float? AVX512 is expensive. I believe if you have an AVX512-heavy workload it can cause the processor to throttle.

Yes, there’s a bios setting to control this. It basically under clocks the core while AVX units are under load.

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#32

Post by TomVDB »

dnautics wrote: post #27
TomVDB wrote: post #10

Earlier quoted context omitted.

For the same number of bits, posits are quite a bit more expensive to implement in terms of area than traditional floats.

That's not true, as I have implemented both, in FPGA. The INRA implementation missed key optimizations in the adder and multiplier.

The INRIA paper was indeed my reference.

It seems like a huge mistake if they missed key optimizations, but I'm happy to take your word for it.

Are there write-ups that go in detail about these mistakes? It's the kind of somebody-is-wrong-on-the-Internet topic that would result in flaming blog posts. :-)

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#34

Post by jdsully »

TomVDB wrote: post #32
dnautics wrote: post #27

Earlier quoted context omitted.

That's not true, as I have implemented both, in FPGA. The INRA implementation missed key optimizations in the adder and multiplier.

The INRIA paper was indeed my reference. It seems like a huge mistake if they missed key optimizations, but I'm happy to take your word for it. Are there write-ups that go in detail about these mistakes? It's the kind of somebody-is-wrong-on-the-Internet topic that would result in flaming blog posts. :-)

That paper used High Level Synthesis which would be the equivalent of coding something in ruby and comparing it with another algorithm written in optimized assembly.

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#36

Post by celrod »

smitty1110 wrote: post #31
jchw wrote: post #24

Earlier quoted context omitted.

They did not specify what the tax was relative to. Maybe they meant relative to 32-bit float? AVX512 is expensive. I believe if you have an AVX512-heavy workload it can cause the processor to throttle.

Yes, there’s a bios setting to control this. It basically under clocks the core while AVX units are under load.

Taking my 7980xe as an example: When it runs non-avx512 loads, I currently have it set to run at 4.1 GHz (all-core). When running avx-512 heavy loads, it instead runs at 3.6 GHz -- and tends to get much hotter (70-80C instead of 50-60C). 3.6 GHz is a mild overclock; Silicon Lottery reports 100% can achieve that speed for avx512 loads.[1]

Running programs doing the same thing (eg, Hamiltonian Monte Carlo where the likelihood function has or has not been vectorized), the avx512 version is far faster than scalar, and routinely 50%+ faster than avx2.

The avx512 instruction set itself also provides conveniences that make it easier to explicitly vectorize, even if most compilers don't take advantage of them on their own. Masking load and store operations in particular (they're better about masking to handle branches).

On why avx512 vs a graphics card: I need double precision, and my code routinely has maximum widths smaller than the 32 or 64 a graphics card would want to computer in parallel.

[1] https://siliconlottery.com/pages/statistics

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#37

Post by nagarajns »

kccqzy wrote: post #25
eatbitseveryday wrote: post #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…

I guess if it's easy enough to do with software, it won't be very difficult to implement with hardware either. So it doesn't really cost much additional die space.

assssd

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#39

Post by namibj »

choppaface wrote: post #29

I met Naveen Rao after Intel bought Nervana. He seemed pretty adamant about getting stuff shipped fast. In contrast, the Xeon folks own all the politics and seem to want the transition to be very gradual. Plus the Phi folks get phased out. They had done a Nervana trial at Facebook but then flaked on other trials. Clearly Intel is trying to desperately manage their books. Having Nervana and friends on a Xeon chip coul…

maxas still exists, and works for Pascal too. A Volta/Turing assembler like maxas would be nice, but there is no Nervana doing the microbenchmarking to identify the instruction encoding well enough.

Re: Intel Prepares to Graft Google’s Bfloat16 onto Processors

#40

Post by simonebrunozzi »

English is not my first language. I have never heard the term "Graft", even if I consider myself quite literate in English. So here you go, for everybody else in my situation:

Graft, as understood in American English, is a form of political corruption, being the unscrupulous use of a politician's authority for personal gain.

Edit: by the way, I really couldn't fit the term with the article. And realized I was probably looking at the wrong definition. This one might be much more apt:

a shoot or twig inserted into a slit on the trunk or stem of a living plant, from which it receives sap.

Post reply on HN