4 ms·

Good point. Intel's 40 cores are basically 80 cores due to hyper threading. Some people don't like hyperthreading for various reasons but it would be better to

Good point. Intel's 40 cores are basically 80 cores due to hyper threading. Some people don't like hyperthreading for various reasons but it would be better to say the comparison is between 128 cores of Ampere and 80 cores of Intel. But then again, number of cores is really a crude measure. We need to measure what those machines can really do... P.S. Surprised I am being downvoted. If you only want to compare number of cores then I was implying that 80 is a better number than 40 to compare with 128. It gives you a rough idea of parallelism even though obviously HT does not give you 2x available cores all the time. I also added a caveat that that number of cores is a crude measure anyways.

holbrad 5y ago
That isn't how hyperthreading works... It's completely dependent on the workload. If your using the CPU core as efficiently as possible, you'd see no benefit from hyperthreading. If your using it very poorly, you'd see a massive 2~x benefit.
- esens 5y ago
  When doing C++ compiles and also renders I see a 2x benefit generally. It is rare that I do not see something close to 1.5 to 2x speed ups. That said I did switch from Intel over to an Apple M1 anyway.
  - mschuster91 5y ago
    Most compilers are one of the prime cases of inefficient architecture, the worse the larger the project gets. There is an awful lot of time lost waiting on I/O for hundreds to thousands of files (even assuming that there is enough RAM for the OS to cache all the files and metadata, every file that is read has at least three syscall context switches for open/read/close, dito for intermediate writes) and for process creation and destruction. What I would find really, really interesting: a "single-process" compiler that has a global in-RAM cache for all source contents and intermediate outputs and can avoid the overhead of child processes... basically a model like Webpack or Parcel that has an inotify watcher and is constantly running. The JS world had no other choice with NodeJS/npm all but forcing the tooling to adapt to a lot of incredibly small source files, it's time for the "classic" world to adapt.
- sidkshatriya 5y ago
  > If your using it very poorly, you'd see a massive 2~x benefit. I find this statement tough to agree with. It depends on the kind of work your processors are doing: it is IO heavy work or are you running Math computations? There are other axes basically related to how much work can be done by the current thread while the other thread stalls waiting for data to be fetched (or other non-parallelizable dependencies to be available). So if you're getting a high benefit you shouldn't necessarily feel embarrassed!
Asmod4n 5y ago
Last time I checked a hyper thread is ~75% slower than a normal one, so it’s roughly a 50 core cpu.
- reitzensteinm 5y ago
  This depends heavily on your memory access patterns. If you're chasing dependent loads around memory, like traversing a long fragmented linked list due to garbage code, you will get an absolutely perfect 100% speed up. If you're already saturating the ALU on one thread, adding another to the core will probably slow you down with context switching and cache contention, and indeed well written numeric simulations on supercomputers often turn it off entirely. However, most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety.
  - Const-me 5y ago
    > most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety. To be fair, crappy pointer-heavy data structures is not the only possible reason. Some useful algorithms are inherently serial. For instance, all streaming parsers, compressors, or cryptography are inherently serial algorithms. An implementation gonna be relatively slow not because of RAM latency, but due to continuous chain of data dependencies between sequential instructions. It’s technically possible to implement single-threaded code to handle multiple streams concurrently. Practically, more often that not it’s prohibitively complicated to achieve. However, doing that in hardware with two hardware threads running on the same core is way more manageable in terms of software complexity.
    - reitzensteinm 5y ago
      Yeah, garbage code was a little unfair. I actually experimented with parallel fetching of multiple values out of a large persistent vector years ago, and saw nearly linear speed up for up to four fetches in parallel. The code was awful and it would need to be a compiler generated thing for sure.
