SoylentNews is people
SoylentNews
Shares of AMD rose 11.6% on Tuesday as Fudzilla reported that Intel would license graphics technologies from AMD after a similar deal with Nvidia expired two months earlier. The deal has not been confirmed.
On the other hand, AMD's 16-core "Threadripper" enthusiast/HEDT CPUs have been confirmed:
With one of the gnarliest CPU codenames we've ever seen, the Threadripper multicore monsters will go head to head with Intel's Broadwell-E and upcoming Skylake-E High-End Desktop (HEDT) CPUs alongside a new motherboard platform that promises expanded memory support and I/O bandwidth. That's likely to take the form of quad-channel RAM and more PCIe lanes, similar to Intel's X99 platform, but AMD is saving further details for its press conference at Computex at the end of May.
AMD's 32-core "Naples" server chips are now known as... "Epyc".
You have seen the launch of 4, 6, and 8-core AMD Ryzen parts. How do you feel about 10, 12, 14, and 16 cores (prices unknown, likely $1,000 or more for 16 cores)?
Previously: CPU Rumor Mill: Intel Core i9, AMD Ryzen 9, and AMD "Starship"
(Score: 3, Informative) by fyngyrz on Thursday May 18 2017, @04:14PM
Also SDR (Software Defined Radio) software - of which there are a fair number of users out there, BTW.
I write both SDR software and image manipulation software. I make extensive use of multiple cores in both.
I would welcome a 16-core CPU. I run a 12/24 core machine now. 16/32 would be just fine with me, assuming equal or better capacity per core.
Having said that, main memory speed is extremely important, particularly with lower numbers of cores. Caches aren't large enough -- not even close -- to do many things that deal with large data and tables. For instance, certain types of image processing access many regions of the image more-or-less simultaneously-ish and repeatedly, while moving through those regions. All that does to cache is make it consistently miss. At that point, the CPU instruction cycle time and the main memory speed are the limiting factors. However, as the core count goes up, in many cases, the slices or regions assigned to each core become smaller, and the odds of the cache missing drop given similar workloads. Likewise, large tables of pre-calculated values don't get effectively cached, so that reduces the time savings of the precalculation, and in the smaller computation-avoided cases renders the technique moot.
Given a choice, I'd like a 100 GHz single core with 100 GHz memory, we can time slice it and call it all good. :) But inasmuch as that's not going to happen with today's silicon tech, many more cores on bigger and bigger chips and/or smaller and/or more 3d-ish geometries are very welcome. It all eventually chokes on memory access though, and that's where I wish we'd see the most improvements. Also very tough to do.
Another thing... operating system (and translation layer, like Qt) GUI code is lagging way behind; it's fairly typical to not allow anything but a main thread to update the GUI, and that can create a bottleneck in graphics-heavy operations; you end up passing messages around and heavily loading the main thread, which is the only one that can address them. My SDR software, for instance, while spread out over the 12/24 cores in my machine, always has one thread/core working much harder than the others. That's the display thread, and it's because those tasks can't be spread out over multiple cores.
TL/DR: Better OS code, faster memory, faster cores, more cores. And give every core an FPU, please. I want it all, chip and OS architects!