From: user5857@newsgrouper.org.invalid   
      
   anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:   
      
   > BGB  writes:   
   > >On 9/17/2025 4:33 PM, John Levine wrote:   
   > >> According to BGB  :   
   --------------------------------------   
   >   
   > I have thought about why the idea of more smaller cores has not been   
   > more successful, at least for the kinds of loads where you have a   
   > large number of independent and individually not particularly   
   > demanding threads, as in web shops.  My explanation is that you need   
   > 1) memory bandwidth and 2) interconnection with the rest of the   
   > system.   
      
   Yes, exactly:: if you have a large number of cores doing a performance of   
   X, they will need exactly the same memory BW as a smaller number of cores   
   also performing at X.   
      
   In addition, the interconnect has to be at least as good as the small core   
   system.   
      
   > The interconnection with the rest of the system probably does   
   > not get much cheaper for the smaller cores, and probably becomes more   
   > expensive with more cores (e.g., Intel switched from a ring to a grid   
   > when they increased the cores in their server chips).   
   >   
   > The bandwidth requirements to main memory for given cache sizes per   
   > core reduce linearly with the performance of the cores; if the larger   
   > number of smaller cores really leads to increased aggregate   
   > performance, additional main memory bandwidth is needed, or you can   
   > compensate for that with larger caches.   
      
   Sooner or later, you actually have to read/write main memory.   
      
   > But to eliminate some variables, let's just consider the case where we   
   > want to get the same performance with the same main memory bandwidth   
   > from using more smaller cores than we use now.  Will the resulting CPU   
   > require less area?  The cache sizes per core are not reduced, and   
   > their area is not reduced much.   
      
   A core running at ½ the performance can use a cache that is ¼ the size   
   and see the same percentage degradation WRT cache misses (as long as   
   main memory is equally latent). TLBs too.   
      
   >                                The core itself will get smaller, and   
      
   12× smaller and 12× lower power   
      
   > its performance will also get smaller (although by less than the   
   > core).   
      
   for ½ the performance   
      
   >         But if you sum up the total per-core area (core, caches, and   
   > interconnect), at some point the per-core area reduces by less than   
   > the per-core performance, so for a given amount of total performance,   
   > the area goes up.   
      
   GBOoO Cores tend to be about the size of 512KB of L2   
      
   > There is one counterargument to these considerations: The largest   
   > configuration of Turin dense has less cache for more cores than the   
   > largest configuration of Turin.  I expect that's the reason why they   
   > offer both; if you have less memory-intensive loads, Turin dense with   
   > the additional cores will give you more performance, otherwise you   
   > better buy Turin.   
   >   
   > Also, Intel has added 16 E-Cores to their desktop chips without giving   
   > them the same amount of caches as the P-Cores; e.g., in Arrow lake we   
   > have   
   >   
   > P-core 48KB D-L0 64KB I-L1 192KB D-L1 3MB L2         3MB L3/core   
   > E-Core 32KB D-L1 64KB I-L1            4MB L2/4 cores 3MB L3/4cores   
   >   
   > Here we don't have an alternative with more P-Cores and the same   
   > bandwidth, so we cannot contrast the approaches.  But it's certainly   
   > the case that if you have a bandwidth-hungry load, you don't need to   
   > buy the Arrow Lake with the largest number of E-Cores.   
   >   
   > - anton   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)