Slashdot Mirror


Leaked Benchmarks Suggest Intel Will Drop Hyperthreading From Core i7 Chips (arstechnica.com)

According to leaked benchmarks found in the SiSoft Sandra database, there is an Intel Core i7-9700K processor that doesn't appear to have hyperthreading available. "This increases the core count from the current six cores in the 8th generation Coffee Lake parts to eight cores, but, even though it's an i7 chip, it doesn't appear to have hyperthreading available," reports Ars Technica. "It's base clock speed is 3.6GHz, peak turbo is 4.9GHz, and it has 12MB cache. The price is expected to be around the same $350 level as the current top-end i7s." From the report: For the chip that will sit above the i7-9700K in the product lineup, Intel is extending the use of its i9 branding, initially reserved for the X-series High-End Desktop Platform. The i9-9900K will be an eight-core, 16-thread processor. This bumps the cache up to 16MB and the peak turbo up to 5GHz -- and the price up to an expected $450. Below the i7s will be i5s with six cores and six threads and below them, i3s with four cores and four threads. Even without hyperthreading, the new i7s should be faster than old i7s. A part with eight cores is going to be faster than the four-core/eight-thread chips of a couple of generations ago and should in general also be faster than the six-core/12-thread 8th generation chips. Peak clock speeds are pushed slightly higher than they were for the 8th generation chips, too.