goldenkey 5y ago
Once mitigations for Spectre, Meltdown, and whatnot are enabled, is hyper threading still a real gain?
- sidkshatriya 5y ago
  Newer generation Intel CPUs deal with some of these issues on a hardware level. See https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html https://www.intel.com/content/www/us/en/developer/topic-tech... So the level at which your Intel CPU is "crippled" would depend on how old it is, I guess.
  - goldenkey 5y ago
    Are these hardware fixes just bandaids or are the actual architectural flaws really fixed? Because didn't other processors that did speculative execution besides Intel's also have similar vulnerabilities? A lot of expert level folks on here were saying that the architecture surrounding speculative execution would need a total removal or reengineering to fix it.

holbrad 5y ago

That isn't how hyperthreading works... It's completely dependent on the workload. If your using the CPU core as efficiently as possible, you'd see no benefit from hyperthreading. If your using it very poorly, you'd see a massive 2~x benefit.

esens 5y ago
When doing C++ compiles and also renders I see a 2x benefit generally. It is rare that I do not see something close to 1.5 to 2x speed ups. That said I did switch from Intel over to an Apple M1 anyway.
- mschuster91 5y ago
  Most compilers are one of the prime cases of inefficient architecture, the worse the larger the project gets. There is an awful lot of time lost waiting on I/O for hundreds to thousands of files (even assuming that there is enough RAM for the OS to cache all the files and metadata, every file that is read has at least three syscall context switches for open/read/close, dito for intermediate writes) and for process creation and destruction. What I would find really, really interesting: a "single-process" compiler that has a global in-RAM cache for all source contents and intermediate outputs and can avoid the overhead of child processes... basically a model like Webpack or Parcel that has an inotify watcher and is constantly running. The JS world had no other choice with NodeJS/npm all but forcing the tooling to adapt to a lot of incredibly small source files, it's time for the "classic" world to adapt.
sidkshatriya 5y ago
> If your using it very poorly, you'd see a massive 2~x benefit. I find this statement tough to agree with. It depends on the kind of work your processors are doing: it is IO heavy work or are you running Math computations? There are other axes basically related to how much work can be done by the current thread while the other thread stalls waiting for data to be fetched (or other non-parallelizable dependencies to be available). So if you're getting a high benefit you shouldn't necessarily feel embarrassed!

Asmod4n 5y ago

Last time I checked a hyper thread is ~75% slower than a normal one, so it’s roughly a 50 core cpu.

reitzensteinm 5y ago
This depends heavily on your memory access patterns. If you're chasing dependent loads around memory, like traversing a long fragmented linked list due to garbage code, you will get an absolutely perfect 100% speed up. If you're already saturating the ALU on one thread, adding another to the core will probably slow you down with context switching and cache contention, and indeed well written numeric simulations on supercomputers often turn it off entirely. However, most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety.
- Const-me 5y ago
  > most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety. To be fair, crappy pointer-heavy data structures is not the only possible reason. Some useful algorithms are inherently serial. For instance, all streaming parsers, compressors, or cryptography are inherently serial algorithms. An implementation gonna be relatively slow not because of RAM latency, but due to continuous chain of data dependencies between sequential instructions. It’s technically possible to implement single-threaded code to handle multiple streams concurrently. Practically, more often that not it’s prohibitively complicated to achieve. However, doing that in hardware with two hardware threads running on the same core is way more manageable in terms of software complexity.
  - reitzensteinm 5y ago
    Yeah, garbage code was a little unfair. I actually experimented with parallel fetching of multiple values out of a large persistent vector years ago, and saw nearly linear speed up for up to four fetches in parallel. The code was awful and it would need to be a compiler generated thing for sure.

goldenkey 5y ago

Once mitigations for Spectre, Meltdown, and whatnot are enabled, is hyper threading still a real gain?

sidkshatriya 5y ago
Newer generation Intel CPUs deal with some of these issues on a hardware level. See https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html https://www.intel.com/content/www/us/en/developer/topic-tech... So the level at which your Intel CPU is "crippled" would depend on how old it is, I guess.
- goldenkey 5y ago
  Are these hardware fixes just bandaids or are the actual architectural flaws really fixed? Because didn't other processors that did speculative execution besides Intel's also have similar vulnerabilities? A lot of expert level folks on here were saying that the architecture surrounding speculative execution would need a total removal or reengineering to fix it.