Linked by Thom Holwerda on Fri 11th Aug 2017 19:46 UTC

In this review we've covered several important topics surrounding CPUs with large numbers of cores: power, frequency, and the need to feed the beast. Running a CPU is like the inverse of a diet - you need to put all the data in to get any data out. The more pi that can be fed in, the better the utilization of what you have under the hood.

AMD and Intel take different approaches to this. We have a multi-die solution compared to a monolithic solution. We have core complexes and Infinity Fabric compared to a MoDe-X based mesh. We have unified memory access compared to non-uniform memory access. Both are going hard against frequency and both are battling against power consumption. AMD supports ECC and more PCIe lanes, while Intel provides a more complete chipset and specialist AVX-512 instructions. Both are competing in the high-end prosumer and workstation markets, promoting high-throughput multi-tasking scenarios as the key to unlocking the potential of their processors.

As always, AnandTech's the only review you'll need, but there's also the Ars review and the Tom's Hardware review.

I really want to build a Threadripper machine, even though I just built a very expensive (custom watercooling is pricey) new machine a few months ago, and honestly, I have no need for a processor like this - but the little kid in me loves the idea of two dies molten together, providing all this power. Let's hope this renewed emphasis on high core and thread counts pushes operating system engineers and application developers to make more and better use of all the threads they're given.

Permalink for comment 647893
To read all comments associated with this story, please click here.
RE: Threads
by dpJudas on Sat 12th Aug 2017 09:57 UTC in reply to "Threads"
Member since:

More use? No. Better use? Yes. Programs should definitely be thread agnostic and thus structured (layered) for usage patterns like work-stealing queues etc.

Problem is that once NUMA enters the picture it becomes much more difficult to be thread agnostic. A generic threadpool doesn't know what memory accesses each work task is going to do, for example.

Reply Parent Score: 3