4 ms·

I remember as part of the TBB library release, Intel remarked that 100 pentium cores had the same transistor count of a core2. Took a while, but starting to tur

I remember as part of the TBB library release, Intel remarked that 100 pentium cores had the same transistor count of a core2. Took a while, but starting to turn the corner on slower and wider becoming more common.

deleted 2y ago
[deleted]
imtringued 2y ago
The problem with adding more cores is that SRAM is the real bottleneck. Adding more cores means more cache. Until someone figures out how to do 3D stackable SRAM similar to how SSDs work, SRAM will always consume most of the area on your chip.
- wmf 2y ago
  It's called V-Cache.
  - Rohansi 2y ago
    V-cache is just L3 which is shared between cores. L1 and L2 are still within each core.
- JonChesterfield 2y ago
  This isn't fill the reticle with CPU, it's make a dozen separate chips and package them on a network fabric. Amount of cache can increase linearly with number of cores without a problem. There is some outstanding uncertainty about cache coherency vs performance as N goes up which shows up in numa cliff fashion. My pet theory is that'll be what ultimately kills x64 - the concurrency semantics are skewed really hard towards convenience and thus away from scalability.
  - doctor_eval 2y ago
    I know next to nothing about CPU architecture so please forgive a stupid question. Are you saying that the x86 memory model means RAM latency is more impactful than on some other architectures? Is this (tangentially) related to the memory mode that Apple reportedly added to the M1 to emulate x86 memory model to make emulation faster? - presumably to account for assumptions that compilers make about the state of the CPU after certain operations?
    - CoastalCoder 2y ago
      I'm guessing GP's point is that x86 makes really strong memory consistency guarantees. It makes life easier for programmers of multithreaded software, but at the cost of high synchronization overhead. Contrast to e.g. Arm, where programmers can avoid a lot of that synchronization, but in exchange they have to be more careful. * IIRC from some recent reading.
    - inkyoto 2y ago
      The preceding comment was about the CPU cache coherency, which is the bane of the symmetric multiprocessor (SMP) system design. The problem arises due to the fact the main memory is shared across processors (or CPU cores). Consider this rough sketch: [memory (shared)] ⇕ [L3 cache (shared)] ⇕ [core 0] ⟺ [L1 cache (private)] ⟺ [L2 cache (shared)] ⟺ [L1 cache (private)] ⟺ [core N] ⇕ [core 1] ⟺ [L1 cache (private)] Each CPU (or CPU core) has its own private L1 cache that other CPU's/CPU cores do not have access to. Now, code running on the CPU 0 has modified 32 bytes at the address 0x1234 but the modification does not occur directly in the main memory, it takes places within a cache and changes to the data now have to be written back into the main memory. Depending on the complexity of the system design, the change has to be back propagates through a hierarchy of L2/L3/L4 (POWER CPU's have a L4 cache) caches until the main memory that is shared across all CPU's is updated. It is easy and simple if no other CPU is trying to access the address 0x1234 at the same time – the change is simply written back and the job is done. But when another CPU is trying to access the same 0x1234 address at the same time whilst the change has not made it back into the main memory, there is a problem as stale data reads are typically not allowed, and another CPU / CPU cores has to wait for the CPU 0 to complete the write back. Since multiple cache level are involved in modern system design, the problem is known as the cache coherency problem, and it is a very complex problem to solve in SMP designs. It is a grossly oversimplified description of the problem, but it should be able to illustrate what the parent was referring to.
- fulafel 2y ago
  The real real problem is that we don't know how to effectively use growing transistor budgets to speed applications up compared to the single core era. Adding cache and more cores are both options that make for very sublinear improvements at the margin. (for 95% of usage - somen niche things can utilize resources better, those not coincidentally often being the focus of benchmarks)
- sva_ 2y ago
  Isn't that what AMD 3D V-Cache does? https://www.amd.com/en/products/processors/technologies/3d-v-cache.html https://www.amd.com/en/products/processors/technologies/3d-v...
dialup_sounds 2y ago
Reminds me of the ill-fated Larabee, which was supposed to be something like 50 Pentium-like cores in a GPU-shaped trenchcoat.
- hajile 2y ago
  Larabee was launched as the first generation Knight-series chip (it even had the GPU-specific stuff still in there disabled IIRC). I believe the Knight-series chips were killed because they ran into a bunch of issues and politics with Knight's Mill then killed it in favor of their upcoming GPU architecture only for that to have issues and be delayed too. I suspect that a RISC-V version of Larabee would work better as the ratio of SIMD to the rest of the core would be a lot better.
  - kijiki 2y ago
    A dual-issue in-order RISC-V isn't enough smaller than a P54c to make a significant difference. The overwhelming majority of Larabee's area went to SIMD units and caches.
    - hajile 2y ago
      Do you have any evidence for this statement? Their actual core wasn’t a Pentium. It added in most/all the x86 bloat from the last 3 decades too. Cutting all that stuff and saving power means you can squeeze in a couple more cores and improve performance that more. 32 registers a significant advantage too. RVV also allows wider vectors than AVX. Without reordering, you can get stronger performance guarantees from a single, wide SIMD than from two narrow SIMD (it’s also possible to look at the next couple instructions and switch between executing one at full width or two at half width each without massive investment). And we haven’t even reached peak advantage yet. RISCV has the option for 48/64 bit instructions with loads of room to add VLIW instructions. While most VLIW implementations require everything to be VLIW, this would be optional in RISCV. Your core could be dual issuing two wide VLIW allowing a single thread to theoretically use four vector units. If you add in 4-8 wide SMT, the result is something very GPU-like while still using standard RISCV. Maybe x86 can do this too, but I don’t think it would be anywhere near as efficient and it would certainly eat up a lot of the precious remaining opcode space.

