I don't think we will be seeing unified DT & server IO chips anytime soon. Is this a stated goal by AMD?
Unified libraries and layouts of the common parts, FI the IMC cicuitry and other IFs, USB and so on.
I don't think we will be seeing unified DT & server IO chips anytime soon. Is this a stated goal by AMD?
I see you point nowUnified libraries and layouts of the common parts, FI the IMC cicuitry and other IFs, USB and so on.
That's a half node, so there won't be a doubling. AMD could just go for more execution resources and larger caches (more throughput per core).Next year 5nm EUV production starts at TSMC for small mobile ARM chips. So in 2021 will be available 5nm for Zen4. This basically means doubling CPU cores in package: desktop 32c/128t, Epyc & TR 112c/448t.
Unless Zen3 and Zen4 bring radical uArch efficiency improvements that simply is not possible, 5nm benefits are great for area, but only middling for power scaling.Next year 5nm EUV production starts at TSMC for small mobile ARM chips. So in 2021 will be available 5nm for Zen4. This basically means doubling CPU cores in package: desktop 32c/128t, Epyc & TR 112c/448t.
That's a half node, so there won't be a doubling. AMD could just go for more execution resources and larger caches (more throughput per core).
Meh, I'd rather AMD run Quad AVX2 and do op-fusion for AVX-512 instructions. I wouldn't follow Intel down the rabbit hole of huge FMA units (plus other functions).They would almost certainly use the die space to bulk up the core. AVX-512 as well.
Meh, I'd rather AMD run Quad AVX2 and do op-fusion for AVX-512 instructions. I wouldn't follow Intel down the rabbit hole of huge FMA units (plus other functions).
Not everything benefits from AVX-512, but more (most?) things benefit from MOAR CORES.Meh, I'd rather AMD run Quad AVX2 and do op-fusion for AVX-512 instructions. I wouldn't follow Intel down the rabbit hole of huge FMA units (plus other functions).
I think @Ajay is driving more towards like... Super-SIMD. 4x AVX2 operations or 2x AVX3 operations, rather than 2x AVX512, 2x AVX256, 2x AVX128.Not everything benefits from AVX-512, but more (most?) things benefit from MOAR CORES.
That's a half node, so there won't be a doubling. AMD could just go for more execution resources and larger caches (more throughput per core).
Not everything benefits from AVX-512, but more (most?) things benefit from MOAR CORES.
There are some workloads that respond well to SIMD but resist thread-level paralellism. It's also a matter of how you want to spend your power and area budget. One core with 4x256b FMACs will probably take less area and less power to operate than two cores with 2x256b FMACs. But if you're going to go wider, you have to rethink load/store and suchlike. I would assume that going wider would (overall) use less power than expanding on core count.
It would be just insane to introduce another AVX extension set for 1024b, considering how different AVX-2 and AVX-512 are (and what a monstrosity the latter is).
To a point yes, but just look at AVX 512 and the throttling it causes - CPU's were not supposed to be super wide vector crunchers.I would assume that going wider would (overall) use less power than expanding on core count
If pursuing wider vectors is a mistake, then why does Intel seem hellbent on doing so?
If pursuing wider vectors is a mistake, then why does Intel seem hellbent on doing so?
If pursuing wider vectors is a mistake, then why does Intel seem hellbent on doing so?
Rather than specifying a specific vector length, SVE allows CPU designers to choose the most appropriate vector length for their application and market, from 128 bits up to 2048 bits per vector register. SVE also supports a vector-length agnostic (VLA) programming model that can adapt to the available vector length. doption of the VLA paradigm allows you to compile or hand-code your program for SVE once, and then run it at different implementation performance points, while avoiding the need to recompile or rewrite it when longer vectors appear in the future. This reduces deployment costs over the lifetime of the architecture; a program just works and executes wider and faster.
Also pouring software dev efforts into GPU vector interplay with the CPU before they had a competitive platform to AMD would only end up strengthening their competitors hand.Intel does not have a competitive GPU solution
Wow, did something change these past few months? Seems I've been reading a lot of negativity on these forums surrounding AVX-512 lately. I thought AVX-512 was SIMD done right, as there was a lot of fanfare when it first became available.
Now though, there is more criticism than not it seems. And that's not to say that criticism is unwarranted mind you. But my, the times have changed I guess.
If pursuing wider vectors is a mistake, then why does Intel seem hellbent on doing so?
Wider vectors themselves aren't the problem. Inventing new incompatible extensions, every time you go wider, is. If Intel had done something like SVE (which scales from 128bit to 2048 bit) say, on Sandy Bridge, Ice-lake would still use the exact same instructions, just be 4x faster (by executing vectors up to 512 bit natively).
My hope is that if AMD indeed goes for SMT-4 (which is far from given)
Another wish is that instead of supporting most of AVX-512 extensions AMD would go for something more akin to ARM's SVE (Scalable Vector Extension) which scales from 128 bit to 2048 bit (no matter how wide the underlying hardware itself is).
- Intel does not have a competitive GPU solution.
I thought that AVX-512 already had a variable length extension (VL). Isn't that what VL does?