rentable units isn't just clustering p-cores, it's clustering (or, co-locating) p-cores together with e-cores, which is exactly what this patent is about. thos

rentable units isn't just clustering p-cores, it's clustering (or, co-locating) p-cores together with e-cores, which is exactly what this patent is about. those aren't separate things. the idea is sort of a bulldozer CMT-ish thing, where resources are shared between a couple dedicated cores, but where threads can move more freely between the cores in a module, rather than having to jump all the way to e-cores that live someplace completely different. because they're still dedicated cores, they benefit from the complexity reduction of not having CMT and not having to worry about scoreboarding/visibility for 4 different threads (SMT4 was the alternative plan and I suspect rentable units will do 1P/3E clusters too) and you gain the ability to run a couple extra threads doing low-intensity busywork, but still retain the ability to move it to a p-core and get it crunching if there's a high-intensity segment. (and obviously from there the need to be able to predict whether a thread is going to be intense or busywork shakes out of this... which is why Intel went to the Thread Director™ despite that seemingly being hilariously overkill for the problems Alder Lake faces... it is, but it's not overkill for where intel wants to go with rentable cores. It seems like there is definitely some performance-power-area overhead to be extracted from scheduling, if it leads to better utilization of core resources per mm2 of die area.) right now a big part of the problem with e-cores is that intel's e-cores fucking suck and they're bolted awkwardly onto the side of the "traditional" p-core. even within the e-core "CCX"/"module" the latency is atrocious, even within the e-core cluster every single inter-core communication must go all the way back to the ringbus (cache eviction is hard) and it's 50ms to go core-to-core even within the same e-core CCX. and this is why "e-cores are not good for gaming", and not good for a lot of productivity workloads currently. like right now it's basically only for cinebench and some other embarassingly-parallel tasks that have always required minimal inter-thread communication/synchronization, that's why ryzen did well at cinebench too. (take a guess which ones are the e-cores in this table... like that's batshit, inside a CCX is the slowest latency in the whole processor? how the fuck does that work? even early zen had good latency inside a CCX. What led to this, did they intentionally design it so that local was the most expensive, and if so why?) https://images.anandtech.com/doci/17601/Core%20i9-13900K%20Core%20to%20core%20latency%203.jpg https://images.anandtech.com/doci/17601/Core%20i9-13900K%20C... https://images.anandtech.com/doci/17047/12900K%20Bounce.png https://images.anandtech.com/doci/17047/12900K%20Bounce.png Like I love the atom family/e-cores generally, but the alder lake/raptor lake design just ain't it as far as big.little. on top of this weird latency you've also got the broken DLVR which results in the e-cores getting way too much voltage since they share a rail. and if you're using the voltage you might as well clock high anyway and get some work done, which has led to this dumb "e-cores are about area, not power" meme. No, not particularly, and power/area are the same thing in most instances (high-density libraries are high-efficiency libraries). They're just poorly-integrated and have to be run at an excessively high/inefficient frequency because the DLVR team couldn't execute properly (as many teams at intel are not) if you can get rid of that latency overhead it will be a lot more applicable to games and other productivity tasks. and I think amd's zen5c core idea will achieve this - I think crossing CCDs (like in 7950X) will still be penalized but if you lasso a game to only use the c-core CCD, performance will be exactly as expected for a zen5 core of the appropriate clock/cache amount. it has all the same CCX structures (ringbus!), why wouldn't it be the same? So if you can come up with a game model that works across CCDs right now, it should work on AMD's big.little implementation too. but intel's going at a slightly different tack. if they can get the e-cores in the CCX itself then there's no latency overhead for using them. so you can effectively accomplish the "main thread that dumps side work into a queue for the Peripheral Processors to clean up" or keep multiple threads that incorporate a high-intensity/low-intensity mix running with high IPC, but without the area overhead of making every core a p-core. this is a more crucial battle for intel since they use an insane amount of area in raptor cove - their p-cores are extremely large and if they don't saturate them they're throwing away performance. Again, the plan B here was SMT4. if you can make this rentable unit idea work, you can have a big powerful p-core with lots of execution resources, but actually saturate those resources completely such that they're not wasted. and that's a PPA gain. the e-cores handle the low-intensity processing and get things lined up while the p-core blitzes the hard parts, and those e-cores can be more "right-sized" to the average throughput. So you can "daily-drive the Prius and when you need a truck you just rent it", so to speak. And unlike SMT you don't have to maintain this crazy abstraction of visibility and timing, which seems like it has to be making the speculative execution/sidechannel leakage problems massively worse. And with SMT4 the area overhead has to be non-trivial to do the bookwork, again especially when you have to assume adversarial behavior attempting to suss out any timing correctness issues. Absolute 100% correctness is always slower/more expensive, and if you only run 1 thread per core you sidestep intracore visibility issues entirely and just have to work at the level of scoreboard-level/unit-level correctness. alternatively, I've also heard the idea raised that maybe the e-cores can be fused to become a p-core, share their execution resources across a single thread, but they can run in parallel if there's not a need. I'm dubious on that concept (2 cores working on 1 set of registers seems like it would present correctness issues that would have to be carefully addressed). But the "CMT but not all threads are equal" idea is perfectly plausible especially if you build some smarts into the scheduling. And they can share things like an FPU/vector unit, or a neural accelerator unit, etc within the CMT module, without blowing up the area 4x to support "average" code that doesn't even use that accelerator. You can pretend to the OS that all cores support this instruction (so you don't run into the AVX-512 problem) and then just schedule them on the shared unit as needed. Anyway all of this is of course extremely ironic given that AMD had a difficult time with the CMT idea with bulldozer, and then went back and copied intel with SMT. Now Intel is copying AMD with high-clocked CMT designs that chase area efficiency by sharing resources and chases high frequency by eliminating SMT complexity... but honestly maybe the time is right to ditch SMT with specter/side-channels being a massive headache right now. As crazy as it sounds, apparently it was designed by Jim Keller while he was at intel. And lord know he’s got the Midas touch. Like can someone else please have some ideas for a change lmao