TR Forums

Perhaps this is old news, but damn, Naples/Epyc is looking great at first glance: http://www.anandtech.com/show/11544/int ... the-decade (sorry for the link to Anand)

Better power efficiency than Intel? What the what? Sure, it's ill suited to some workloads due to the oddness of cache latency and inter-core communication...but holy jeebus.

I cannot wait to get my hands on the test boxes showing up at work in the next week or so. I/O monsters for sure with memory bandwidth to spare if you don't need high concurrence between many threads.

AMD got themselves a winner in the 1S/2S server market. The massive I/O on the platform is almost as if was geared for using GPGPUs for HPC applications.

I'm no fan of GPUs for doing HPC work (they're pretty terrible for certain workloads), but yes, the PCIe layout is extremely attractive for many other reasons.

Waco wrote:

I'm no fan of GPUs for doing HPC work (they're pretty terrible for certain workloads), but yes, the PCIe layout is extremely attractive for many other reasons.

That's kinda why Intel placing massive investment into AVX becoming widespread. It is a long-term plan to fight against the encroaching threat of GPGPUs in certain HPC applications.

Yep. For many problems GPUs just aren't usable, though.

Waco wrote:

I'm no fan of GPUs for doing HPC work (they're pretty terrible for certain workloads), but yes, the PCIe layout is extremely attractive for many other reasons.

What are the workloads that don't execute well on GPUs? I imagine those with lots of loops and conditionals?

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

anotherengineer wrote:

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

"Your day" must go pretty far back.

In the early '90s I worked on one of the early purpose-built QCD simulation machines, ACPMAPS. 12 racks of equipment, 612 Intel i860 processors, and hundreds (thousands?) of feet of twisted pair ribbon cable. It was bleeding edge for its day; today you can get equivalent computing power in a desktop PC.

anotherengineer wrote:

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

You're going to drop a line like that with no mention of slide rules?

(I had a friend who went to work for Boeing the late 80s. Even then Boeing had leading edge CAD and Boeing Computing Services was already a thing, with Cray no less, but for day to day calculations a lot of the engineers still used slide rules or, for the younger ones, HP calculators. It took a while for my friend to convince some of them as to the benefits of spreadsheet software.)

UberGerbil wrote:

anotherengineer wrote:

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

You're going to drop a line like that with no mention of slide rules?

(I had a friend who went to work for Boeing the late 80s. Even then Boeing had leading edge CAD and Boeing Computing Services was already a thing, with Cray no less, but for day to day calculations a lot of the engineers still used slide rules or, for the younger ones, HP calculators. It took a while for my friend to convince some of them as to the benefits of spreadsheet software.)

I've learned the basics of using a slide ruler back in the late 80's when I was in JR High, but haven't used one in so long that I forgotten how.

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

The cache hierarchy in the new AMD cards with transparent addressing of system RAM and even an onboard SSD is supposed to help with this. HBM is now called "high-bandwidth cache". The PCIe3 bus remains a bottleneck, but at 15.8GB/s (16x) it's already 1/3 of DDR4 3200 (2ch).

On the other end, there are AVX512 monsters that can now hit 1TFLOP on the CPU. Competition gets interesting...

UberGerbil wrote:

anotherengineer wrote:

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

You're going to drop a line like that with no mention of slide rules?

(I had a friend who went to work for Boeing the late 80s. Even then Boeing had leading edge CAD and Boeing Computing Services was already a thing, with Cray no less, but for day to day calculations a lot of the engineers still used slide rules or, for the younger ones, HP calculators. It took a while for my friend to convince some of them as to the benefits of spreadsheet software.)

When I was a senior in High School in 1974 we were taught how to use slide rules in Algebra but not allowed to use them on tests. I used my slide rule for the first year of freshman chemistry in college before I got my first calculator.

UberGerbil wrote:

anotherengineer wrote:

Back in my day we did physics simulations with pencil and paper, went through both by the ton, and erasers.............

You're going to drop a line like that with no mention of slide rules?

(I had a friend who went to work for Boeing the late 80s. Even then Boeing had leading edge CAD and Boeing Computing Services was already a thing, with Cray no less, but for day to day calculations a lot of the engineers still used slide rules or, for the younger ones, HP calculators. It took a while for my friend to convince some of them as to the benefits of spreadsheet software.)

