slizard

> On the Open Source Linux OpenGL drivers (but not the proprietary ones), it is competitive with the 1080Ti at considerably lower MSRP

Yaaay! Really, that's cool but it's a negligible fraction of the market. Unless Linux gaming becomes a market force overnight, it won't matter a lot, I think.

> Power to performance ratios are also not well shown with the current shipping proprietary driver

I doubt they can close the large power gap that the initial benchmarks show (compared to the 1080 and esp. 1070), but I'm hoping the power margin will get narrower and a bit of performance increase might compensate too.

Indeed, I am dampening my expectations, I'm most hopeful that in the high-end GPGPU compute arena they might not be too late and will provide enough Perf/W/buck to gain traction.

RX Toaster, they need to pull some magic out of the chip with upcoming drivers, otherwise this won't be the big return everyone expected, I feel.

I just hope the MI25 cards will be far cheaper than the $6k Tesla P100's and that the ROCm stack is good enough so for compute the architecture may still be a viable and very competitive option.

There goes yet another example of Goodwin's law in action, but I'm not so glad for the arguably rash, overly emotional, and definitely not balanced analogy.

Agreed, see my point below (/item?id=14747906).

Sure, but I was addressing the areas where the Zen arch is clearly not beating Intel. Database, java, etc. are areas where the initial benchmarks indicate that EPYC is quite competitive.

Good point, it looks like they have a decent path forward and hopefully they take good advantage of the new nodes and the available room for refining the uarch.

Socket compatibility would be wise, I hope at least the Zen+

I'm hoping they soon get back to competing aggressively at high-end HPC too, perhaps they could spend some area on Zen+ on better FP SIMD, or even flexible width SIMD (though the latter would be more realistic on the 7nm successor).

Thanks for the link.

Ugh, per-core licensing is pita. Tell the decision-maker at your work to pay for the cores or switch to some code with more sensible pricing model. Do the alternatives (like Ansys) charge per core as well?

Many if not most HPC/sci. comp applications are memory bound (or actually their implementations are). [ref missing, but google around and you'll find plenty]

More and more applications are drifting into the memory-bound regime, especially with the wider SIMD instruction sets increasing arithmetic throughput while memory throughput lags behind.

My back-of-the-envelope calculation (with a guesstimated AVX512 clock) gives a 12 FLOPS/byte for a big Skylake chip like the 8176 while this was around 9 FLOPS/byte for Broadwell. I'm not entirely sure about the instruction throughput of Zen, but it looks like the 7601 should be around 4-5 FLOPS/byte (that's worst-case with mixed FMA+ADD workload based checked Agner F's manual [1] IIUC).

Of course this does not consider NUMA and other effects, but given the above a lot of applications will benefit from the great bandwidth advantage of EPYC.

[1] http://www.agner.org/optimize/microarchitecture.pdf

Why not talk to OEM's? Many have been running benchmarks for some time and surely have an idea about performance -- though one important question is whether that "idea" is biased or not.

> 1. The mesh interconnect looks like a big loser for the smaller parts. It's a big jump up in complexity (there's an academic paper floating around which describes the guts of an early-stage version) and seems to be a power and performance drain.

Indeed surprising given that they had a few years to learn from the KNL experience.

Got a link to that paper?

> I have an upgrade budget and it looks like it'll be heading nVidia's way at this point.

Just for curiosity: what workload allows you to go with NVIDIA instead of Intel (rather than AMD)?

It will take some time until that question can be answered. For some it will likely matter a lot, e.g. engineering or HPC applications that rely heavily on dense solvers. however, even for non FP-heavy workloads (like integer-heavy stuff say databases) the wider SIMD with the new mask and blend instructions [1] _could_ make a significant difference. Still, in many cases significant difference will likely be seen only after careful tuning!

Also note that Intel is refining their pesky market segmentation game: the full 2x 512-bit FMA/cycle is only available on high-end CPUs, only lower-end it's only 1 FMA/cycle and you still get the extra AVX512 clock throttle hit [2]!

I really like the fact that AMD stayed away from such devil-in-the-details feature-based market segmentation!

[1] https://software.intel.com/en-us/blogs/2013/avx-512-instruct... [2] https://www.servethehome.com/wp-content/uploads/2017/07/Inte...

