Live data from Hacker News

Intel Prepares to Graft Google’s Bfloat16 onto Processors

nextplatform.com

71–80 of 138 posts

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

#71

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…

They had an assembler where one person wrote kernels that were faster than cublas in a lot of cases. Afaik, nobody ever released anything else with that assembler, and Nvidia caught up to that performance quickly. In talking with the cublas devs, it seemed more that maxas kernels were highly tuned for specific sizes, whereas cublas/cudnn had to be more general. Nowadays it's really a moot point with Nvidia's Cutlass…

True story-- the Nervana Maxwell stuff didn't go very far-- but it was noteworthy because they had both that small win as well as their own hardware platform.

One other thought about the Nervana-Xeon convergence is that the support for more memory (thru DDR, Optane, or even just mmap'ed NVME) will be a big win for modeling and large-minibatch SGD. For example, the minibatch fetching could be pushed to the hardware / OS instead of Tensorflow (or the crazy guy behind Tensorpack) using a threadpool. A lot of training is still I/O bound at some level, and processors only support so many PCI-e lanes...

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

#72
post #36

Earlier quoted context omitted.

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 lik…

What are you using to vectorize avx512 for HMC? Do you have a lot of element wise ops on big arrays?

When running Stan (NUTS/HMC) on Xeon Phi, telling Eigen to use avx512 provided a noticeable speed up but I didn't look at the assembly to be sure.

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

#73
post #25

> 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.

As the exponent is the same size it is mostly a matter of truncating. However custom hardware could have ability to do more parallel 16 bit ops in avx mode. Presumably they are emulating by expanding to 32 bit in avx512 registers.

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

#74

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…

They had an assembler where one person wrote kernels that were faster than cublas in a lot of cases. Afaik, nobody ever released anything else with that assembler, and Nvidia caught up to that performance quickly. In talking with the cublas devs, it seemed more that maxas kernels were highly tuned for specific sizes, whereas cublas/cudnn had to be more general. Nowadays it's really a moot point with Nvidia's Cutlass…

Cutlass doesn't match the performance of cublass, even on nvidia's benchmarks. Hand assembly is still alive and well!

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

#75
post #2

I wonder why they chose it over facebook’s 8 bit posit: https://code.fb.com/ai-research/floating-point-math/

What does the "int8/32" mean in that paper?

4x8-bit values in a 32-bit value? SIMD does this to perform an operation on 4 8-bit values in a single 32-bit register. There are other configurations, IIRC.

https://en.wikipedia.org/wiki/SIMD#Software

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

#76

Earlier quoted context omitted.

They had an assembler where one person wrote kernels that were faster than cublas in a lot of cases. Afaik, nobody ever released anything else with that assembler, and Nvidia caught up to that performance quickly. In talking with the cublas devs, it seemed more that maxas kernels were highly tuned for specific sizes, whereas cublas/cudnn had to be more general. Nowadays it's really a moot point with Nvidia's Cutlass…

True story-- the Nervana Maxwell stuff didn't go very far-- but it was noteworthy because they had both that small win as well as their own hardware platform. One other thought about the Nervana-Xeon convergence is that the support for more memory (thru DDR, Optane, or even just mmap'ed NVME) will be a big win for modeling and large-minibatch SGD. For example, the minibatch fetching could be pushed to the hardware /…

A V100 GPU gets 900GB/s of memory bandwidth. I am less of a CPU expert but afaict you'll be lucky to get much more than 10% of that out of a CPU. This is going to make a huge difference that Intel can't make up with bigger execution units.

bfloat helps with this because the data is half as large. But of course if you're doing Nvidia you're probably already doing (IEEE) fp16.

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

#77
post #67

Does bfloat16 have any other uses than deep learning?

It isn't really very good for machine learning - machine learning doesn't need 8 bits of exponent. For weights during training, 7 bits of mantissa also seems a bit low - it's common for weights to adjust much less than 1% during a single batch of training, which this couldn't represent. I think this is more a "we want something which is faster but is compatible with existing code written for fp32's".

Bfloat is specifically designed for ML. It is the native type in Google's TPUs. It is quite good at ML; most models that work with fp32 work with bfloat with no adjustments; that's in contrast to IEEE fp16.

You're right that the mantissa is small. The trick is that you always accumulate into fp32 and then truncate down to 16 bits at the end. You'd do this for any 16-bit floating type.

Source: I work on this at Google.

https://cloud.google.com/tpu/docs/bfloat16

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

#79
post #76

Earlier quoted context omitted.

True story-- the Nervana Maxwell stuff didn't go very far-- but it was noteworthy because they had both that small win as well as their own hardware platform. One other thought about the Nervana-Xeon convergence is that the support for more memory (thru DDR, Optane, or even just mmap'ed NVME) will be a big win for modeling and large-minibatch SGD. For example, the minibatch fetching could be pushed to the hardware /…

A V100 GPU gets 900GB/s of memory bandwidth. I am less of a CPU expert but afaict you'll be lucky to get much more than 10% of that out of a CPU. This is going to make a huge difference that Intel can't make up with bigger execution units. bfloat helps with this because the data is half as large. But of course if you're doing Nvidia you're probably already doing (IEEE) fp16.

That sounded a bit low. This

https://en.wikichip.org/wiki/intel/microarchitectures/cooper...

says "Higher bandwidth (174.84 GiB/s, up from 119.209 GiB/s)"

I don't know if memory bandwidth matters for this type of job, though.

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

#80

Could we get a Bfloat32?

You already have that; it's more formally called IEEE 754 single precision. Requires double the memory bandwidth (bad) for extra precision that back propagation would have corrected for anyways.

Seems like BFloat32 would have the same exponent range as Float64 (double precision), and a correspondingly shorter significand.
Post reply on HN