AMD Ryzen Threadripper 1950X and 1920X

[Tarinder]

Yup, the result is the same - or within the standard deviation of the test - because it remains subsystem-limited at those resolutions. I've checked the screengrabs. I could run it again and put in a different number from a different run, say, 78.2, but you get the picture. A faster gaming chip, like the Core i7-7700K, continues to scale higher at 1080p.

Edit: I have just run it again. The 1950X scores an average 78.1fps at 1080p, over two runs, so no meaningful increase over 1440p.

[kalniel]

It gives the TR the same result at 1080p and 1440p? And suggests that with Game Mode enabled TR would easily outpace the 7900X at 1080? Impressive...

The latter would be, but giving same result at different resolutions just means you are not GPU limited (ie, are likely CPU limited).

[rainman]

Switch modes, disabling cores (remember? the actual reason you bought this CPU for in the first place) and not having a CPU which you plug in and just works - total deal breaker.

It does "just work" - look at the gaming results in the review . It's not AMD's fault that some game engines throw their toys out of the pram when they meet a > 20-thread CPU, is it.

It's optimised for different types of workloads. As CAT and Corky both say above, you don't buy TR for an exclusively gaming machine. But the fact that you're going to lose a few percent of gaming performance really shouldn't matter if you're buying a 16C/32T CPU for content creation...

Games don't factor into our particular use case, but the requirements for our mixed workloads of new and legacy code are likely to span the two profiles offered in the AMD cludge. Having to reboot to switch between different modes to deal with performance crippling memory latency issues means that for the environments I might have deployed this platform for my customers in the particular non-gaming use case I've been waiting on this product for, it's a total show stopper. Yes, we want performance, but "up time" is every bit as important because it's one of the factors that we get measured on by our customers. Our code roadmap also features AVX512 in the future and so we'd hoped that we could use cheaper Threadripper parts in the near term to gain an advantage. All this means is that we'll be buying Skylake-X parts sooner and employing more staff to bring our planned AVX512 code fork forward.

[Corky34]

...performance crippling memory latency issues ...

5-10% is hardly performance crippling, especially when you gain 30% odd in the other scenario, and i wouldn't be pinning my hopes on Skylake-X as Intel's probably going to struggle with exactly the same "problem" of higher latency between dies that TR faces, you only have to look at the testing PCPer did on a Xeon to see cross-die latency isn't exclusive to AMD.



It should be interesting when people get the time to test how TR handles devices on opposing PCIe controllers, as in the 60 PCIe lanes of TR are split between the two dies so what happens when die 0 requests data from a device connected to die 1's PCIe controller?

[rainman]

...performance crippling memory latency issues ...

5-10% is hardly performance crippling, especially when you gain 30% odd in the other scenario.

That really depends on your workload. In our case we wouldn't get a 30% advantage due to the extensions not being available in TR in the first place that are available across Knights Landing but had hoped we'd make up for that in 60% extra cores vs a 7900X part. IPC still matters to us because although we can parallelise our CFD workloads pretty well we need to be able to effectively leverage an efficient NUMA architecture to do this or it's all a bit pointless, and without that we start falling back to relying on IPC again which is a strategy compromises the whole point of parallel coding. To fork or not to fork, that is the question. We need more testing and publishing gaming benches on these parts is frankly ridiculous.

It should be interesting when people get the time to test how TR handles devices on opposing PCIe controllers, as in the 60 PCIe lanes of TR are split between the two cores so what happens when core 0 requests data from a device connected to core 1's PCIe controller?

Agreed. I'm not sure how well these parts are going to work with a Magma chassis stuffed full of Pascal cards.

[CAT-THE-FIFTH]

Apparently at least Eypc seems well received by some large companies like MS and Baidu:

https://www.geekwire.com/2017/micros...ter-processor/



That is a video from the CEO of Baidu.

I noticed on a few forums,hardware enthusiasts trying to say AMD is unreliable,etc for the data centre,etc and it seems to be a line straight out of Intel PR and IIRC they tried something similar when the Athlon 64 was released too. Apparently MS and Baidu disagree,and many of the large server companies have announced lines based on Ryzen uarch systems.

Sadly for many for many of the forum enthusiasts having companies like Baidu and MS onboard as launch customers will help AMD quite a bit,especially with the resources these companies have.

Nobody expects AMD to outdo Intel on volume(or get close),but it should carve out a nice niche for AMD in more profitable markets.

Edit!!

Also:

https://twitter.com/NVIDIAGeForce/st...h%2Findex.html

https://twitter.com/AMDRyzen/status/...h%2Findex.html

[scaryjim]

... the requirements for our mixed workloads of new and legacy code are likely to span the two profiles offered in the AMD cludge. ...

Sorry, just to check I've got this right - you've discounted threadripper completely because you think performance will suffer for a particular set of legacy tasks?!

If you'd done proper benchmarking and confirmed that your workload suffers under threadripper's Creator mode I could understand your position, but to just assume it'll be a problem and discount it? Sorry, makes no sense from a business point of view...

[Corky34]

TBH if all you wanted from TR was content creation (heavily threaded workloads) then you'd probably be better of with a Xeon or Epyc, it seems TR's segmentation of the market is confusing some people although i don't understand why as if your workloads are mainly multithreaded then get a Xeon or Epyc, if they're mainly single threaded then buy a high clocking chip with fewer cores, if you're workloads are primarily multithreaded and secondarily single threaded then get a TR, if they're primarily single threaded with secondary multithreaded the get a Intel X series.

TR is basically the equivalent of Intel's X series but puts content creation primarily with gaming as a secondary.

[Xlucine]

TBH if all you wanted from TR was content creation (heavily threaded workloads) then you'd probably be better of with a Xeon or Epyc, it seems TR's segmentation of the market is confusing some people although i don't understand why as if your workloads are mainly multithreaded then get a Xeon or Epyc, if they're mainly single threaded then buy a high clocking chip with fewer cores, if you're workloads are primarily multithreaded and secondarily single threaded then get a TR, if they're primarily single threaded with secondary multithreaded the get a Intel X series.

TR is basically the equivalent of Intel's X series but puts content creation primarily with gaming as a secondary.

That's a good point, low-end epyc comes in at a similar cost for the CPU and with more threads (1900X 8c 3.8GHz $550 vs 7281 16c 2.1GHz $600; 1920X 12c 3.5GHz $800 vs 7351P 16c 2.4GHz $700; 1950X 16c 3.4GHz $1000 vs 7401P 24c 2GHz $1000 from here and here). It could be the motherboard is significantly more pricey for epyc, but then it'd have to cost significantly more than the chip to still work out more expensive overall.

[Bambooz]

Page 2, last picture (Total War: Warhammer) says Full HD/FHD, but then lists 2560x1440 as the resolution right after...!?