[HN Gopher] Skymont: Intel's E-Cores reach for the Sky
___________________________________________________________________
Skymont: Intel's E-Cores reach for the Sky
Author : ksec
Score : 34 points
Date : 2025-01-18 19:27 UTC (3 hours ago)
(HTM) web link (chipsandcheese.com)
(TXT) w3m dump (chipsandcheese.com)
| dragontamer wrote:
| Triple decoder is one unique effect. The fact that Intel managed
| to get them lined up for small loops to do 9x effective
| instruction issue is basically miraculous IMO. Very well done.
|
| Another unique effect is L2 shared between 4 cores. This means
| that thread communications across those 4 cores has much lower
| latencies.
|
| I've had lots of debates with people online about this design vs
| Hyperthreading. It seems like the overall discovery from Intel is
| that highly threaded tasks use less resources (cache, ROPs, etc.
| etc).
|
| Big cores (P cores or AMD Zen5) obviously can split into 2
| hyperthread, but what if that division is still too big? E cores
| are 4 threads of support in roughly the same space as 1 Pcore.
|
| This is because L2 cache is shared/consolidated, and other
| resources (ROP buffers, register files, etc. etc.) are just all
| so much smaller on the Ecore.
|
| It's an interesting design. I'd still think that growing the
| cores to 4way SMT (like Xeon Phi) or 8way SMT (POWER10) would be
| a more conventional way to split up resources though. But
| obviously I don't work at Intel or can make these kinds of
| decisions.
| 01HNNWZ0MV43FF wrote:
| > It seems like the overall discovery from Intel is that highly
| threaded tasks use less resources (cache, ROPs, etc. etc).
|
| Does that mean if I can take a single-threaded program and
| split it into multiple threads, it might use less power? I have
| been telling myself that the only reason to use threads is to
| get more CPU power or to call blocking APIs. If they're
| actually more power-efficient, that would change how I weigh
| threads vs. async
| dragontamer wrote:
| Not... quite. I think you've got the cause-and-effect
| backwards.
|
| Programmers who happen to write multiple-threaded programs
| don't need powerful cores, they want more cores. A Blender
| programmer calculating cloth physics would rather have 4x
| weaker cores than 1x P-core.
|
| Programmers who happen to write powerful singled-threaded
| programs need powerful cores. For example, AMD's "X3D" line
| of CPUs famously have 96MB of L3 cache, and video games that
| are on these very-powerful cores have much better
| performance.
|
| Its not "Programmers should change their code to fit the
| machine". From Intel's perspective, CPU designers should
| change their core designs to match the different kinds of
| programmers. Single-threaded (or low-thread) programmers...
| largely represented by the Video Game programmers... want
| P-cores. But not very much of them.
|
| Multithreaded programmers... represented by Graphics and a
| few others... want E-cores. Splitting a P-core into "only" 2
| threads is not sufficient, they want 4x or even 8x more
| cores. Because there's multiple communities of programmers
| out there, dedicating design teams to creating entirely
| different cores is a worthwhile endeavor.
|
| --------
|
| > Does that mean if I can take a single-threaded program and
| split it into multiple threads, it might use less power? I
| have been telling myself that the only reason to use threads
| is to get more CPU power or to call blocking APIs. If they're
| actually more power-efficient, that would change how I weigh
| threads vs. async
|
| Power-efficiency is going to be incredibly difficult moving
| forward.
|
| It should be noted that E-cores are not very power-efficient
| though. They're area efficient, IE Cheaper for Intel to make.
| Intel can sell 4x as many E-cores for roughly the same
| price/area as 1x P-core.
|
| E-cores are cost-efficient cores. I think they happen to use
| slightly less power, but I'm not convinced that power-
| efficiency is their particular design goal.
|
| If your code benefits from cache (ie: big cores), its
| probable that the lowest power-cost would be to run on large
| caches (like P-cores or Zen5 or Zen5 X3D). Communicating with
| RAM is always more power than just communicating with caches
| after all.
|
| If your code does NOT benefit from cache (ie: Blender
| regularly has 100GB+ scenes for complex movies), then all of
| those spare resources on P-cores are useless, as nothing fits
| anyway and the core will be spending almost all of its time
| waiting on RAM to do anything. So the E-core will be more
| power efficient in this case.
| Dwedit wrote:
| I see "ROP" and immediately think of Return Oriented
| Programming and exploits...
| dragontamer wrote:
| Lulz, I got some wires crossed. The CPU resource I meant to
| say was ROB: Reorder Buffer.
|
| I don't know why I wrote ROP. You're right, ROP means return
| oriented programming. A completely different thing.
| Zardoz84 wrote:
| > I've had lots of debates with people online about this design
| vs Hyperthreading. It seems like the overall discovery from
| Intel is that highly threaded tasks use less resources (cache,
| ROPs, etc. etc).
|
| AMD did something similar before. Anyone don't remember the
| Bulldozer cores sharing resources between pair of cores ?
| rwmj wrote:
| Slightly off topic, but if I'm aiming to get the fastest 'make
| -jN' for some random C project (such as the kernel) should I set
| N = #P + #E, or just the #P, or something else? Basically, is
| there a case where using the E cores slows a compile down?
|
| I timed it on the single Intel machine I have access to with
| E-cores and setting 'N' to the P+E cores was in fact the fastest,
| but I wonder if that's a general rule.
___________________________________________________________________
(page generated 2025-01-18 23:00 UTC)