Slide Rule, that's pretty advanced there. More along the lines of an abacus

ptsant wrote:

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

The cache hierarchy in the new AMD cards with transparent addressing of system RAM and even an onboard SSD is supposed to help with this. HBM is now called "high-bandwidth cache". The PCIe3 bus remains a bottleneck, but at 15.8GB/s (16x) it's already 1/3 of DDR4 3200 (2ch).

On the other end, there are AVX512 monsters that can now hit 1TFLOP on the CPU. Competition gets interesting...

Honestly, that kind of tech hurts more than it helps for my workloads. Caching doesn't help anything if you have to touch every byte of memory.

PCIe is simply far to slow to do anything but communication over...and I'd love for more bandwidth in that dimension as well. Hopefully you can see why Epyc has me excited.

ptsant wrote:

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

The cache hierarchy in the new AMD cards with transparent addressing of system RAM and even an onboard SSD is supposed to help with this. HBM is now called "high-bandwidth cache". The PCIe3 bus remains a bottleneck, but at 15.8GB/s (16x) it's already 1/3 of DDR4 3200 (2ch).

On the other end, there are AVX512 monsters that can now hit 1TFLOP on the CPU. Competition gets interesting...

AMD is a member of OpenCAPI and the rumor is that Epyc + Vega will utilize such a link. That'd permit a bandwidth boost to match the speed of dual channel DDR4 3200. The real benefit isn't in the bandwidth increase but the latency reduction and coherency.

However, AVX 512 is a bit of a mess right now. There are two primary implementations (SkyLake-X/SP/EP etc. and Xeon Phi). Even then, Intel is only enabling the full 512 bit wide FMA unit on select hardware. The lower end chips will execute AVX 512 as two 256 bit wide operations. Considering the lack of AVX 512 software on the market, this isn't a big issue but it reeks of artificial product segmentation.

the wrote:

ptsant wrote:

Waco wrote:

Anything that's memory latency or bandwidth bound that doesn't fit in GPU memory.

In my line of work, that's basically all of the problems we run (physics simulations). They tend to sweep all of memory evenly, and we buy machines for memory capacity and bandwidth, for the most part.

The cache hierarchy in the new AMD cards with transparent addressing of system RAM and even an onboard SSD is supposed to help with this. HBM is now called "high-bandwidth cache". The PCIe3 bus remains a bottleneck, but at 15.8GB/s (16x) it's already 1/3 of DDR4 3200 (2ch).

On the other end, there are AVX512 monsters that can now hit 1TFLOP on the CPU. Competition gets interesting...

AMD is a member of OpenCAPI and the rumor is that Epyc + Vega will utilize such a link. That'd permit a bandwidth boost to match the speed of dual channel DDR4 3200. The real benefit isn't in the bandwidth increase but the latency reduction and coherency.

However, AVX 512 is a bit of a mess right now. There are two primary implementations (SkyLake-X/SP/EP etc. and Xeon Phi). Even then, Intel is only enabling the full 512 bit wide FMA unit on select hardware. The lower end chips will execute AVX 512 as two 256 bit wide operations. Considering the lack of AVX 512 software on the market, this isn't a big issue but it reeks of artificial product segmentation.

Actually, my understanding is that AVX 512 is not simply a flag or a fuse on the chip. CPUs with AVX512 seem to have dedicated units. If correct, then it is probably a case of true, not artificial, product segmentation. Could be mistaken of course...

ptsant wrote:

Actually, my understanding is that AVX 512 is not simply a flag or a fuse on the chip. CPUs with AVX512 seem to have dedicated units. If correct, then it is probably a case of true, not artificial, product segmentation. Could be mistaken of course...

To quote Anandtech: "For anyone on the consumer side who wants to play with AVX-512, it is worth reiterating that there is a separation between the Skylake-X processors: the 6-core and 8-core parts only support one FMA per core, whereas the 10-core supports two FMAs per core."

Since the 10-core is the same LCC silicon and the HCC only begins at the 12-core model, it appears Intel is actually arbitrarily segmenting the product stack (as usual). My understanding is the mainstream Skylake chips don't have the core logic to run it native, hence why it's broken up into two 256 chunks.