4 ms·

One theory is that the new xeon comes with no HT to keep the power draw under 300W, which is why the footnotes mention no HT/SMT in test configuration... This

by c2h5oh 8y ago

One theory is that the new xeon comes with no HT to keep the power draw under 300W, which is why the footnotes mention no HT/SMT in test configuration... This would also "fix" a lot of side channel attacks without new silicon being ready and Intel claims this CPU includes some hardware mitigations.

nolok 8y ago
It's still rather telling that they compare only with the equivalent also off on the AMD chip.
- tutanchamun 8y ago
  Especially since AMDs SMT is better.
rbanffy 8y ago
It also doubles the effective amount of cache per core. I kind of like that.
- xxs 8y ago
  do you mean the L2 or L3 cache? Hyperthreading is there to help reduce the times the CPU is stalled. If you run less active threads, the cache efficiency would the same in that case, hypethreading or not.
  - rbanffy 8y ago
    L1 and L2 (IIRC) are usually tied to a single physical core and, also IIRC, are partitioned between logical cores when HT is enabled. With HT disabled, cache per logical core doubles (because there is only one) and cache misses go down. Many HPC installs run with HT disabled because of that (YMMV depending on specifics of your workload - if your hot data fits in the cache, you'll be happy). Now that we mention it, I wonder if HT can be enabled or disabled per core. If that's possible, the machine would look like it has some logical cores with more cache than others and we could use cache miss counters as input to decide where a process should run.
    - xxs 8y ago
      >With HT disabled, cache per logical core doubles (because there is only one) and cache misses go down. This is too naive to look at in such a way. Yes if there is less scheduling on the core (less concurrency) the likehood of misses is lower, but the idea is to pay less for each miss doing effectively something else meanwhile instead of being stalled for memory. >Now that we mention it, I wonder if HT can be enabled or disabled per core. OS scheduler can do that. Normally the guidance for hyperthreading is: consider each "thread" as a separate core. If an OS chooses to use one core at a time and not schedule anything, the hypertrheadind won't be used. That is imagine logical core0&core 1 represent the same physical one, if the OS schedules only to core0, hyperthreading is not in play. Notes: controlling scheduling on linux is done via taskset. And cores info is available via "cat /proc/cpuinfo"
      - rbanffy 8y ago
        > OS scheduler can do that True, but the scheduler can't tell the CPU to allocate all of the partitioned cache to a thread if it the silicon thinks it belongs to another logical core, so you end with effectively half of your cache dark. If L1 and L2 are pooled between the logical cores, it makes no difference, but I'm not sure how HT behaves WRT to partitioning caches on current generations of Intel parts and I remember it used to be like that (because I turned off HT on a couple dozen boxes to improve single thread performance, which was what was bothering me).
        xxs 8y ago
        L1&L2 are exclusive to each designated core. L3 is shared (hence my very 1st question); also updated the info how to force scheduling on your own.
        rbanffy 8y ago
        Got back from Intel's website. It seems the cache was partitioned on early HT implementations, but now L1 and L2 are shared between the logical cores and, therefore, it should make no difference to disable HT.
mtgx 8y ago
I'll be one of those to say that HT/SMT should probably die off unless the chipmakers learn how to make it secure. I'd rather have twice the physical cores for a little higher price anyway. However, Intel starting to sell chips without HT has nothing to do with the insecurity of HT and everything to do with the fact that they are trying to sell chips that are cheaper to make (or more profitable), while also being a little more competitive (price-wise) with AMD's offerings. But while they do this, they know they'll have a severe handicap in performance as long as AMD continues to sell competing products with SMT enabled. So their "solution" is to start making it "fair" in their benchmarks by using only half the cores or the SMT disabled for competing AMD products. One of the first clues that tells us this move is not a response to the recent security vulnerabilities of HT is that they started offering chips without HT only a few months after those discoveries were made. Do you really think something like planning to design and ship a product without HT happened only a few months earlier? No, this was decided at least a year and a half ago.
- snovv_crash 8y ago
  Not everyone runs programs they don't trust on hardware they don't own. These sidechannel attacks are really only an issue for consumers with JIT JavaScript, and for enterprise with shared hosting. For HPC, or consumer/professional applications eg. gaming, rendering, encoding, ie. all those places where performance actually really matters, SMT is a great way to get a decent boost in a lot of workloads.
  - marmaduke 8y ago
    It seems like something that should be improved at the OS-level, where some workloads are untrusted and can'tb e HT'd next to others, whereas trusted software can be.
- toast0 8y ago
  I don't think we can know for sure why they disabled HT. There's arguments for both. It's certainly possible that during the long Spectre embargo, someone was looking around and realized HT was going to be a problem. It's also not that hard to disable HT -- it's a flag somewhere in the on chip settings, in some parts of their product line, it's already done as part of binning and market segmentation. It's just a matter of deciding to have more SKUs with that set. Actually removing the die space used for HT would be different, but then we'd see chip families released without HT in any SKU.

by c2h5oh 8y ago

nolok 8y ago

It's still rather telling that they compare only with the equivalent also off on the AMD chip.

tutanchamun 8y ago
Especially since AMDs SMT is better.

rbanffy 8y ago

It also doubles the effective amount of cache per core. I kind of like that.

xxs 8y ago
do you mean the L2 or L3 cache? Hyperthreading is there to help reduce the times the CPU is stalled. If you run less active threads, the cache efficiency would the same in that case, hypethreading or not.
- rbanffy 8y ago
  L1 and L2 (IIRC) are usually tied to a single physical core and, also IIRC, are partitioned between logical cores when HT is enabled. With HT disabled, cache per logical core doubles (because there is only one) and cache misses go down. Many HPC installs run with HT disabled because of that (YMMV depending on specifics of your workload - if your hot data fits in the cache, you'll be happy). Now that we mention it, I wonder if HT can be enabled or disabled per core. If that's possible, the machine would look like it has some logical cores with more cache than others and we could use cache miss counters as input to decide where a process should run.
  - xxs 8y ago
    >With HT disabled, cache per logical core doubles (because there is only one) and cache misses go down. This is too naive to look at in such a way. Yes if there is less scheduling on the core (less concurrency) the likehood of misses is lower, but the idea is to pay less for each miss doing effectively something else meanwhile instead of being stalled for memory. >Now that we mention it, I wonder if HT can be enabled or disabled per core. OS scheduler can do that. Normally the guidance for hyperthreading is: consider each "thread" as a separate core. If an OS chooses to use one core at a time and not schedule anything, the hypertrheadind won't be used. That is imagine logical core0&core 1 represent the same physical one, if the OS schedules only to core0, hyperthreading is not in play. Notes: controlling scheduling on linux is done via taskset. And cores info is available via "cat /proc/cpuinfo"
    - rbanffy 8y ago
      > OS scheduler can do that True, but the scheduler can't tell the CPU to allocate all of the partitioned cache to a thread if it the silicon thinks it belongs to another logical core, so you end with effectively half of your cache dark. If L1 and L2 are pooled between the logical cores, it makes no difference, but I'm not sure how HT behaves WRT to partitioning caches on current generations of Intel parts and I remember it used to be like that (because I turned off HT on a couple dozen boxes to improve single thread performance, which was what was bothering me).
      - xxs 8y ago
        L1&L2 are exclusive to each designated core. L3 is shared (hence my very 1st question); also updated the info how to force scheduling on your own.
        rbanffy 8y ago
        Got back from Intel's website. It seems the cache was partitioned on early HT implementations, but now L1 and L2 are shared between the logical cores and, therefore, it should make no difference to disable HT.

mtgx 8y ago

I'll be one of those to say that HT/SMT should probably die off unless the chipmakers learn how to make it secure. I'd rather have twice the physical cores for a little higher price anyway. However, Intel starting to sell chips without HT has nothing to do with the insecurity of HT and everything to do with the fact that they are trying to sell chips that are cheaper to make (or more profitable), while also being a little more competitive (price-wise) with AMD's offerings. But while they do this, they know they'll have a severe handicap in performance as long as AMD continues to sell competing products with SMT enabled. So their "solution" is to start making it "fair" in their benchmarks by using only half the cores or the SMT disabled for competing AMD products. One of the first clues that tells us this move is not a response to the recent security vulnerabilities of HT is that they started offering chips without HT only a few months after those discoveries were made. Do you really think something like planning to design and ship a product without HT happened only a few months earlier? No, this was decided at least a year and a half ago.

snovv_crash 8y ago
Not everyone runs programs they don't trust on hardware they don't own. These sidechannel attacks are really only an issue for consumers with JIT JavaScript, and for enterprise with shared hosting. For HPC, or consumer/professional applications eg. gaming, rendering, encoding, ie. all those places where performance actually really matters, SMT is a great way to get a decent boost in a lot of workloads.
- marmaduke 8y ago
  It seems like something that should be improved at the OS-level, where some workloads are untrusted and can'tb e HT'd next to others, whereas trusted software can be.
toast0 8y ago
I don't think we can know for sure why they disabled HT. There's arguments for both. It's certainly possible that during the long Spectre embargo, someone was looking around and realized HT was going to be a problem. It's also not that hard to disable HT -- it's a flag somewhere in the on chip settings, in some parts of their product line, it's already done as part of binning and market segmentation. It's just a matter of deciding to have more SKUs with that set. Actually removing the die space used for HT would be different, but then we'd see chip families released without HT in any SKU.