8 ms·

Intel's Lion Cove Architecture Preview

175 points by zdw 2y ago

andrewia 2y ago
I'm very interested to see independent testing of cores without SMT/hyperthreading. Of course it's one less function for the hardware and thread scheduler to worry about. But hyperthreading was a useful way to share resources between multiple threads that had light-to-intermediate workloads. Synthetic benchmarks might show an improvement but I'm interested to see what everyday workloads, like web browsing while streaming a video, will react.
- adrian_b 2y ago
  I was surprised that disabling SMT has improved by a few percents the Geekbench 6 multi-threaded results on a Zen 3 (5900X) CPU. While there are also other tasks where SMT does not bring advantages, for the compilation of a big software project SMT does bring an obvious performance improvement, of about 20% for the same Zen 3 CPU. In any case, Intel has said that they have designed 2 versions of the Lion Cove core, one without SMT for laptop/desktop hybrid CPUs and one with SMT for server CPUs with P cores (i.e. for the successor of Granite Rapids, which will be launched later this year, using P-cores similar to those of Meteor Lake).
  - papichulo2023 2y ago
    Probably because the benchmark is not using all cores so the cores hit the cache more often.
- dagmx 2y ago
  Generally HT/SMT has never been favored for high utilization needs or low wattage needs. On the high utilization end, stuff like offline rendering or even some realtime games, would have significant performance degradation when HT/SMT are enabled. It was incredibly noticeable when I worked in film. And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core.
  - The_Colonel 2y ago
    > And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core. For most of the HT's existence there weren't any E cores which conflicts with your "never" in the first sentence.
    - dagmx 2y ago
      It doesn’t because a lot of low wattage silicon doesn’t support HT/SMT anyway. The difference is that now low wattage doesn’t have to mean low performance, and getting back that performance is better suited to E cores than introducing HT.
      - The_Colonel 2y ago
        > It doesn’t Saying "no" doesn't magically remove your contradiction. E cores didn't exist in laptop/PC/server CPUs before 2022 and using HT was a decent way to increase capacity to handle many (e.g. IO) threads without expensive context switches. I'm not saying E cores are a bad solution, but somehow you're trying to erase historical context of HT (or more likely just sloppy writing which you don't want to admit).
        dagmx 2y ago
        I’ve explained what I meant. You’ve interjected your own interpretation of my comment and then gotten huffy about it. We could politely discuss it or you can continue being rude by making accusations of sloppy writing and denials.
        The_Colonel 2y ago
        No, you haven't explained the contradiction, you just talk over it. Before E cores were a thing, HT was a decent approach to cheaply support more low utilization threads.
  - jeffbee 2y ago
    Backend-bound workloads that amount to hours of endless multiplication are not that common. For workloads that are just grab-bags of hundreds of unrelated tasks on a machine, which describes the entire "cloud" thing and most internal crud at every company, HT significantly increases the apparent capacity of the machine.
- mmaniac 2y ago
  The need for hyperthreading has diminished with increasing core counts and shrinking power headroom. You can just run those tasks on E cores now and save energy.
- pjmlp 2y ago
  Since side-channel attacks became a common thing, there is hardly a reason to keep hyperthreading around. It was a product of its time, a way to get cheap multi-cores when getting real cores was too expensive for regular consumer products. Besides the security issues, for high performance workloads they have always been an issue, stealing resources across shared CPU units.
  - sapiogram 2y ago
    > there is hardly a reason to keep hyperthreading around. Performance is still a reason. Anecdote: I have a pet project that involves searching for chess puzzles, and hyperthreading improves throughput 22%. Not massive, but definitely not nothing.
    - magnio 2y ago
      You mean 4 cores 8 threads give 22% more throughput than 8 cores 8 threads or 4 cores 4 threads?
      - rbanffy 2y ago
        Remember core to core coordination takes longer than between threads of the same core.
      - sapiogram 2y ago
        4c/8t gives more throughput than 4c/4t.
        hajile 2y ago
        There are definitely workloads where turning off SMT improves performance. SMT is a crutch. If your frontend is advanced enough to take advantage of the majority of your execution ports, SMT adds no value. SMT only adds value when your frontend can't use your execution ports, but at that point, maybe you're better off with two more simple cores anyway. With Intel having small e-cores, it starts to become cheaper to add a couple e-cores that guarantee improvement than to make the p-core larger.
klooney 2y ago
> The removal of Hyperthreading makes a lot of sense for Lunar Lake to both reduce the die size of the version of Lion Cove found in Lunar Lake along with simplifying the job of Thread Director. And, you know, stop the security vulnerability bleeding.
- andrewia 2y ago
  I don't think hyperthreading was the bulk of the attack surface. It definitely presented opportunities for processes to get out of bounds, but I think preemptive scheduling is the bulk of the issue. That genie not going back in the bottle another way to significantly improve processor performance for the same amount of instructions.
  - nextaccountic 2y ago
    I think the real problem is cache sharing and hyperthreading kind of depends on it, so it was only ever secure to run two threads from the same security domain in the same core
    - antoniojtorres 2y ago
      Newbie question, if the cores share an L3 cache, does that factor in the branch prediction vulnerabilities? Or is the data affected by the vulnerability stay in caches closer to the individual core? I assume so otherwise all cores would be impacted but I’m unclear where it does sit
andrewia 2y ago
It's interesting to see that modern processor optimization still revolves around balancing hardware for specific tasks. In this case, the vector scheduler has been separated from the integer scheduler, and the integer pipeline has been made much wider. I'm sure it made sense for this revision, but I wonder if things will change in a few generations in the pendulum will swing back to simplifying and integrating more parts of the arithmrtic scheduler(s) and ALUs. It's also interesting to see that FPGA integration hasn't gone far, and good vector performance is still important (if less important than integer). I wonder what percentage of consumer and professional workloads make significant use of vector operations, and how much GPU and FPGA offload would alleviate the need for good vector performance. I only know of vector operations in the context of multimedia processing, which is also suited for GPU acceleration.
- dogma1138 2y ago
  AMD tried that with HSA in the past it doesn’t really work. Unless your CPU can magically offload vector processing to the GPU or another sub-processor you are still reliant on new code to get this working which means you break backward compatibility with previously compiled code. The best case scenario here is if you can have the compiler do all the heavy lifting but more realistically you’ll end up having to make developers switch to a whole new programming paradigm.
  - andrewia 2y ago
    I understand that you can't convince developers to rewrite/recompile their applications for a processor that breaks compatibility. I'm wondering how many existing applications would be negatively impacted by cutting down vector throughput. With some searching, I see that some applications make mild use of it like Firefox. However there are applications that would negatively affected, such as noise suppression in Microsoft Teams, and crypto acceleration in libssl and the Linux kernel. Acceleration of crypto functions seems essential enough to warrant not touching vector throughput, so it seems vector operations are here to stay in CPUs.
    - alexhutcheson 2y ago
KingOfCoders 2y ago
Main thing for me, they take the Apple hint and again increase caches (and add another cache layer L0)
- trynumber9 2y ago
  I don't think the L0 is the "new" cache. It's still 48K like the old L1. The 9 cycle 192K cache about halfway between the old L1 and L2 is really the new cache level in size and latency. And that's now called L1.
  - hajile 2y ago
    L0 latency is 4 cycles while old L1 was 5 cycles, so it's definitely a new cache even though the size is the same. Apple does a lot better. I'm not sure about newer chips, but M1 has the same 192kb of L1, but with the 4 cycle latency of Intel's tiny 48kb cache.
    - KingOfCoders 2y ago
      Yes, Apple makes expensive CPUs and has much more cache, one of the reasons why they have been faster and why Intel adds much more caching each generation now.
formerly_proven 2y ago
End of the unified scheduler is big news, Intel had this since Core. Both AMD and Apple have split the scheduling up for a long time.
bee_rider 2y ago
Now that the floating point vector units have gotten large enough to engage in mitosis, I wonder if there will be room in the future for little SIMD units stuck on the integer side. Bring back SSE, haha.
Symmetry 2y ago
Removing a core's SMT aka "hyperthreading" has some modest hardware savings but but biggest cost is that it makes testing and validation much more complicated. Given the existence of Intel's p-cores I'm not surprised they're getting rid of it.
- dralley 2y ago
  From Intel's perspective, I doubt that's true, when taking into consideration the constant stream of side channel vulnerabilities they were needing to deal with.
  - Symmetry 2y ago
    It's exactly the potential for side channel vulnerabilities that makes SMT so hard to get right.
    - rbanffy 2y ago
      You can always do like Sun and IBM and dilute the side channel in too many other threads to make it reliable. IIRC, both POWER10 and SPARC do 8 threads per core.
      - Symmetry 2y ago
        It's also a matter of workload. For a database where threads are often waiting on trips to RAM then SMT can provide a very large boost to performance.
- dan-robertson 2y ago
  I think you’re saying that testing smt makes it expensive, which sounds mostly right to me, though I can imagine some arguments that it isn’t much worse. When I first read your comment, I thought it said the opposite – that removing smt requires expensive testing and validation work.
- trynumber9 2y ago
  Lion Cove doesn't remove hyper-threading in general. Some variants will have it so Intel still has to validate it (eventually). But the first part shipping, Lunar Lake, removes hyper-threading. It may have saved them validation time for this particular part but they'll still have to do it.
therealmarv 2y ago
And the main question: Is it overall better (faster and less power hungry) than a reduced instruction set, powerful laptop ARM based CPU which is around the corner (Qualcomm)? Guessing not...
- Rinzler89 2y ago
  There's still an insurmountable amount of apps that are still X86 exclusive both new and legacy. So the chip not beating the best of ARM in benchmarks is largely irelevant. A Ferrari will beat a tractor on every test bench numbers and every track, but I can't plow the field with a Ferrari, so any improvements in tractor technology is still welcome despite they'll never beat Ferraris.
  - hajile 2y ago
    I hear this argument, but I don't really believe it. If you're talking apps before say 2015 (10 years ago), they can be emulated on ARM faster than they ran natively. That rules out 95% of the backward compatibility argument. Most more recent apps are very portable. They were written in a managed language running on a cross-platform runtime. The source code is likely stored in git so it can be tracked down and recompiled. Over 15 years of modern smartphones has ensured that most low-level libraries have support for ARM and other ISAs too as being ISA-agnostic has once again become important. Apple's 4 years of transition aren't to be underestimated either. Lots of devs/creatives use ARM machines and have ensured that pretty much all of the biggest pro software runs very well on non-x86 platforms. Yes, some stuff remains, but I don't think the remaining stuff is as big a deal as some people claim.
- jeffbee 2y ago
  Amazing that you can look at an ISA like ARM and say "reduced instruction set". It has 1300+ opcodes.
  - mhh__ 2y ago
    At best ARM is regular rather than reduced
SilverBirch 2y ago
I'm just wondering, how much of this analysis is real? I mean, how much of this analysis is a true weighing up of design decisions and performance, and how much is copy/pasted Intel marketing bumf?
- antoniojtorres 2y ago
  That’s typically the question with all marketing (probably cherry-picked) benchmarks. Have to wait until independent reviewers get their hands on them.
- dur-randir 2y ago
  Nothing real. They cherry-pick for what they're trying to sell you this time - advent of 2nd core, +HT, E-cores, -HT, you-name-it-next-time. Without independent benchmark + additional interpretation for your particular workload you can safely ignore all their claims.
JonChesterfield 2y ago
The dropping hyperthreading is interesting. I'm hoping x64 will trend in the other direction - I'd like four or eight threads scheduled across a pool of execution units as a way of hiding memory latency. Sort of a step towards the GPU model.
- jandrewrogers 2y ago
  This has not been successful historically because software developers struggle to design code that has mechanical sympathy with these architectural models. These types of processors will run idiomatic CPU code with mediocre efficiency, which provides an element of backward compatibility, but achieving their theoretical efficiency requires barrel-processing style data structures and algorithms, which isn't something widely taught or known to software developers. I like these architectures but don't expect it to happen. Every attempt to produce a CPU that works this way has done poorly because software developers don't know how to use them properly. The hardware companies have done the "build it and they will come" thing multiple times and it has never panned out for them. You would need a killer app that would strongly incentivize software developers to learn how design efficient code for these architectures.
  - bri3d 2y ago
    I think another huge issue is the combination of general-purpose/multi-tenant computing, especially with virtualization in the mix, and cache. Improvements gained from masking memory latency by issuing instructions from more thread execution contexts are suddenly lost when each of those thread contexts is accessing a totally different part of memory and evicting the cache line that the next thread wanted anyway. In many ways barrel processing and hyperthreading are remarkably similar to VLIW - they're two very different sides of the same coin. At the end of the day, both work well for situations where multiple simultaneous instruction streams need to access relatively small amounts of adjacent data. Realtime signal processing, dedicated databases, and gaming are obvious applications here, which I think is why VLIW has done so well in DSP and hyperthreading did well in gaming and databases. Once the simultaneous instruction streams are accessing completely disparate parts of main memory, it all blows up. Plus, in a multi-tenant environment, the security issues inherent to sharing even more execution state context (and therefore side channels) between domains also become untenable fairly quickly.
osigurdson 2y ago
From an investor perspective, I'd rather hear: "we pay more for talent than our competition". That is the first step toward greatness.
tambourine_man 2y ago
> Moving to a more customizable design will allow Intel to better optimize their P-cores for specific designs moving forward Amateur question: is that due to the recent advances in interconnect or are they designing multiple versions of this chip?
- wmf 2y ago
  Cheese is talking about different chips (e.g. laptop, desktop, and server) that contain Lion Cove cores. Intel doesn't really reuse chips between different segments.
ein0p 2y ago
Once (and if) Intel manages to get out of the woods with lithography, they will have an incredibly strong product lineup.

175 points by zdw 2y ago

I'm very interested to see independent testing of cores without SMT/hyperthreading. Of course it's one less function for the hardware and thread scheduler to worry about. But hyperthreading was a useful way to share resources between multiple threads that had light-to-intermediate workloads. Synthetic benchmarks might show an improvement but I'm interested to see what everyday workloads, like web browsing while streaming a video, will react.

adrian_b 2y ago
I was surprised that disabling SMT has improved by a few percents the Geekbench 6 multi-threaded results on a Zen 3 (5900X) CPU. While there are also other tasks where SMT does not bring advantages, for the compilation of a big software project SMT does bring an obvious performance improvement, of about 20% for the same Zen 3 CPU. In any case, Intel has said that they have designed 2 versions of the Lion Cove core, one without SMT for laptop/desktop hybrid CPUs and one with SMT for server CPUs with P cores (i.e. for the successor of Granite Rapids, which will be launched later this year, using P-cores similar to those of Meteor Lake).
- papichulo2023 2y ago
  Probably because the benchmark is not using all cores so the cores hit the cache more often.
dagmx 2y ago
Generally HT/SMT has never been favored for high utilization needs or low wattage needs. On the high utilization end, stuff like offline rendering or even some realtime games, would have significant performance degradation when HT/SMT are enabled. It was incredibly noticeable when I worked in film. And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core.
- The_Colonel 2y ago
  > And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core. For most of the HT's existence there weren't any E cores which conflicts with your "never" in the first sentence.
  - dagmx 2y ago
    It doesn’t because a lot of low wattage silicon doesn’t support HT/SMT anyway. The difference is that now low wattage doesn’t have to mean low performance, and getting back that performance is better suited to E cores than introducing HT.
    - The_Colonel 2y ago
      > It doesn’t Saying "no" doesn't magically remove your contradiction. E cores didn't exist in laptop/PC/server CPUs before 2022 and using HT was a decent way to increase capacity to handle many (e.g. IO) threads without expensive context switches. I'm not saying E cores are a bad solution, but somehow you're trying to erase historical context of HT (or more likely just sloppy writing which you don't want to admit).
      - dagmx 2y ago
        I’ve explained what I meant. You’ve interjected your own interpretation of my comment and then gotten huffy about it. We could politely discuss it or you can continue being rude by making accusations of sloppy writing and denials.
        The_Colonel 2y ago
        No, you haven't explained the contradiction, you just talk over it. Before E cores were a thing, HT was a decent approach to cheaply support more low utilization threads.
- jeffbee 2y ago
  Backend-bound workloads that amount to hours of endless multiplication are not that common. For workloads that are just grab-bags of hundreds of unrelated tasks on a machine, which describes the entire "cloud" thing and most internal crud at every company, HT significantly increases the apparent capacity of the machine.
mmaniac 2y ago
The need for hyperthreading has diminished with increasing core counts and shrinking power headroom. You can just run those tasks on E cores now and save energy.
pjmlp 2y ago
Since side-channel attacks became a common thing, there is hardly a reason to keep hyperthreading around. It was a product of its time, a way to get cheap multi-cores when getting real cores was too expensive for regular consumer products. Besides the security issues, for high performance workloads they have always been an issue, stealing resources across shared CPU units.
- sapiogram 2y ago
  > there is hardly a reason to keep hyperthreading around. Performance is still a reason. Anecdote: I have a pet project that involves searching for chess puzzles, and hyperthreading improves throughput 22%. Not massive, but definitely not nothing.
  - magnio 2y ago
    You mean 4 cores 8 threads give 22% more throughput than 8 cores 8 threads or 4 cores 4 threads?
    - rbanffy 2y ago
      Remember core to core coordination takes longer than between threads of the same core.
    - sapiogram 2y ago
      4c/8t gives more throughput than 4c/4t.
      - hajile 2y ago
        There are definitely workloads where turning off SMT improves performance. SMT is a crutch. If your frontend is advanced enough to take advantage of the majority of your execution ports, SMT adds no value. SMT only adds value when your frontend can't use your execution ports, but at that point, maybe you're better off with two more simple cores anyway. With Intel having small e-cores, it starts to become cheaper to add a couple e-cores that guarantee improvement than to make the p-core larger.

klooney 2y ago

> The removal of Hyperthreading makes a lot of sense for Lunar Lake to both reduce the die size of the version of Lion Cove found in Lunar Lake along with simplifying the job of Thread Director. And, you know, stop the security vulnerability bleeding.

andrewia 2y ago
I don't think hyperthreading was the bulk of the attack surface. It definitely presented opportunities for processes to get out of bounds, but I think preemptive scheduling is the bulk of the issue. That genie not going back in the bottle another way to significantly improve processor performance for the same amount of instructions.
- nextaccountic 2y ago
  I think the real problem is cache sharing and hyperthreading kind of depends on it, so it was only ever secure to run two threads from the same security domain in the same core
  - antoniojtorres 2y ago
    Newbie question, if the cores share an L3 cache, does that factor in the branch prediction vulnerabilities? Or is the data affected by the vulnerability stay in caches closer to the individual core? I assume so otherwise all cores would be impacted but I’m unclear where it does sit

andrewia 2y ago

It's interesting to see that modern processor optimization still revolves around balancing hardware for specific tasks. In this case, the vector scheduler has been separated from the integer scheduler, and the integer pipeline has been made much wider. I'm sure it made sense for this revision, but I wonder if things will change in a few generations in the pendulum will swing back to simplifying and integrating more parts of the arithmrtic scheduler(s) and ALUs. It's also interesting to see that FPGA integration hasn't gone far, and good vector performance is still important (if less important than integer). I wonder what percentage of consumer and professional workloads make significant use of vector operations, and how much GPU and FPGA offload would alleviate the need for good vector performance. I only know of vector operations in the context of multimedia processing, which is also suited for GPU acceleration.

dogma1138 2y ago
AMD tried that with HSA in the past it doesn’t really work. Unless your CPU can magically offload vector processing to the GPU or another sub-processor you are still reliant on new code to get this working which means you break backward compatibility with previously compiled code. The best case scenario here is if you can have the compiler do all the heavy lifting but more realistically you’ll end up having to make developers switch to a whole new programming paradigm.
- andrewia 2y ago
  I understand that you can't convince developers to rewrite/recompile their applications for a processor that breaks compatibility. I'm wondering how many existing applications would be negatively impacted by cutting down vector throughput. With some searching, I see that some applications make mild use of it like Firefox. However there are applications that would negatively affected, such as noise suppression in Microsoft Teams, and crypto acceleration in libssl and the Linux kernel. Acceleration of crypto functions seems essential enough to warrant not touching vector throughput, so it seems vector operations are here to stay in CPUs.
  - alexhutcheson 2y ago

KingOfCoders 2y ago

Main thing for me, they take the Apple hint and again increase caches (and add another cache layer L0)

trynumber9 2y ago
I don't think the L0 is the "new" cache. It's still 48K like the old L1. The 9 cycle 192K cache about halfway between the old L1 and L2 is really the new cache level in size and latency. And that's now called L1.
- hajile 2y ago
  L0 latency is 4 cycles while old L1 was 5 cycles, so it's definitely a new cache even though the size is the same. Apple does a lot better. I'm not sure about newer chips, but M1 has the same 192kb of L1, but with the 4 cycle latency of Intel's tiny 48kb cache.
  - KingOfCoders 2y ago
    Yes, Apple makes expensive CPUs and has much more cache, one of the reasons why they have been faster and why Intel adds much more caching each generation now.

formerly_proven 2y ago

End of the unified scheduler is big news, Intel had this since Core. Both AMD and Apple have split the scheduling up for a long time.

bee_rider 2y ago

Now that the floating point vector units have gotten large enough to engage in mitosis, I wonder if there will be room in the future for little SIMD units stuck on the integer side. Bring back SSE, haha.

Symmetry 2y ago

Removing a core's SMT aka "hyperthreading" has some modest hardware savings but but biggest cost is that it makes testing and validation much more complicated. Given the existence of Intel's p-cores I'm not surprised they're getting rid of it.

dralley 2y ago
From Intel's perspective, I doubt that's true, when taking into consideration the constant stream of side channel vulnerabilities they were needing to deal with.
- Symmetry 2y ago
  It's exactly the potential for side channel vulnerabilities that makes SMT so hard to get right.
  - rbanffy 2y ago
    You can always do like Sun and IBM and dilute the side channel in too many other threads to make it reliable. IIRC, both POWER10 and SPARC do 8 threads per core.
    - Symmetry 2y ago
      It's also a matter of workload. For a database where threads are often waiting on trips to RAM then SMT can provide a very large boost to performance.
dan-robertson 2y ago
I think you’re saying that testing smt makes it expensive, which sounds mostly right to me, though I can imagine some arguments that it isn’t much worse. When I first read your comment, I thought it said the opposite – that removing smt requires expensive testing and validation work.
trynumber9 2y ago
Lion Cove doesn't remove hyper-threading in general. Some variants will have it so Intel still has to validate it (eventually). But the first part shipping, Lunar Lake, removes hyper-threading. It may have saved them validation time for this particular part but they'll still have to do it.

therealmarv 2y ago

And the main question: Is it overall better (faster and less power hungry) than a reduced instruction set, powerful laptop ARM based CPU which is around the corner (Qualcomm)? Guessing not...

Rinzler89 2y ago
There's still an insurmountable amount of apps that are still X86 exclusive both new and legacy. So the chip not beating the best of ARM in benchmarks is largely irelevant. A Ferrari will beat a tractor on every test bench numbers and every track, but I can't plow the field with a Ferrari, so any improvements in tractor technology is still welcome despite they'll never beat Ferraris.
- hajile 2y ago
  I hear this argument, but I don't really believe it. If you're talking apps before say 2015 (10 years ago), they can be emulated on ARM faster than they ran natively. That rules out 95% of the backward compatibility argument. Most more recent apps are very portable. They were written in a managed language running on a cross-platform runtime. The source code is likely stored in git so it can be tracked down and recompiled. Over 15 years of modern smartphones has ensured that most low-level libraries have support for ARM and other ISAs too as being ISA-agnostic has once again become important. Apple's 4 years of transition aren't to be underestimated either. Lots of devs/creatives use ARM machines and have ensured that pretty much all of the biggest pro software runs very well on non-x86 platforms. Yes, some stuff remains, but I don't think the remaining stuff is as big a deal as some people claim.
jeffbee 2y ago
Amazing that you can look at an ISA like ARM and say "reduced instruction set". It has 1300+ opcodes.
- mhh__ 2y ago
  At best ARM is regular rather than reduced

SilverBirch 2y ago

I'm just wondering, how much of this analysis is real? I mean, how much of this analysis is a true weighing up of design decisions and performance, and how much is copy/pasted Intel marketing bumf?

antoniojtorres 2y ago
That’s typically the question with all marketing (probably cherry-picked) benchmarks. Have to wait until independent reviewers get their hands on them.
dur-randir 2y ago
Nothing real. They cherry-pick for what they're trying to sell you this time - advent of 2nd core, +HT, E-cores, -HT, you-name-it-next-time. Without independent benchmark + additional interpretation for your particular workload you can safely ignore all their claims.

JonChesterfield 2y ago

The dropping hyperthreading is interesting. I'm hoping x64 will trend in the other direction - I'd like four or eight threads scheduled across a pool of execution units as a way of hiding memory latency. Sort of a step towards the GPU model.

jandrewrogers 2y ago
This has not been successful historically because software developers struggle to design code that has mechanical sympathy with these architectural models. These types of processors will run idiomatic CPU code with mediocre efficiency, which provides an element of backward compatibility, but achieving their theoretical efficiency requires barrel-processing style data structures and algorithms, which isn't something widely taught or known to software developers. I like these architectures but don't expect it to happen. Every attempt to produce a CPU that works this way has done poorly because software developers don't know how to use them properly. The hardware companies have done the "build it and they will come" thing multiple times and it has never panned out for them. You would need a killer app that would strongly incentivize software developers to learn how design efficient code for these architectures.
- bri3d 2y ago
  I think another huge issue is the combination of general-purpose/multi-tenant computing, especially with virtualization in the mix, and cache. Improvements gained from masking memory latency by issuing instructions from more thread execution contexts are suddenly lost when each of those thread contexts is accessing a totally different part of memory and evicting the cache line that the next thread wanted anyway. In many ways barrel processing and hyperthreading are remarkably similar to VLIW - they're two very different sides of the same coin. At the end of the day, both work well for situations where multiple simultaneous instruction streams need to access relatively small amounts of adjacent data. Realtime signal processing, dedicated databases, and gaming are obvious applications here, which I think is why VLIW has done so well in DSP and hyperthreading did well in gaming and databases. Once the simultaneous instruction streams are accessing completely disparate parts of main memory, it all blows up. Plus, in a multi-tenant environment, the security issues inherent to sharing even more execution state context (and therefore side channels) between domains also become untenable fairly quickly.

osigurdson 2y ago

From an investor perspective, I'd rather hear: "we pay more for talent than our competition". That is the first step toward greatness.

tambourine_man 2y ago

> Moving to a more customizable design will allow Intel to better optimize their P-cores for specific designs moving forward Amateur question: is that due to the recent advances in interconnect or are they designing multiple versions of this chip?

wmf 2y ago
Cheese is talking about different chips (e.g. laptop, desktop, and server) that contain Lion Cove cores. Intel doesn't really reuse chips between different segments.

ein0p 2y ago

Once (and if) Intel manages to get out of the woods with lithography, they will have an incredibly strong product lineup.