Even GPUs are starting to peter out with lengthening product cycles, smaller improvements, and the increasing tendency to just rename the previous generation with a new name, as if it was actually significantly improved.
So CPUs have peaked, most of the low hanging fruit has already been taken. Most easily shown by pretty much all the popular CPUs from the previous generation maxed out at 95 watts or so (desktop or server), but are at 180 watts in the current generation. This happened years ago for desktops, but is hitting laptops (last year), and smart phones (this year or so).
GPUs are about half way there, improvements are harder. No more annual updates with 2x the performance on most common use cases. Feature improvements are getting more obscure, gaming sites are using 16x zoom to show the improvements. GTX1170 is rumored to be 50% faster than the GTX1070... from 2 years ago.
Specific use ASICs for mining, AI, and similarly narrow use cases are still early in their development. Multiple vendors are showing 2x improvements with each generation, even crazy things like including said chips in consumer devices with tiny power budgets.
So basically a core twice as fast isn't happening, it's not because anyone is lazy. There's tons of room for improvement in specific use cases where today's silicon is crazy inefficient. Things like machine learning, software device radios, vision specific processing, and related are seeing rapid improvements.
> Chips are getting physically bigger
They are? Over the years, I got the notion that the cheap controller chips were about 30 mm2, the regular desktop CPUs about 100 mm2, and server class powerhouses around 300 mm2.
With a quick look, I found mention of Epyc being four 200 mm2 dies packed together: https://www.eetimes.com/author.asp?section_id=36&doc_id=1331...
Wafers have gotten bigger, https://en.wikipedia.org/wiki/Wafer_(electronics), but I suppose that manufacturers just want more dies per wafer, not larger dies.
AMD was pretty krafty with this generation. Intel has a huge R&D budget, has it's own fabs, and pushes many different ASICs split into a dizzying array of products. Intel can afford this because they have a MUCH higher volume of parts to amortize the costs over.
To compete at many different price/power/performance points AMD uses the exact same ASIC for desktop (1 ASICs with 2 memory channels), workstation (2 ASICs with 4 memory channels), and server (4 ASICS with 8 memory channels).
Now AMD can compete across a decent fraction of Intel's produces with a single ASIC and spend more R&D on the second generation without having to re-engineer an entire family of ASICs.
Compare any photos of a threadripper or epyc chip, they are easily visible even onstage, it's about as big as the palm of your hand. I believe it's 69.2 mm x 57.9 mm according to a spec I found on the TR4 socket.
Out of curiosity, are you working on tasks that don't parallelize? There are some for sure, but maybe more that do parallelize, just not trivially or easily? It seems like some people have wanted faster CPUs rather than more parallelism for as long as I can remember... decades. I'm wondering out loud if your wish has ever not been true.
I suspect we're stuck with getting more cores until there's a new fundamental breakthrough in physics. We're hitting the wall with CPU speeds, which is why GPUs have been seeing all the growth recently.
So I just went looking and found a CS term for hard to parallelize I hadn't heard before: P-complete. https://en.wikipedia.org/wiki/P-complete Are you working on stuff related to or dependent on any of these examples?
[0] https://www.anandtech.com/show/12785/arm-cortex-a76-cpu-unve...
This is not to say that your problems aren't real. But I'm skeptical a concerted effort was ever made to go multi-core here.
What's an acceptable level of total latency, so I can understand better?
Acceptable latency would be between 2 to 25ms, but typically it is 5ms to work comfortable. My projects stutter on 25ms latency on Ryzen 1800x.
Let me put it this way:
Take a sample rate of 200kHz.
Take a pipeline with 12 steps that each require 2-3GHz.
These cores can easily synchronize to within a fraction of a microsecond, so round up to 1us.
Assume each plugin needs 10 samples available, and that the input-to-output latency might get as high as 20 samples when it's running on a completely dedicated core.
So put a buffer between each core of 20 samples, plus an extra 50% to be conservative, plus an extra 15us=3 samples to synchronize the cores with very conservative slop. So 33 samples per buffer.
12 inter-core buffers now take up a total of 396 samples, or slightly under 2ms. For a pipeline doing ~30GHz of work.
Nothing about modern multi-core CPU design makes a pipeline like this difficult. It's all software considerations, where the use of soft-realtime threads 'should' be straightforward, while letting the OS use the spare cores.
If you have a stutter at 25ms then someone blatantly screwed up their code.
I'm arguing that in audio processing, if the software is well-written, more cores can crush the performance of a single fast core. Even if it's a very serial pipeline.
Now you're here, describing an audio processing scenario where it's trivial to split the load up over many cores and run 10x faster or more.
I agree, more cores are better...?
If you're just arguing that you can't dedicate 12 cores per track while also having 32 tracks... that's certainly true, but completely irrelevant? Completely accurate that the multi-core CPU is not 300 times faster than a single fast core. But nobody said it was.
It's like none have noticed all processors, even gaming centric ones, come with a bunch of cores these days. Athlon dual core is not exactly a recent innovation, it's archaeology. So all the trivia and "yeah but..."
+ Gaming and a few other tasks mostly do not benefit from more cores and tend to be extremely GHz dependent. Thanks to massive GPU parallelisation we're left mainly CPU bound.
+ Even gaming pitched "Extreme" SKUs are disappointing from a GHz PoV
+ We haven't been in MS-DOS mode or had problems serving 120 OS background processes for a very, very long time indeed.
+ Power and heat have still gone wildly up despite the switch to cores not GHz
So, processor manufacturers hopped off the GHz race for well known reasons. We're now a decade on from that and GHz is about the same like they have stopped thinking about GHz entirely.
It's not unreasonable to have hoped to have hit 5GHz without wildly unrepresentative cheats hidden under the desk, or that they would have kept at least a few percent of their research chasing some more Hz as well as cores.
The reality of it is:
1) increasing the clock rate is hard past 3 GHz or so. The memory wall doesn't get any easier, so IPC drops as clock rate increases. Also heat becomes more of an issue.
2) increasing pipeline length (to make it easier to hit higher clocks) has increasing penalties for each branch misprediction. So IPC drops significantly and you end up back where we are today (high IPC, but low clock).
3) shrinking chips to increase the clock rate no longer works. Generally the insulation layer is so thin that making it thinner results in more leaking.
4) Ever increasingly smart cores (to get higher IPC), makes it ever harder to increase the clock. It's actually pretty amazing what happens in 1/3rd of a ns. Voltage changes in silicon actually move quite slowly (relatively to the speed of light) in silicon. Things like looking at a queue of 80 instructions, figuring out which ones have no pending dependencies, and issuing them to the right unit is pretty impressive for 0.33 ns. Moving to 0.2ns makes it worse.
So could AMD, Intel, or anyone with a decent CPU team design a 5 GHz cpu... sure, no problem. Would it be any faster for general purpose code running on today's 3 GHz CPUs, unlikely.
Personally for my desktop use I don't care about best case performance (0% cache misses), or even average case performance (which is generally way more than I need). I care about worst case performance. Stutters, hangs, lagginess, etc. Linux, enough ram (32GB in my case), GTX 1070, and a M2 for /home. So I welcome the additional cores. Plex transcoding, compressing family videos, making new icons for 10,000 photos, large parallel compiles, etc. Hell sometimes I game while the kids are watching plex streaming and neither of us notice. Thank god for M.2 which killed off the rather serious bottlenecks with SATA.
Absolutely. I can double the speed* for a ~10-15X increase in power. But then you won't buy my core ;)
*In theory a massive ROB could do this, frontend bottlenecks notwithstanding.
The breakthrough has to come from software. Might need to reimagine our programming/system model altogether.
My computer has 130 processes on average, even if they are single threaded, they get all nicely distributed across all cores.
We are not in MS-DOS where a single application owns the hardware while it runs.
Sounds interesting but is that even possible?
Seems like it would have been the perfect fit for AMDs Bulldozer back then due to the chips worse single threaded performance and it's unused multi threaded performance in mainstream software.
I just did a little googling, and came across the Intel Optimation Reference Manual[1], and in Appendix C you can see how latency and throughput changed for architectures over time (e.g. table C-4). Being able to assess all the implications of these is beyond me currently, but if an operation goes from 5 clock cycles to 4 (or it ties up certain transisters less for other ops at the same time, my understanding is this stuff is super complex), that could be a huge boost for specific actions.
1: https://www.intel.com/content/dam/www/public/us/en/documents...
We can't make cores higher frequency, because the power consumption (and heat dissipation) is prohibitive.
Doing more per cycle? It's hard to see how more work could be squeezed out of most operations (maybe fdiv or div could be shrunk a few cycles), so you're left with introducing niche instructions or wider, more complex SIMD instructions.
Spending more of your time being productive? This requires more accurate branch prediction and other speculative execution, but everyone's freaking out and trying to rip out speculative execution because of a bug that lets you read memory you already have access to.
You might be able to squeeze out more performance, but you're looking at 10% gains, not 2× gains.
[1] https://www.anandtech.com/show/12893/intels-28core-5-ghz-cpu...
But I think threadripper 2 should have faster clock speeds regardless. The zen+ 12nm cores that it uses are known to have higher clock speeds.
So sure Intel can make 32 cores go fast, by taking a $10,000 chip (literally, it's a relabel of the Intel Xeon 8180), a giant power supply, impressive cooling, and a 735 watt pump. Still only has 75% of the memory bandwidth/memory channels of the AMD epyc.
My main hope with threadripper is that they hit the lower price points that the HEDT intel chips do (I.e. $300-$500).
1900x sells for ~$450. It's just the 8 core part, though — might as well grab the Ryzen 8 core for way less cost instead unless you need the memory b/w or PCIe lanes.
i7-7800x (Skylake-X) is a sort-of last gen part (Kabylake-X briefly existed in the form of i7-7740X, although only in a 4-core SKU); 4 GHz is its maximum turbo clock (may be only single core); base clock is 3.5.
1900x is current gen, although about to become last-gen; its base clock is 3.8, 4.0 turbo (single core).
Same number of memory channels. 33% more cores. AMD's IPC lags Intel a little bit, but not by 25%. Is it worth the $60 (15%) premium? Maybe.
When TR2's version of 1900x comes out, TR1 1900x may experience a nice price drop, making it (even) more competitive/affordable.
A bit of Googling verifies that you are at least partially correct: "Intel announced that it is releasing the Core i7-8086K, a special edition processor that commemorates the 40th anniversary of the 8086..." and "...reports speculated that Intel would only produce 50,000 units. Our sources have confirmed that this is a limited-edition chip, so Intel isn't positioning it against AMD's competing Ryzen processors."