Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.
Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.The latency has increased for SIMD instructions from 1 to 2 cycles. Because of this SSE instructions seems to suffer. So any workload using this instructions might see a slight regression from Zen4.View attachment 104756
Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.
I guess it will impact, as most executable are generic ones which are compiled for lowest common denominator. Win64 baseline is SSE2. So most generic application may not have significant improvement. It could change in Zen 6.Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.
That depends. SSE is the default [for scalars too] processing mode for floating point values for x64 architecture. The thing 1 cycle latency instructions got worse, and those are usually shuffles and you don't need to shuffle scalar values within the register. Add and multiply were already 3 cycles each and those were not affected. Actually SIMD int might be affected as vector int add was probably one cycle.Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.
It wasn't hard for Skymont to double 128b execution units, they had so few of them before It would be much more impressive if Lion Cove doubled number of 256 pipes, but they are probably facing the same limitations AMD is. Lion Cove will match Zen5 with AVX2 capabilities as it is actually playing catch-up to Zen4.X86-64 basic fp instruction set is SSE2, x87 could be used from x64 but ain't recommended and also not normally used at all. AVX/AVX2 has some support but as it's not supported on all cpu's even sold today support is quite minimally. AVX512 ain't supported pretty much on anything. AMD probably didn't know SIMD workload distribution when they started Zen5 design - Intel did back up AVX512 then pretty strongly. But even with AVX512 main desktop performance priority is on 128 bit SIMD - giving up 128 bit performance for wider vectors is just wrong bet from AMD. Intel goes to opposite direction - their E-core straight doubled 128 fp resources and Lion cove increased 256 bit fp units. Zen5 seems to face quite tough competition from Intel.
We get essentially 10% general improvement in INT, if not less.The 40% IPC improvement in SpecInt (an early leak) is consistent with my tests showing 30-35% improvement in raw scalar integer that isn't memory-bound.
Latency, what good are all those execution resources if you are waiting either for data or code to run. Games must be notorious for this, seeing how many of them are helped by x3d cache. Since Zen5 and Zen4 share the same connection characteristics from Core to L3 and from CCD to IOD afaik you won't see much improvement between Zen4 and Zen5 when that happens.
We get essentially 10% general improvement in INT, if not less.
How the heck can Zen 5 be somehow entirely memory-bound on scalar????
Are you implying that AMD's 128 bit vector perf has actually regressed?But even with AVX512 main desktop performance priority is on 128 bit SIMD - giving up 128 bit performance for wider vectors is just wrong bet from AMD
No, FPU can only do 4 operations per cycle (of any size). And up to 2 loads (of any length). The stores can be split, however. 1 x 512 bit or 2 x 128/256 bit.AFAIK unless I have read things completely wrong the larger units should just subdivide for smaller vectors allowing 4x 512 to become 8x 256, or 16x 128.
SSE replacing x87 basically started in 2000 with the Pentium 4. But with SSE came the option of SIMD, doing 2-4 tasks at a time. So any floating-point code requiring performance between 2000 and the early 2010s should have used SSE with SIMD. When AVX came along in the early 2010s it was a drop-in upgrade for most SIMD code.Wouldn't that impact most x86 workloads...? Programs basically don't use x87 nor AVX512 as I understand.
Yes there is extra latency there nowAre you implying that AMD's 128 bit vector perf has actually regressed?
AFAIK unless I have read things completely wrong the larger units should just subdivide for smaller vectors allowing 4x 512 to become 8x 256, or 16x 128.
MMX entered the chat.....But with SSE came the option of SIMD, doing 2-4 tasks at a time
SSE replacing x87 basically started in 2000 with the Pentium 4. But with SSE came the option of SIMD, doing 2-4 tasks at a time. So any floating-point code requiring performance between 2000 and the early 2010s should have used SSE with SIMD. When AVX came along in the early 2010s it was a drop-in upgrade for most SIMD code.
By this logic, most performant floating-point code updated in the past decade should be using AVX and thus should not be affected. Also realize that many applications don't use floating-point at all.
Of course there are always exceptions. A program I worked on used SSE and 80-bit x87 in a weird way that wouldn't translate well to AVX because there weren't enough x87 registers. Fortunately it's obsolete now, but it would have required a good deal of work to use AVX.
Also 3DNow! instruction set the year before SSE.
Edit: Oh interesting, 3DNow! actually started offering FP32 add/subtract/multiply operations before Intel had them with SSE.
There are further limits by the operation type [add, mul, complex permute, simple permute] which might be or might not be importantNo, FPU can only do 4 operations per cycle (of any size). And up to 2 loads (of any length). The stores can be split, however. 1 x 512 bit or 2 x 128/256 bit.
only for subset of instructions the most basic one already had more than 1 cycle latency so are not affectedYes there is extra latency there now
If not for this stupid segmentation policy, AVX512 could be more popular now, I mean Intel could fit somewhat limited implementation into Tiger Lake, and I remember part of the hardware for this limited implementation was already present on Skylake non X but fused off. But I would need to dig for source, since I might be remembering wronglyI think you meant SSE2 with the P4. SSE was on the P3 before that. When AVX came along in the early 2010's Intel used it as market segmentation. The lower end chips and didn't include it. If not for that, maybe AVX(2) would be more prevelant today. But that was par for the course for a long time with Intel.
I know there was SSE on P3, but I don't think they really pushed moving off the x87 FPU for non-SIMD work until the P4.I think you meant SSE2 with the P4. SSE was on the P3 before that.
Oh, yeah, I forgot about the broken Celery. (Celerons.)When AVX came along in the early 2010's Intel used it as market segmentation. The lower end chips and didn't include it. If not for that, maybe AVX(2) would be more prevelant today. But that was par for the course for a long time with Intel.
Story of AMD's life really.3DNow! was implemeted to make up for AMD's less than stellar x87 performance at the time. If AMD had more market share maybe it would've made more of a difference.
Fascinating...Latency, what good are all those execution resources if you are waiting either for data or code to run. Games must be notorious for this, seeing how many of them are helped by x3d cache. Since Zen5 and Zen4 share the same connection characteristics from Core to L3 and from CCD to IOD afaik you won't see much improvement between Zen4 and Zen5 when that happens.
I guess using synthetic benchmarks running completely from L1 cache, you would see noticeable improvements in int scalar execution between Zen5 vs Zen4. Therefore the uncore changes rumored for Zen6 might be more meaningful than IPC gain of the core, if current potential is not fully tapped. But to know that, we would need someone to hook a profiler and see where the problem lies. Maybe C&C will do that.
3DNow! was implemeted to make up for AMD's less than stellar x87 performance at the time. If AMD had more market share maybe it would've made more of a difference.
http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/ Ever so slightly, a percent or two.Are you implying that AMD's 128 bit vector perf has actually regressed?
AFAIK unless I have read things completely wrong the larger units should just subdivide for smaller vectors allowing 4x 512 to become 8x 256, or 16x 128.
Are you implying that AMD's 128 bit vector perf has actually regressed?
AFAIK unless I have read things completely wrong the larger units should just subdivide for smaller vectors allowing 4x 512 to become 8x 256, or 16x 128.
Biggest how? Area I doubt it's even half the size of GC's. Transistor count? Doubt that it'll approach any N3 core.AMD has biggest FP-unit of all in their cpu's
Biggest how? Area I doubt it's even half the size of GC's. Transistor count? Doubt that it'll approach any N3 core.
I think people keep overestimating the area needed to do the changes they did. Plus in mobile the FPU isn't wider, it's still 256-bit.
And yet it has the 1 cycle penalty (i.e. it's not a consequence of being 512 bit but of some other design hazard).
And yet a rather obvious low hanging fruit for future cores to improve upon.Theoretically most powerful - but in real usage cases might actually be worst performer. That's a pretty imbalanced situation.