5 ms·

I wonder what Intel's plan is for the future here. Will a future efficiency core support AVX-512? Or will intel just abandon it on consumer in favor of a varia

I wonder what Intel's plan is for the future here. Will a future efficiency core support AVX-512? Or will intel just abandon it on consumer in favor of a variable-length simd instruction set?

paulmd 4y ago
Crestmont is the next e-core after gracemont and appears to still not have AVX-512. It would be highly desirable for e-cores to implement microcoded AVX-512 support to break the heterogeneous-ISA problem, if nothing else. You don't need to use the same implementation but if you can support the same ISA via microcode then software doesn't need to worry about heterogeneous ISA. Maybe crestmont does the microcode thing, possibly, but in the die shots there aren't many visible changes in the vector unit vs gracemont design. The next p-core will continue to have AVX-512 but it will continue to be fused off. This obviously is completely insane, like, even if you validated Raptor Cove already and you can't just take AVX-512 out, you're just going to keep including it in all your future designs too? It's not an insignificant amount of area, even on consumer it's probably at least 10% extra area just to even support a 256b vector/microcode, and it just looks crazy to introduce and then abandon it at the exact moment your competitor adopts and supports it. Only thing I can think of is that maybe they have some other instructions which utilize microcode intrinsics implemented on the AVX-512 engines... like how Turing implements its Rapid Packed Math (dual-rate FP16) support using the tensor engines. Something else in the design that locks them into AVX-512 even if it is not externally exposed? But again, they don't even support it even if you turn off the e-cores entirely... why the fuck would you do that? It's like the most confusing resolution to this problem and satisfies nobody, probably not even Intel. I guess they flatly do not want to touch it at all for some reason. Note that this also includes mobile going forward since mobile will have big.LITTLE designs too... it's a serious amount of work and years of rollout they're pissing down the drain here.
- kristianp 4y ago
  Perhaps there wasn't enough lead time to get it into Crestmont after the decision to go with P+E for Alder Lake.
- rektide 4y ago
  It's going to be somewhat hilarious if Intel makes a AMD Bulldozer alike architecture for E-cores where there are AVX-512 units shared among 2 or 4 e-cores.
  - paulmd 4y ago
    To go back to a past tech-screed: CMT as implemented by Bulldozer is just SMT with inefficiently-allocated resources. If the frontend (cache, fetch, decode, scoreboarding) and the FPU and retirement are all shared, what exactly did Bulldozer have that was unique to each 'core'? It was an integer ALU dedicated to each thread, that's it. And that's functionally identical to SMT but with a dedicated ALU for each thread. And if one of the threads has enough ILP to occupy two units and the other one isn't being used... why not let the thread use them both and get more work done? https://news.ycombinator.com/item?id=34494484 https://news.ycombinator.com/item?id=34494484 So sure, let's do Bulldozer, a bunch of weaker but space-efficient threads (you know, e-cores) but put four threads on a single module sharing an AVX-512 unit, but let's also make it SMT so they can steal unoccupied execution units from other threads in their module. We could call it... Xeon Phi. ;) https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing And sure maybe Bulldozer was "ahead of its time" but I think that probably undersells just how weak they are especially when threads in a module start contending for shared resources. Both Bulldozer and Xeon Phi get incredibly weak when multiple threads are on a module, the higher threadcount is offset by a reduction in IPC too. And while that is still probably a net perf-per-area gain, your application really has to like threads for it to be worth it. I'm gonna say it: if you think Bulldozer was "ahead of its time" then so was Larrabee and Xeon Phi. Bulldozer was a first stab at this Xeon Phi idea for AMD. And in both cases I'm not 100% sure it was worth it. The market doesn't seem to have thought so. Now again: the devil is kinda in the details. It all depends what is shared. If you can make it so the performance hit is really small except for the shared FPU, that's one thing - there's nothing inherently wrong with this idea, that's what the Sun Niagara series does too. But Sun Niagara is also noted for comparatively weak FP performance (it's an integer-monster for database work). It all depends on just how much duplication per-thread and how much shared resource and how much area benefit it gets you. But like, take a Niagara core, and let's say we have a couple threads with an opportunity for a bunch of ILP and a bunch of unused execution units sitting there. Why should you not launch onto them? That's the CMT vs SMT question to me. And it's fine if the answer is "scheduling complexity" but you need to think about that question before just blindly pinning resources to specific threads. And again none of this is to dump on e-cores specifically. Intel's P-cores are too big, they are like triple the transistor count of AMD for a smidge more performance. I think the long-term future lies in the e-cores for Intel, they will replace Coves with Monts eventually. Sierra Forest is the most interesting Intel product in a long time imo. AMD is in less need of e-cores, a Zen3 core only has about 2x the transistor count of a Gracemont core and to me that's fine, it's an SMT core with higher per-thread performance too, that's a reasonable sidegrade. AMD's strategy of pursing "compact" cores makes sense to me, they don't need a whole separate e-core, their P-cores are already area-efficient. They just are going to squeeze the last 10-20% out of it for area-optimized applications and call it a day. (AMD has done a really good job avoiding cruft - supposedly Zen3 was a from-scratch redesign (Zen2 was actually supposedly a tweak, according to AMD's engineering lead), etc. And they've built this modularity of design that lets them embrace semicustom and advanced packaging and make innovative products and not just architectures. It really feels like Intel has been coasting on the Sandy Bridge design for a long time now, not even the kinds of Zen2->3 shifts, just incremental tweaks. Their iGPU stuff is evidently just as tightly tied to the CPU side as the CPU stuff is to their nodes, everything at Intel is obviously just one giant ball of mud at this point and it's incremental changes and legacy cruft all the way down. I am very down on Intel lately because even completely ignoring the current set of products and their merits, AMD is executing well and Intel is simply not. They've had 6 years since the Ryzen launch to turn things around and they still can't do the job right. AMD is obviously the better company right now in the Warren Buffett "own stocks that you'd want to buy the product" sense.) https://www.youtube.com/watch?v=3vyNzgOP5yw https://www.youtube.com/watch?v=3vyNzgOP5yw But I'm just not sure the Xeon Phi/Bulldozer/Niagara concept has really worked all that well in practice. Anyway it's also possible that instead of sharing one unit among four cores, they put a unit in each core but it executes over multiple cycles, like AMD did with Zen1/Zen+ and 256b vectors. Or you have two 256b units that fuse to become a 512b unit. That seems to have been the design trend recently, that's how AMD does their AVX-512 on Zen4. But those kinds of changes are what I mean when I say "if there were changes in the vector units it would probably show up on the die shots". Crestmont die shots seem to show a pretty unchanged AVX unit from Gracemont - it seems unlikely they changed it too significantly. https://www.semianalysis.com/p/meteor-lake-die-shot-and-architecture https://www.semianalysis.com/p/meteor-lake-die-shot-and-arch... https://twitter.com/Locuza_/status/1524441315441786881 https://twitter.com/Locuza_/status/1524441315441786881

