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

Knight’s Landing: Atom with AVX-512

chipsandcheese.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Knight’s Landing: Atom with AVX-512

#31

Post by janwas »

moonchild wrote: post #23
janwas wrote: post #3

Great in-depth article. One especially interesting data point relevant to ongoing discussions about AVX-512 area cost: 40% of 2.93 mm2 per core is AVX-512, so 1.14 mm2. This is a large fraction, but as the article says the core is basically a minimum wrapper around the vector unit, with rather weak L1i/branch predictor/store buffers. Let's put that in the context of modern chips. 14nm density was 44.67 MTr/mm2 so tha…

> give us more cores instead That should be a pretty obvious conclusion--higher-clocked cores is better than wider cores, and wider cores is better than more cores. Communication cost between concurrency domains for superscalar/supervector: min Communication cost between concurrency domains for multiprocessors: min 10-100ns

:) Obvious or not, one does still occasionally hear "give us more cores instead".

I agree about the communication cost. Higher clocks are harder - quadratic increase in power. For shared-nothing problems, an array of wimpy (low frequency) cores is pretty good. It seems to me that wider, lower-frequency cores are a good compromise: beefy enough (thanks to vectors) to reduce the number of cores required, while still power-efficient due to both vectors and lower clocks.

Re: Knight’s Landing: Atom with AVX-512

#32

Post by chazeon »

My colleague are still using KNL cpus on Stampede2 to run molecular dynamics simulations. They are just “cheap” in terms of job accounting, because there unloved because they are old and cannot catch up with state of art AMD cpus today. Butter they have a shorter queue for it also.

But it is very interesting to see that these CPUs’ optimizations for high throughput by adopting near-die MCDRAM. This strategy is very similar to what we see in Apple’s M1 series chips today.

Re: Knight’s Landing: Atom with AVX-512

#33

Post by rbanffy »

cpgxiii wrote: post #19
mk_stjames wrote: post #15

The Xeon Phi coprocessor pci-e cards with similar CPU can be had on ebay for like $60 these days. Sadly I haven't seen any good writeups on setting up an environment to run such cards in a homebuilt system. I think it would be neat to build a little mini-supercomputer with 8 of them stacked in one of those mining motherboards with 8 pci-e slots. But I'd have no idea where to start with the toolchain needed to compile…

The only Xeon Phi products to be available in PCIe form are the first-gen KNC cards. These are not Atom-based, they do not share the x86_64 ABI, and the only effective toolchain for them is older versions of the proprietary Intel compiler. While they were quirky at the time (and I got some neat simulations out of them), they were a massive pain in the ass in every other way: - Requires a motherboard that supports lar…

> or third-generation KNM

Never found Knights Mill available anywhere. My understanding is that they were only available to integrators in the HPC space.

Re: Knight’s Landing: Atom with AVX-512

#34

Post by rbanffy »

janwas wrote: post #3

Great in-depth article. One especially interesting data point relevant to ongoing discussions about AVX-512 area cost: 40% of 2.93 mm2 per core is AVX-512, so 1.14 mm2. This is a large fraction, but as the article says the core is basically a minimum wrapper around the vector unit, with rather weak L1i/branch predictor/store buffers. Let's put that in the context of modern chips. 14nm density was 44.67 MTr/mm2 so tha…

> "AVX-512 is a huge fraction of modern cores", and "give us more cores instead". Let's instead use the hardware we have

If what you do can use a wide SIMD pipeline, then, by all means, get AVX-512.

If what you want is to have lots of branchy processes running serving different things, then more cores is a better idea.

I'd suggest the best of both worlds - asymmetric cores. Put a couple that have wide SIMD pipelines, alongside a couple others that don't, but may be smaller and more numerous.

AVX-512 tasks that are scheduled to non-AVX-512 trap and are scheduled to AVX-512 cores. Tasks that don't trap continue running wherever the kernel thinks is best.

Re: Knight’s Landing: Atom with AVX-512

#35

Post by celrod »

janwas wrote: post #29
celrod wrote: post #12

Earlier quoted context omitted.