deleted 2y ago

[deleted]

imtringued 2y ago

The problem with adding more cores is that SRAM is the real bottleneck. Adding more cores means more cache. Until someone figures out how to do 3D stackable SRAM similar to how SSDs work, SRAM will always consume most of the area on your chip.

wmf 2y ago
It's called V-Cache.
- Rohansi 2y ago
  V-cache is just L3 which is shared between cores. L1 and L2 are still within each core.
JonChesterfield 2y ago
This isn't fill the reticle with CPU, it's make a dozen separate chips and package them on a network fabric. Amount of cache can increase linearly with number of cores without a problem. There is some outstanding uncertainty about cache coherency vs performance as N goes up which shows up in numa cliff fashion. My pet theory is that'll be what ultimately kills x64 - the concurrency semantics are skewed really hard towards convenience and thus away from scalability.
- doctor_eval 2y ago
  I know next to nothing about CPU architecture so please forgive a stupid question. Are you saying that the x86 memory model means RAM latency is more impactful than on some other architectures? Is this (tangentially) related to the memory mode that Apple reportedly added to the M1 to emulate x86 memory model to make emulation faster? - presumably to account for assumptions that compilers make about the state of the CPU after certain operations?
  - CoastalCoder 2y ago
    I'm guessing GP's point is that x86 makes really strong memory consistency guarantees. It makes life easier for programmers of multithreaded software, but at the cost of high synchronization overhead. Contrast to e.g. Arm, where programmers can avoid a lot of that synchronization, but in exchange they have to be more careful. * IIRC from some recent reading.
  - inkyoto 2y ago
    The preceding comment was about the CPU cache coherency, which is the bane of the symmetric multiprocessor (SMP) system design. The problem arises due to the fact the main memory is shared across processors (or CPU cores). Consider this rough sketch: [memory (shared)] ⇕ [L3 cache (shared)] ⇕ [core 0] ⟺ [L1 cache (private)] ⟺ [L2 cache (shared)] ⟺ [L1 cache (private)] ⟺ [core N] ⇕ [core 1] ⟺ [L1 cache (private)] Each CPU (or CPU core) has its own private L1 cache that other CPU's/CPU cores do not have access to. Now, code running on the CPU 0 has modified 32 bytes at the address 0x1234 but the modification does not occur directly in the main memory, it takes places within a cache and changes to the data now have to be written back into the main memory. Depending on the complexity of the system design, the change has to be back propagates through a hierarchy of L2/L3/L4 (POWER CPU's have a L4 cache) caches until the main memory that is shared across all CPU's is updated. It is easy and simple if no other CPU is trying to access the address 0x1234 at the same time – the change is simply written back and the job is done. But when another CPU is trying to access the same 0x1234 address at the same time whilst the change has not made it back into the main memory, there is a problem as stale data reads are typically not allowed, and another CPU / CPU cores has to wait for the CPU 0 to complete the write back. Since multiple cache level are involved in modern system design, the problem is known as the cache coherency problem, and it is a very complex problem to solve in SMP designs. It is a grossly oversimplified description of the problem, but it should be able to illustrate what the parent was referring to.
fulafel 2y ago
The real real problem is that we don't know how to effectively use growing transistor budgets to speed applications up compared to the single core era. Adding cache and more cores are both options that make for very sublinear improvements at the margin. (for 95% of usage - somen niche things can utilize resources better, those not coincidentally often being the focus of benchmarks)
sva_ 2y ago
Isn't that what AMD 3D V-Cache does? https://www.amd.com/en/products/processors/technologies/3d-v-cache.html https://www.amd.com/en/products/processors/technologies/3d-v...

dialup_sounds 2y ago

Reminds me of the ill-fated Larabee, which was supposed to be something like 50 Pentium-like cores in a GPU-shaped trenchcoat.

hajile 2y ago
Larabee was launched as the first generation Knight-series chip (it even had the GPU-specific stuff still in there disabled IIRC). I believe the Knight-series chips were killed because they ran into a bunch of issues and politics with Knight's Mill then killed it in favor of their upcoming GPU architecture only for that to have issues and be delayed too. I suspect that a RISC-V version of Larabee would work better as the ratio of SIMD to the rest of the core would be a lot better.
- kijiki 2y ago
  A dual-issue in-order RISC-V isn't enough smaller than a P54c to make a significant difference. The overwhelming majority of Larabee's area went to SIMD units and caches.
  - hajile 2y ago
    Do you have any evidence for this statement? Their actual core wasn’t a Pentium. It added in most/all the x86 bloat from the last 3 decades too. Cutting all that stuff and saving power means you can squeeze in a couple more cores and improve performance that more. 32 registers a significant advantage too. RVV also allows wider vectors than AVX. Without reordering, you can get stronger performance guarantees from a single, wide SIMD than from two narrow SIMD (it’s also possible to look at the next couple instructions and switch between executing one at full width or two at half width each without massive investment). And we haven’t even reached peak advantage yet. RISCV has the option for 48/64 bit instructions with loads of room to add VLIW instructions. While most VLIW implementations require everything to be VLIW, this would be optional in RISCV. Your core could be dual issuing two wide VLIW allowing a single thread to theoretically use four vector units. If you add in 4-8 wide SMT, the result is something very GPU-like while still using standard RISCV. Maybe x86 can do this too, but I don’t think it would be anywhere near as efficient and it would certainly eat up a lot of the precious remaining opcode space.