I wonder what Intel's plan is for the future here. Will a future efficiency core support AVX-512? Or will intel just abandon it on consumer in favor of a variable-length simd instruction set?

paulmd 4y ago

Crestmont is the next e-core after gracemont and appears to still not have AVX-512. It would be highly desirable for e-cores to implement microcoded AVX-512 support to break the heterogeneous-ISA problem, if nothing else. You don't need to use the same implementation but if you can support the same ISA via microcode then software doesn't need to worry about heterogeneous ISA. Maybe crestmont does the microcode thing, possibly, but in the die shots there aren't many visible changes in the vector unit vs gracemont design. The next p-core will continue to have AVX-512 but it will continue to be fused off. This obviously is completely insane, like, even if you validated Raptor Cove already and you can't just take AVX-512 out, you're just going to keep including it in all your future designs too? It's not an insignificant amount of area, even on consumer it's probably at least 10% extra area just to even support a 256b vector/microcode, and it just looks crazy to introduce and then abandon it at the exact moment your competitor adopts and supports it. Only thing I can think of is that maybe they have some other instructions which utilize microcode intrinsics implemented on the AVX-512 engines... like how Turing implements its Rapid Packed Math (dual-rate FP16) support using the tensor engines. Something else in the design that locks them into AVX-512 even if it is not externally exposed? But again, they don't even support it even if you turn off the e-cores entirely... why the fuck would you do that? It's like the most confusing resolution to this problem and satisfies nobody, probably not even Intel. I guess they flatly do not want to touch it at all for some reason. Note that this also includes mobile going forward since mobile will have big.LITTLE designs too... it's a serious amount of work and years of rollout they're pissing down the drain here.