Good analysis. It's also worth pointing out that this is for 2x 512 bit FMA, which is more than client Ice/Tiger/Rocket lake or Zen4 have. Personally, I bought HEDT (Skylake-X and Cascadelake) because I wanted 2x 512 bit AVX512. Glad it's cheap in terms of area, and I'm hoping we'll get more options with great vector performance in the future.

Good point about the second FMA. I'm not certain it's the best tradeoff, Genoa only has two half-width FMA. I share your hope for more focus on vectors. It's also up to us software devs, CPUs will not invest as heavily if we don't use it.

I do think that Genoa's approach is a reasonable one. I'd like to see one of Gracemont's successors doing the same.

Maybe we'll even see quadruple pumping for AVX-512 some day? I'll be impressed if/when an Atom line CPU gets 4x 128bit fma units to match ARM's Cortex-X line or Apple's Firestorm).

I think these are good options, and can allow AVX-512 to sort of act like SVE, but with the benefits of a fixed size architecture (i.e., shuffles); compile one set of code and you're able to run it anywhere, with performance dictated by how much the vendor decided was worth investing into the vector units. And AVX512 can still help (like it does Genoa) by taking a lot of pressure off of the front end.

I'm also trying to do my part as a software dev! I wrote/maintain the JuliaSIMD ecosystem, and working on good loop vectorizers to let people take advantage of their vector units is my passion; LoopVectorization.jl has gotten great results on many benchmarks[0], and I'm rewriting it as an LLVM pass to try and address as many of its flaws and limitations as I can.

[0] For example, in a simple self-dot-product benchmark, LLVM's 256 bit code is actually faster than its 512 bit code when testing random sizes from 1-256: https://github.com/JuliaSIMD/LoopVectorization.jl/issues/446... However, LoopVectorization.jl's 512 bit code is close to twice as fast as either LLVM's 256 bit or 512 bit code. This is a trivial example; the difference can be much larger for more complicated code.

Re: Knight’s Landing: Atom with AVX-512

#36

Post by ksec »

janwas wrote: post #3

Great in-depth article. One especially interesting data point relevant to ongoing discussions about AVX-512 area cost: 40% of 2.93 mm2 per core is AVX-512, so 1.14 mm2. This is a large fraction, but as the article says the core is basically a minimum wrapper around the vector unit, with rather weak L1i/branch predictor/store buffers. Let's put that in the context of modern chips. 14nm density was 44.67 MTr/mm2 so tha…

Yes. That was part of the plan for Intel. Remember that Intel was suppose to have 7nm by 2019, which is roughly equal to TSMC N5.

Re: Knight’s Landing: Atom with AVX-512

#37

Post by janwas »

celrod wrote: post #35
janwas wrote: post #29

Earlier quoted context omitted.

Good point about the second FMA. I'm not certain it's the best tradeoff, Genoa only has two half-width FMA. I share your hope for more focus on vectors. It's also up to us software devs, CPUs will not invest as heavily if we don't use it.

I do think that Genoa's approach is a reasonable one. I'd like to see one of Gracemont's successors doing the same. Maybe we'll even see quadruple pumping for AVX-512 some day? I'll be impressed if/when an Atom line CPU gets 4x 128bit fma units to match ARM's Cortex-X line or Apple's Firestorm). I think these are good options, and can allow AVX-512 to sort of act like SVE, but with the benefits of a fixed size archit…

> Maybe we'll even see quadruple pumping for AVX-512 some day? > can allow AVX-512 to sort of act like SVE, but with the benefits of a fixed size architecture (i.e., shuffles); compile one set of code and you're able to run it anywhere, with performance dictated by how much the vendor decided was worth investing into the vector units

That makes a lot of sense. It's basically the equivalent of RISC-V's LMUL=4, with the big advantage of reducing instruction count as you say. That seems a better route than 4x128, which might actually be less in practice if there are resource conflicts.

> I'm also trying to do my part as a software dev! I wrote/maintain the JuliaSIMD ecosystem

That's awesome, congrats on the good result. Looks like your preference is to allow people to write high-level code without much worry about the arch details. Any thoughts on how we can spread awareness of the basics such as data-oriented programming (avoiding branches, optimizing for cache and contiguous memory accesses)?

Post reply on HN