The 2990wx blew everything out of the water in rendering. It's like 37% faster than the 7980xe in the Blender benchmark.
Faster with 2x more cores and twice more power consumption. Hardly a win in my book - it means each core is way weaker and power hungry. Intel will easily match that sometimes soon without sweating.
2x core count hardly ever offers anywhere near a 100% performance gain, even across Intel's lineup [1]. Very few workloads are that parallelizeable, and almost everything (from the program to the OS to the CPU itself) introduces some form of overhead when running in parallel.
It's funny to me how much range there is in these tests. Some of these are seemingly backwards with better CPUs ranking so much worse and some look completely random. But wow, the performance on these new TR chips is just insane. Never would've guessed that AMD would be this competitive a few years ago, especially not on the CPU front. Looking forward to the upcoming 7nm launch, can't wait to see what's in store.
The test results on Phoronix paint a rather different picture (i.e., the 2990WX being consistently and markedly faster than any other tested processor). My initial gut feeling reading the results on Anandtech is that Window's scheduler may not be able yet to exploit the processor's architecture effectively.
Wow, I didn't even realize how big an impact it makes. It literally outperforms everything else on a large margin except for one test, and gets like 117% more performance in ebizzy than the 7980xe.
It seems performance under Linux is significantly better: https://www.phoronix.com/scan.php?page=article&item=amd-linu...
I wonder if this comes down to Linux being more adept at handling "exotic" NUMA configurations compared to (desktop) Windows. Even if the "server" editions of Windows could handle them Microsoft may have left that functionality out of the "desktop" kernels for product segmentation purposes.
> Because the two NUMA nodes are ~entirely independent, it's capable of running two independent processes at full speed. I don't understand. From my (admittedly little better than layperson's) knowledge, I'm guessing the cores of most multicore processors have to compete for memory access...? Is there a good search term I can use to help me understand what's going on here?
There are 2 dies in the 1950X, each one has 2 memory channels. Thus, it's possible to run a process on one (8-core) die that maxes out the memory bandwidth to it's two local DDR4 channels while the other die still has full bandwidth access to it's own DDR4 channels. Threadripper is able to switch between NUMA (non-uniform memory access) mode and "regular" mode. In NUMA, the OS knows that 2 channels are attached to 1…
As a bonus, if you are explicitly NUMA & the OS/code does a good job, there's little line contention or resource sharing (e.g., caches) between die.
The Chrome compilation looks really strange indeed, especially with having the results from Phoronix on Linux which show that it's the fastest compiling the Linux kernel. I wonder what kind of Chrome build it's doing - does it use Clang-cl or Visual C++? Does it have LTO (LTCG for VC++) enabled? If it's VC++ with LTCG, for example, the entire code generation and linking is limited to 4 cores by default.
It's Chromium 56 with the default Chromium build-chain. At that point, Chromium required Visual Studio 2015 Update 3 or later. Anand use VS Community 2015.3. IIRC, by default it doesn't have LTCG enabled. By default, release builds are almost entirely statically linked (with a few shared libraries, platform dependent), which makes linking time pretty significant. As a result, it ends up more as a linking benchmark th…
Ian Cutress replied on the article comments that LTCG is indeed used. With LTCG those strange results make sense - it's spending a lot of time on just 4 threads by default - actually majority of the time is on one thread for the Chromium case, it hits some current limitations of the VC++ compiler regarding CPU/memory usage that makes scaling worse for Chromium (but not for smaller programs or with non-LTCG builds). Increasing the number of threads from the default of 4 is possible, but will not help here. The frontend (parsing) work is well parallelized by Ninja, it's probably the reason why the Threadrippers do end up ahead of the faster single-core Intel CPUs.
Honest q: What home-use workstation would use 32 cores? (Excluding home labs or servers).
Does video editing or After Effects work could as home use yet? Video editing, in terms of cutting and splicing clips, is not going to benefit much from this chip, but a lot of effects rendering will benefit, and basic video editing uses a lot of effects these days. That’s all I’ve got.
Most plugins/filters/effects are single-threaded :-(
> After core counts, the next battle will be on the interconnect. Low power, scalable, and high performance: process node scaling will mean nothing if the interconnect becomes 90% of the total chip power. I think this means that scaling processors to more cores (nodes) in a lightweight-NUMA scheme just isn't going to work. My guess going forward is that the core counts will stay at the current level for quite a while…
I was hoping they would at least make a passing reference to Amdahl's Law.
As you optimize one part of the system so that it is blazingly fast or lower power or whatever, then the amount taken up by the rest of the system increases proportionally.
(In other words, real performance wins happen gradually as all the parts receive their own little optimizations which add up.)
This is the perfect chip for continuous, low-memory number crunching. For everything else... not so much. I mean, this chip consumes 74W when idle, of which almost 90% are spend on the interconnect. That's insane. Most important bit in the review for me: "After core counts, the next battle will be on the interconnect. Low power, scalable, and high performance: process node scaling will mean nothing if the interconnec…
Why do you say low-memory? I got the opposite feeling. I've been drooling over EPYC and TR2 ever since they released the specs for my memory bandwidth limited projects.