kristianp 4y ago
Perhaps there wasn't enough lead time to get it into Crestmont after the decision to go with P+E for Alder Lake.
rektide 4y ago
It's going to be somewhat hilarious if Intel makes a AMD Bulldozer alike architecture for E-cores where there are AVX-512 units shared among 2 or 4 e-cores.
- paulmd 4y ago
  To go back to a past tech-screed: CMT as implemented by Bulldozer is just SMT with inefficiently-allocated resources. If the frontend (cache, fetch, decode, scoreboarding) and the FPU and retirement are all shared, what exactly did Bulldozer have that was unique to each 'core'? It was an integer ALU dedicated to each thread, that's it. And that's functionally identical to SMT but with a dedicated ALU for each thread. And if one of the threads has enough ILP to occupy two units and the other one isn't being used... why not let the thread use them both and get more work done? https://news.ycombinator.com/item?id=34494484 https://news.ycombinator.com/item?id=34494484 So sure, let's do Bulldozer, a bunch of weaker but space-efficient threads (you know, e-cores) but put four threads on a single module sharing an AVX-512 unit, but let's also make it SMT so they can steal unoccupied execution units from other threads in their module. We could call it... Xeon Phi. ;) https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing And sure maybe Bulldozer was "ahead of its time" but I think that probably undersells just how weak they are especially when threads in a module start contending for shared resources. Both Bulldozer and Xeon Phi get incredibly weak when multiple threads are on a module, the higher threadcount is offset by a reduction in IPC too. And while that is still probably a net perf-per-area gain, your application really has to like threads for it to be worth it. I'm gonna say it: if you think Bulldozer was "ahead of its time" then so was Larrabee and Xeon Phi. Bulldozer was a first stab at this Xeon Phi idea for AMD. And in both cases I'm not 100% sure it was worth it. The market doesn't seem to have thought so. Now again: the devil is kinda in the details. It all depends what is shared. If you can make it so the performance hit is really small except for the shared FPU, that's one thing - there's nothing inherently wrong with this idea, that's what the Sun Niagara series does too. But Sun Niagara is also noted for comparatively weak FP performance (it's an integer-monster for database work). It all depends on just how much duplication per-thread and how much shared resource and how much area benefit it gets you. But like, take a Niagara core, and let's say we have a couple threads with an opportunity for a bunch of ILP and a bunch of unused execution units sitting there. Why should you not launch onto them? That's the CMT vs SMT question to me. And it's fine if the answer is "scheduling complexity" but you need to think about that question before just blindly pinning resources to specific threads. And again none of this is to dump on e-cores specifically. Intel's P-cores are too big, they are like triple the transistor count of AMD for a smidge more performance. I think the long-term future lies in the e-cores for Intel, they will replace Coves with Monts eventually. Sierra Forest is the most interesting Intel product in a long time imo. AMD is in less need of e-cores, a Zen3 core only has about 2x the transistor count of a Gracemont core and to me that's fine, it's an SMT core with higher per-thread performance too, that's a reasonable sidegrade. AMD's strategy of pursing "compact" cores makes sense to me, they don't need a whole separate e-core, their P-cores are already area-efficient. They just are going to squeeze the last 10-20% out of it for area-optimized applications and call it a day. (AMD has done a really good job avoiding cruft - supposedly Zen3 was a from-scratch redesign (Zen2 was actually supposedly a tweak, according to AMD's engineering lead), etc. And they've built this modularity of design that lets them embrace semicustom and advanced packaging and make innovative products and not just architectures. It really feels like Intel has been coasting on the Sandy Bridge design for a long time now, not even the kinds of Zen2->3 shifts, just incremental tweaks. Their iGPU stuff is evidently just as tightly tied to the CPU side as the CPU stuff is to their nodes, everything at Intel is obviously just one giant ball of mud at this point and it's incremental changes and legacy cruft all the way down. I am very down on Intel lately because even completely ignoring the current set of products and their merits, AMD is executing well and Intel is simply not. They've had 6 years since the Ryzen launch to turn things around and they still can't do the job right. AMD is obviously the better company right now in the Warren Buffett "own stocks that you'd want to buy the product" sense.) https://www.youtube.com/watch?v=3vyNzgOP5yw https://www.youtube.com/watch?v=3vyNzgOP5yw But I'm just not sure the Xeon Phi/Bulldozer/Niagara concept has really worked all that well in practice. Anyway it's also possible that instead of sharing one unit among four cores, they put a unit in each core but it executes over multiple cycles, like AMD did with Zen1/Zen+ and 256b vectors. Or you have two 256b units that fuse to become a 512b unit. That seems to have been the design trend recently, that's how AMD does their AVX-512 on Zen4. But those kinds of changes are what I mean when I say "if there were changes in the vector units it would probably show up on the die shots". Crestmont die shots seem to show a pretty unchanged AVX unit from Gracemont - it seems unlikely they changed it too significantly. https://www.semianalysis.com/p/meteor-lake-die-shot-and-architecture https://www.semianalysis.com/p/meteor-lake-die-shot-and-arch... https://twitter.com/Locuza_/status/1524441315441786881 https://twitter.com/Locuza_/status/1524441315441786881