This looks like a solid if not amazing comeback of AMD into the server market. Sure, single threaded performance may not beat Skylake-SP, nor will the LINPACK (and most wide SIMD/FMA-heavy works) performance, but that still leaves most of the HPC/engineering applications that either do not have workload that lends itself to heavy vectorization or are simply not tuned for it (and won't be overnight).

All in all, whhen you have a server that seems so close in performance to Intel for less money and consuming less power, I can't imagine that EPYC won't see broad adoption and Intel won't be squeezed.

I'm glad AMD is back and there is renewed competition in the server market!

What scaling are you referring to when talking about "linear"? Did you really get 2x absolute performance going from 128-bit to 256-bit SIMD (regardless of the uarch, e.g. both with SBE and HSW with the former having a relatively poor cache performance). I'd be surprised, but if your code is in the >>O(10) flops/byte regime [1] and especially friendly instruction stream too. Otherwise, I'm skeptical.

Putting aside the "scaled almost linearly" statement, I'm not surprised that AVX-512 did not give the expected benefits ootb, you suddenly need double the amount of data loaded into the registers for every 512-bit instruction. You'd also quite like want to make sure masking is used effectively. [2]

[1] http://people.eecs.berkeley.edu/~kubitron/cs258/lectures/lec... [2] https://software.intel.com/en-us/node/523777

Threadripper & EPYC are a truly epic move to jump into the dense GPU workstation and server market! With a Threadripper you get four x16 GPUs without PLX or three + a couple of SSDs.

Time for @nvidia to switch the DGX boxes to @AMD CPUs? :)

> Xeon Phi's clock low because the die is massive.

That's not the main reason. The main reason is perf/W for highly parallel workloads.

> The downclocking for AVX started with Knights Landing.

You're mixing things up here and that statement is incorrect too. AVX throttling started with Haswell-EP [1,3] (Intel kept it quite hush-hush avoiding mentioning it in products specs and such). Secondly, Xeon Phi is the HPC product family and KNL is the codename of the 2nd generation of these arch [2]

> My Boardwell-EP Xeon stays at 3.0Ghz even when I (ab)use AVX2.

In that case you're most likely either not using more than 1-2 cores or you're overclocking (or perhaps monitoring incorrectly), see [1,3].

[1] http://images.anandtech.com/doci/8423/AVXTurboHaswEP.png [2] https://en.wikipedia.org/wiki/Xeon_Phi [3] https://www.microway.com/knowledge-center-articles/detailed-...

> The 18 core part will probably be in the 2.5 range at best (the best 18 core Broadwell I can find runs at 2.3, but it is a dual socket part). Running in full AVX512 mode will probably downclock the cpu further.

Indeed, the 2.2-2.3/2.7-2.8 GHz (base/boost) of the >18C E5-269X v4 CPUs is the non-AVX instruction clock. With AVX the throttling these drop by 300-400 MHz [1] and I expect the skylake chips to behave very similarly. In fact I would not be surprised if on average 512-bit AVX2 required more throttling than 256-bit.

[1] https://www.microway.com/knowledge-center-articles/detailed-...

...and of course AVX-512 for the lucky ones that can get significant benefit from such a wide SIMD (also considering the very likely significant clock limit for AVX instruction streams).

The poor performance (as well as perf/W for all but 2D graphics). Compare it to an NVIDIA chip of similar die size, TDP, and target form-factor. You'll realize that most Intel chips (other than the top of the line like the P580) are not in the same ballpark. As much as I hate saying this, NVIDIA's drivers are stable on Linux -- and I know because I use them every day both for display and compute (in OpenCL/CUDA).

Looks like they think they're still winning regardless of the price and that simply bumping core count to be the kings and bringing the price back to the Haswell-EP level high (rather than Broadwell-EP crazy) will be enough.

What also shows that they seem to be confident is that they're further segmenting the market based on the PCIE lane count to push everyone wanting >32 lanes into the >$1k regime.

All in all, the cool thing is not the i9s and high core counts which you could get even before by plugging a Xeon chip into a consumer X99 mobo (though you'd have to pay some $$$), but the new cache hierarchy which will give serious improvements in well-implemented, cache friendly codes!

> Google Search? The entire web could be described exactly like that.

Nah, the user's mood may be ruined if the search results are junk, but ruining the the model you're trying to build has vastly more costly consequences. I don't think the tech is there (just yet) to have some code simply ingest whatever comes its way, chew it up and use it well; required xkcd (today's!): https://xkcd.com/1838/

