4 ms·
The V2 decision to go with 4 128 bit vector pipes instead of 2 236 bit ones is a bit odd, maybe due to sharing some of the design with the N2? Or maybe they wa
by Symmetry 4y ago
The V2 decision to go with 4 128 bit vector pipes instead of 2 236 bit ones is a bit odd, maybe due to sharing some of the design with the N2? Or maybe they want to keep things compatible so code can be migrated from a V2 to a smaller core.
- vgatherps 4y agoIt also means that code using smaller vectors from an older version just gets faster, as long as the new core can schedule/retire instructions fast enough to keep up. If it can't then going for 256 bit is the best choice although it seems like newer chips are going for wider execution (and that each 128 bit unit is in fact individually accessible).
- rbanffy 4y agoCan modern chips hold instructions from different processes in the reorder buffer tagging them by their context/PID? If so, up to four processes could be running 128-bit SIMD ops concurrently.
- wmf 4y agoThat's SMT but Neoverse cores don't use it.
- rbanffy 4y agoSMT would be from “virtual” cores. Does the reorder buffer get emptied when a processor switches context or do the in-flight instructions continue there and instructions from a different process start coming in?
- wmf 4y agoI assume the kernel code to perform the context switch is big enough to fill the ROB.
- rbanffy 4y agoGood point, still, context switch code can enter the ROP before the previous instruction flow is retired. Is the ROB explicitly flushed or can instructions from different processes (or a user process and the kernel) coexist in the ROB?
- saagarjha 4y agoNow that’s a relevant username ;)
- vgatherps 4y agoIt crossed my mind is that this only is valid as long as you can reasonable expect most of the uses themselves to have enough ILP, not just the hardware scheduler. I'm thinking back to some linear algebra code I wrote which was bounded by min(loads-per-cycle, FMA per cycle). Adding more fma units there wouldn't help if you didn't increase load units equivalently, so for this sort of software wider vector units are better.
- brigade 4y agoV1 already had 4 128bit pipes, SVE just used two simultaneously. The only real gain in benchmarks on V1 with 256bit SVE over 128bit NEON was in load-heavy kernels that were bottlenecked by the 5-wide decode, and weren't saved by the MOP cache. Improving decode width is easier now that 32-bit is dead (or maybe V2's MOP cache was improved enough...), so 256bit wide isn't terribly useful unless they commit the transistors and power budget for an even wider backend than 512bit/cycle.