24 of 199 comments (clear)

  1. Never been a fan of hyperthreading by InvalidsYnc · · Score: 5, Interesting

    I've always seen them as "pseudo" cpu's, and not been all that happy with them overall. Yeah, some workloads benefit from it just fine, but others get tanked, but you'll never know because it just looks like those CPU's are flying along (according to task mangler or whatever).

    Anyway, glad to see that there will be some parts out there that people can choose to buy that don't have it.

    1. Re:Never been a fan of hyperthreading by jader3rd · · Score: 2

      What are those workloads that actually benefit from thinking the CPU has more cores than what it actually has?

    2. Re:Never been a fan of hyperthreading by Anonymous Coward · · Score: 5, Informative

      workloads that cause a lot of switching between processes/Jobs. We have many systems that benefit hugely from hyper threading, others that get bugger all and still more where we explicitly disable it as it slows down the system.

    3. Re: Never been a fan of hyperthreading by Anonymous Coward · · Score: 5, Informative

      Integer heavy workloads, sometimes branch heavy coding. The physical core 0 really can do two things at once, but only for some things. Much like how you can pet two cats in half the time with your two hands, but can only drink water at a rate limited by your mouth.

      The big things are this:
      1- It is rare to find a workload that works better with HT off
      2- It is common to find a workload that gets some speedup
      3- HT may have some vague security issues, based on recent actions from BSD etc. Maybe.

      Anyway, those three things should mostly determine whether you turn HT on or off on your box, and really just the first two unless you are Server Guy.

    4. Re: Never been a fan of hyperthreading by Anonymous Coward · · Score: 5, Funny

      I welcome these simultaneous-cat-petting analogies.

    5. Re:Never been a fan of hyperthreading by Tough+Love · · Score: 4, Interesting

      So what you're saying is, you have no idea what hyperthreading is but you don't like it because it does not benefit all workloads? I hope you can see what's wrong with that argument. If not, I will try to help.

      Hyperthreading (a simplified form of SMT is about putting cpu cores to work that would otherwise stall, e.g., waiting on a memory load. If your workload has everything in L1 cache then SMT won't do anything and just wastes transistors, which could have been better used by providing more cores or more cache memory. Most loads do hit enough memory that SMT is a win for parallel latency, however for those that don't, SMT can actually slow things down as multiple threads compete for limited superscalar resources such as register files. If there aren't too many parallel threads then it would be better to give each its own core.

      So here is the thing: to make best use of SMT you need to know something about how SMT works, and something about your workload. Then you can potentially use CPU affinity to tune your application. If you are ignorant about either of these things, or you can't justify the time to do the necessary tuning, or you don't have the necessary access, then sometimes, yes, SMT is just going to bite. But it wins on average, which is why all modern general purpose processors implement it, with the notable exception of ARM.

      Throughput is not the entire story about SMT, there is also power efficiency. Additional logic is required to fetch two independent instruction streams in parallel, keep them independent, and manage the additional cache complexity. This does not slow things down but eats power, which is why ARM so far does not implement it, and Intel does not use it for Atom. This sacrifices parallel throughput, and if you have any Atom devices, you will be painfully aware that they suck compared to their core arch cousins. Intel had to about face on this when AMD dropped Ryzen on them so now, some low end Intel parts also have hyperthreading.

      Fast forward to today's rumor. It should be clear that not having Hyperthreading/SMT hurts performance on average, but can improve power efficiency. Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    6. Re:Never been a fan of hyperthreading by gman003 · · Score: 5, Interesting

      A lot of them, actually.

      A modern "core" has several "execution units". Unlike very early x86, where it was divided between ALU and FPU, these are divided more finely and evenly - one might do integer math, vector shifts, and branches, while another might do integer math, vector logic, and data stores. There's usually redundancy on common instruction types (eg. Haswell has three that can do address stores, but only one can do divides).

      In a single thread, this is used for superscalar execution. If you have code something like "a = b / c; d = e * f;", both instructions can be run in parallel since neither depends on the other. This also hides the cost of x86's more complicated addressing modes - computing the address gets dispatched to an execution unit just like a normal multiply/add, and the result just gets sent to the store unit.

      But sometimes a thread has lots of dependencies, or does mainly a single type of operation. Maybe it's crunching through a bunch of multiply-adds. Rather than let the remainder of the core sit idle, you can run another thread, or even another process, on it. If this second one mainly hits a different EU - say, it's doing a lot of shifting and bit-twiddling - you can get a 100% speedup.

      You rarely get so much of a boost in practice. A worker-thread type of program, splitting a parallel task across cores, will generally be using the same execution units in each thread. And SMT doesn't help if you're bottlenecked on something besides execution - well-optimized code, as often as not, is limited by memory throughput rather than execution.

      The other boost comes from covering memory latency. If one thread hits a load that isn't in L1 cache, it will stall while the load is served. If it's in L2 cache, that's not too long - a dozen cycles or so. If you're going out to main memory, you're looking at a few hundred, maybe a few thousand cycles of NOPs - so why not switch to another thread, that has all it's data in L1 cache already? Modern x86 processors have pretty low memory latency compared to other architectures, so two threads is generally the most you'd find useful for this, but other systems with harsher memory latency will go even wider - the latter-day SPARCs do eight threads per core, and some parts of a GPU will operate in the hundreds. This is why some non-superscalar architectures will still have multiple threads per core - it's only ever actually running one instruction, but it will rarely be running zero.

    7. Re:Never been a fan of hyperthreading by Tough+Love · · Score: 3, Interesting

      Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.

      These are 95W parts. Video encoding should be just fine with these high frequency non-HT parts.

      But obviously, it would be better with HT. Going to the Arstechnica comments, the consensus is, this is just a marketing move by Intel. To be precise, i9 is the new i7, and open your wallets wider. It is possible that I am also right by saying that these non-HT i7's are targeted at mobile. Bragging rights, ok? "I have an i7 in my laptop, so cool [apple fan voice]". The catch being, i7 is the new i5.

      This game is going to push a lot of folks to Ryzen. Intel must know that. Maybe they are trying to keep Apple from going to ARM?

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    8. Re: Never been a fan of hyperthreading by Miamicanes · · Score: 4, Informative

      It made a big difference on WinXP with single-core CPUs because XP had lots of performance chokepoints that were limited to a single thread per "CPU".

      The name resolver (which handled not only DNS lookups, but drive-path resolution for Explorer as well) is a noteworthy example. If the browser triggered a "bad" DNS lookup, it would hang Explorer (including the Start menu) until the DNS lookup timed out (30-90 seconds later, IIRC).

      Hyperthreading mitigated 99% of that, because even if one name resolver thread got hung up, the other could keep chugging along.

      As of Win10, most of those chokepoints are gone, and HT is useful mainly with virtual machines (by simplifying program logic since each virtual core gets its own set of registers). The catch is, recently-documented security vulnerabilities suggest it can be used to leak info between VMs... a minor issue for someone using a VM to run Linux under Windows for convenience, but a potentially HUGE issue for comercial hosting services w/multiple unrelated customers.

      In any case, HT is a huge benefit with one single-core CPU, but offers little if you have 8 cores to begin with.

    9. Re: Never been a fan of hyperthreading by tlhIngan · · Score: 2

      So from this discussion it's interesting that hyperthreading has been stuck on 2 threads per core for so long. Why not 16 today?

      Because of diminishing returns. It's called "Multithreading" and not "Multiprocessing" because even though it shows up as a separate CPU core, it's shared resources could benefit from threads of the same process far more than disparate threads, especially with respect to cache utilization.

      It comes about because a modern CPU is super-scalar. That is, there are multiple execution units - often 3 (or more) integer units doing simple operations (adds, subtracts, bitshifts, boolean operations, etc), a couple of "complex" integer operations (multiply, divide), several load/store units (at least two each for loading and storing, and sometimes the effective address calculation uses the simple integer ALUs), multiple floating point units - again 2-3 for simple operations, 1 for complex operations and other units. Thing is, one program instruction stream, even with multiple instructions in flight simultaneously may not actually use all the resources. It's fairly cheap to tack on another front end execution unit and run another set of instructions through the same execution units, with the goal to have more utilization of the idle execution units.

      Thus, disparate workloads generally work better - if one is more integer versus floating point, you can often run both together without them colliding. But if you're using all integer, and even worse, both are using the same units, then it will not speedup.

    10. Re: Never been a fan of hyperthreading by burhop · · Score: 2

      I welcome these simultaneous-cat-petting analogies.

      You are going to love the future. Quantum computing is based on having a herd of schrodinger cats... more or less.

  2. spectre mitigation? by Anonymous Coward · · Score: 2, Interesting

    spectre-related attacks rely on predictive execution in hyperthreading.

    could this be a mitigation, while providing improved performance so the new part still exceeds the outgoing part?

    1. Re:spectre mitigation? by viperidaenz · · Score: 4, Informative

      spectre related attacks rely on speculative execution. hyperthreading is not speculative execution.
      There are plenty of CPU's vulnerable to spectre attacks that have no hyperthreading capability. turning it off on your Intel CPU doesn't mitigate it either.

  3. More important question: by Gravis+Zero · · Score: 2, Interesting

    Will these still need to have Meltdown and Spectre patches? If Intel are just pooping out new chips with no fix for the root cause then it's kind of a moot point to talk about it's speed.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:More important question: by 110010001000 · · Score: 2

      No they won't. Don't count on it. They will just speed up the mitigations.

  4. Can we get more pci-e lanes on the desktop? by Joe_Dragon · · Score: 2

    Can we get more pci-e lanes on the desktop?

    Not pay more or get less.

    AMD FOR THE WIN!!!!!!!!!!

  5. Everyone who cares disables it anyway by jader3rd · · Score: 3, Interesting

    I know we have to disable CPU level Hyper Threading anyway. Too many false cache swaps when it's on.

    1. Re:Everyone who cares disables it anyway by Anonymous Coward · · Score: 3, Informative

      anyone who cares tests to see if they are in one of the fringe cases that gets worse performance. Far more likely to either have no effect on performance or a slight increase.

  6. Maybe an attempt to amp their i9 line? by slack_justyb · · Score: 3, Informative

    So to recap the 8th gen of Intel. The i7 had the most cores at six with HT enabled. i5 was just like the i7 but with HT turned off. The i3 had HT in gen 7 so it was two cores/four threads, in 8th gen they gave it two more cores and turned off HT. So: i7=6/12, i5=6/6, i3=4/4. The i9 in gen 8 was really weird. The clock would scale down the more cores you used, it was very odd and minus the fact that the 18 core version was roughly the price of a used car, it was expensive. The price per performance with the i9 was incredibly low. A 3.4 Ghz i7 would give you a better CPU mark / $ by almost 200%, not to mention that an AMD six core FX-6300 would give you better CPU mark/$ by almost 800%. So clearly the i9 wasn't going to win you an award for price sensitive consumers.

    So all that said, and this is my opinion so it's literally worth whatever value you choose to give it, I think Intel is going to reposition the line up to disable HT on all "consumer" processors and focus on just keeping HT and "pro" features in the i9. I personally think it's a back hand to Intel consumers, but I'm an AMD fanboy so full disclosure there. But yeah, I think the i3, i5, and i7 are all going to eventually be labelled as the "cheapy", "actual desktop", "gamer" CPUs in that order and the i9 is going to be viewed as "workstation" and thus the i9 isn't going to focus on price/performance balance. So, i3 will be 4/4, i5 will be 6/6, and i7 will be 8/8 with the i9 being whatever crazy numbers they throw at the chips with hopefully not any of that weird scaling core/HT/Ghz stuff.

    That's just my hot take on this, open to hear what others think.

    1. Re:Maybe an attempt to amp their i9 line? by Anonymous Coward · · Score: 2, Insightful

      "Workstation" absolutely requires ECC support. So, no, i9 ain't going workstation anytime soon, that's for the gimped try-out low-end Xeons (the Xeon E3 in the old nomeclarture, maybe they're called Xeon "Tin" nowadays? because Bronze is the low-end Xeon E5)

  7. Re:Works for me by slack_justyb · · Score: 5, Informative

    If this is how they plan to deal with the Spectre/Meltdown issues permanently, I'm ok with that.

    HT has nothing to do with that issue. That's part of the instruction pipeline within the CPU. The core of it is a thing called speculative execution, where a CPU goes and fetches things before the actual instruction hits the core. The true fix will be to detect unprivileged instructions in the pipe (because actually getting rid of the pipe is *NOT* ever going to be an option) and then act on that.

    And the end of the day, if I can still play my games, I really don't care what's inside that hunk of silicon, as long as my games still work as good as they always have.

    Yeah I think that's ultimately what matters most here so I wouldn't worry too much about it anyway, just stay up to date on patches, which I'm sure you do.

  8. Re:Yeah hyperthreading can go by viperidaenz · · Score: 2

    HT on the old P4's was pretty shit. In most cases the overhead outweighed the benefits.
    Modern CPU's have a higher number of execution units per core now. the only way to keep them all running at once is speculative execution or hyperthreading. Using both is even better.

  9. It's? by DontBeAMoran · · Score: 4, Insightful

    It's base clock speed is 3.6GHz

    Surely you mean "Its base clock speed is 3.6GHz" and not "It is base clock speed is 3.6GHz".

    --
    #DeleteFacebook
  10. Re:Workloads may shift to GPU by Tough+Love · · Score: 2

    I am referring to some non-gaming tasks that can also move to the GPU.

    Some can, most can't. Many parallel loads could in theory be ported to GPU but this is a specialized, prohibitively expensive engineering task. Many parallel loads do not parallelize at the SIMD level. Without SIMD, a GPU becomes a fairly small number of low-clocked and non-superscaler CPUs with crappy branching characteristics and severely limited cache, basically turning the GPU into a decellerator. For these and other reasons, the vast majority of parallel loads will stay on the CPU for the forseeable future.

    --
    When all you have is a hammer, every problem starts to look like a thumb.