Might well be at 10x less power -- or more.

Might also be TPU gen2 given the "64 GB of ultra-high-bandwidth memory" was not something IIRC the recent TPU paper was talking about.

And this is here now, while Volta is paper-launched and will be very scarce until late 2017/2018.

I do think that might have played a role here, smart product naming for the Internet-generation will have an impact even in the enterprise settings!

> Why is their business model "poor"?

Because it relies on exploitation. It offers pennies for work that ha real risks involved. No insurance, not even bike maintenance is offered. You're on your own and if you happen to be the unemployed, unprivileged youngster from the outskirts of Stockholm (quite common) and anything happens while you're riding for one of these companies (car hits you, pedestrian walks out in front of you, etc.), at best your bike is busted and you can't even pay back the money you borrowed to buy it just to get the job. At worst you'll have serious injuries and you'll need treatment that you'll get for relatively little cost only because this is Sweden not one of those fucked up countries where health care is terrible and you'd go bankrupt if such a thing happened to you.

That's why the mode is poor. It makes me sad that all these delivery companies build thir business on exploitation.

That's a blanket-statement and ends up being incorrect/inaccurate. The top Vega card is HBM2, not even in the same ballpark as the 1080.

Also, recent Linux patches hint that there will be dual-chip water-cooled Vega boards too which is likely not even 1080 Ti regime: https://www.techpowerup.com/233208/linux-drivers-point-to-up...

The new "Radeon Instinct" cards are about to be released: http://www.anandtech.com/show/10905/amd-announces-radeon-ins...

The mid-range has a lot of potential as it's based on Fiji which NVIDIA can't match in terms of memory BW with any of their existing ML products (nor near future ones). This is important IMO because ML inference is memory-bound and GDDR5 on NVIDIA's cards is no match for even 1st gen HBM.

The big cards is announced to be 12.5/25 Tflops SP/HP, so as long as it's not "tensoring" it should be in between P100 and V100. If they get the price right (and given that even P100 is currently still $5.5-6 w/o tax), it will hopefully gain traction.

A lot hinges on their fully OSS (!) software stack, but they are getting things done, just had a new release: https://rocm.github.io

Hard to get? For better or worse TTBOMK there are more Intel Xeon Phi machines on the TOP500 than GPU accelerated systems.

These efforts are mostly going to aid further market segmentation and boosting profits; e.g. even for development you'll now need a Tesla/Quadro that costs a ton of money, the days of GTX cards that have the same GK2xx or GM2xx chip as Teslas is over.

While the "tensor" units may land in consumer stuff (though I don't think it'll happen this year) I expect there to be little "trickle-down" planned or wanted at this stage.

That would be one way, but what's commendable is that they went further and HIP is actually also a common thin API on top of CUDA and their own platform. They could've just stopped at converting code, but they did not -- and that's something that might save them and give people enough incentive to support their products. You can keep your NVIDIA path that'll be compiled with the nvcc backend and target both platforms with the nearly the same code, especially on host (and often also device side).

> http://www.pcmag.com/encyclopedia/term/48478/open-system

Sadly, that's a very problematic, borderline BS definition.

"A system that allows third parties to make products that plug into or interoperate with it. For example, the PC is an open system."

Intel allows some third parties to interoperate with their system (ref Intel vs NVIDIA etc.) and they pick and choose to their liking, kill some and promote others exactly because they control the open-ness of their systems.

> http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...

HIP is still not a CUDA compiler. http://gpuopen.com/compute-product/hip-convert-cuda-to-porta...

> nor did I refer to CUDA as a programming language.

You did refer to "CUDA compiler". My comment was admittedly a nitpick as well as a serious point too. CUDA can be seen as a C++ language + extensions -- something you can compile --, but it's also more than that (stuff that you can't compile), e.g.: API, programming tools, etc. all strongly adapted for NVIDIA hardware.

^ This!

Please read this before moving on: https://twitter.com/jrprice89/status/667466444355993600

Also, NVIDIA's CUDA compilers are built on clang which does have OpenCL frontend, so all they would need to do is to put some resources into making that frontend work with their current nvcc toolchain.

Many request and want this, but instead they are trying hard to hold back OpenCL just because providing OpenCL 2.0 support (and extensions for their GPUs features) may help adoption of OpenCL which in turn may end up helping other folks and companies too.