Jump to content

Core vs thread

A.T
Go to solution Solved by Mark77,

Well, think of going to a concert.  There are 4 entry gates (ie: 4 cores in a CPU) where someone validates tickets.

 

If everyone is well behaved and in line, the 4 entry gates are utilized very efficiently and lots of people are admitted to the concert.

 

But we know that's not often the case.  Sometimes people take time to find their tickets (ie: it takes extra time to decode instructions in a CPU).  Sometimes there are data items that have to come out of main RAM (sometimes people need to dump their water bottles and other prohibited items). 

 

The whole idea of hyperthreading is that basically you split things into 8 lines that go to the 4 entry gates.  With someone monitoring those lines to make sure everything is in order.  As a result, those 4 gates are used very efficiently. 

 

Intuitively this is why there are some workloads which are multi-threaded/multi-processor capable, but don't benefit much, if at all from hyperthreading.  Video rendering comes to mind, as video rendering calculations are very highly structured and repetitive. 

 

There are workloads that are very chaotic, which highly benefit from hyperthreading.  Heavy multitasking, virtualization, etc. comes to mind. 

 

So the answer to your question heavily depends upon workload, although core for core, its usually better to have real cores, than hyperthreads.  But real cores cost a lot more silicon and consume a lot more power.  Hyperthreads are a great, relatively low cost compromise to leverage existing resources which may not be optimally utilized.  Hyperthreading adds, at best, a few more percent to a CPU in terms of die space and can double some workloads' performance.  Doubling the core count doubles the required silicon. 

 

 

 

What is the main difference in how they WORK not what they are . Imagine intel realises a Cpu with same stuff as a i7 6700k but 8 cores and no hyper threading would it be better then the normal i7 6700k or almost the same

Link to comment
Share on other sites

Link to post
Share on other sites

Well, think of going to a concert.  There are 4 entry gates (ie: 4 cores in a CPU) where someone validates tickets.

 

If everyone is well behaved and in line, the 4 entry gates are utilized very efficiently and lots of people are admitted to the concert.

 

But we know that's not often the case.  Sometimes people take time to find their tickets (ie: it takes extra time to decode instructions in a CPU).  Sometimes there are data items that have to come out of main RAM (sometimes people need to dump their water bottles and other prohibited items). 

 

The whole idea of hyperthreading is that basically you split things into 8 lines that go to the 4 entry gates.  With someone monitoring those lines to make sure everything is in order.  As a result, those 4 gates are used very efficiently. 

 

Intuitively this is why there are some workloads which are multi-threaded/multi-processor capable, but don't benefit much, if at all from hyperthreading.  Video rendering comes to mind, as video rendering calculations are very highly structured and repetitive. 

 

There are workloads that are very chaotic, which highly benefit from hyperthreading.  Heavy multitasking, virtualization, etc. comes to mind. 

 

So the answer to your question heavily depends upon workload, although core for core, its usually better to have real cores, than hyperthreads.  But real cores cost a lot more silicon and consume a lot more power.  Hyperthreads are a great, relatively low cost compromise to leverage existing resources which may not be optimally utilized.  Hyperthreading adds, at best, a few more percent to a CPU in terms of die space and can double some workloads' performance.  Doubling the core count doubles the required silicon. 

 

 

 

Link to comment
Share on other sites

Link to post
Share on other sites

Physical cores always peform bettter tha. Logical cores. 

 

A core with HT basically splits itself and instead of one task it can work on two.

 

Thats the simpliest explanation i think. Correct me if im wrong.

 

Full power of one core for one task gives the best possible performance and thats why i5 is so much more expensive than i3.

 

Edit: AMD uses its own HT on FX chips but their architecture is different so they dont directly compare to intel. We are waiting for AMD to catch up a little bit with Zen CPU line because their latest FX8000 is over 4 generstions behind Intel.

Connection200mbps / 12mbps 5Ghz wifi

My baby: CPU - i7-4790, MB - Z97-A, RAM - Corsair Veng. LP 16gb, GPU - MSI GTX 1060, PSU - CXM 600, Storage - Evo 840 120gb, MX100 256gb, WD Blue 1TB, Cooler - Hyper Evo 212, Case - Corsair Carbide 200R, Monitor - Benq  XL2430T 144Hz, Mouse - FinalMouse, Keyboard -K70 RGB, OS - Win 10, Audio - DT990 Pro, Phone - iPhone SE

Link to comment
Share on other sites

Link to post
Share on other sites

8 minutes ago, Thony said:

Edit: AMD uses its own HT on FX chips but their architecture is different so they dont directly compare to intel. We are waiting for AMD to catch up a little bit with Zen CPU line because their latest FX8000 is over 4 generstions behind Intel.

I gave you thumbs up for the first part of your post, but this is simply not true. The FX procesors have physical cores with shared resources, which is completely different from Hyperthreading -for which you provided a good simple explanation. Specifically, every 2 cores in the FX chips share a Floating Point Unit and some of the cache. Sharing the FPU is what lead some people to say "it's just one core with some bells and whistles", but that's a huge overstatement of the importance of the FPU for CPU computations. In particular, heavy multithreaded programs that saturate the cores for long periods (the kind of programs Mark77 lists as benefiting less from HT) will exhibit "near 1/n" scaling despite the bottlenecks present inside each module (where one must take into account that fully independent, non-shared resources cores will achieve "near 1/n, but not quite" themselves, so it's downhill from there).

 

34 minutes ago, Mark77 said:

There are workloads that are very chaotic, which highly benefit from hyperthreading.  Heavy multitasking, virtualization, etc. comes to mind. 

 

So the answer to your question heavily depends upon workload, although core for core, its usually better to have real cores, than hyperthreads.  But real cores cost a lot more silicon and consume a lot more power.  Hyperthreads are a great, relatively low cost compromise to leverage existing resources which may not be optimally utilized.  Hyperthreading adds, at best, a few more percent to a CPU in terms of die space and can double some workloads' performance.  Doubling the core count doubles the required silicon. 

I'm not aware of any task that can experience a doubling in performance from HT (or a 50% increase for that matter), but I can't disagree with the main point, so another thumbs up ;) 

Link to comment
Share on other sites

Link to post
Share on other sites

A modern Skylake processor has 7 arithmetic logic units (ALUs) and they are capable of different things. The CPU doesn't actually run instructions one after the other, Intel processors are known as out of order processors and they analyse all the instructions they are given and try to run the program in parallel on the 7 ALUs it has. You can think of the ALU as the piece that does the actual maths while the core itself deals with concerns of going to and from memory or decoding an instruction into lots of calls to the ALUs.

 

When you have hyperthreading you have 2 Cores exposed to the operating system, so it will run 2 programs on it. But those 2 Cores are actually the same 7 ALUs they are shared between the two of them. If the programs you are running use different types of instructions then you may very well get better utilisation of the 7 ALUs (since they are all different) and get a performance boost, it can be worth about 30%. However if both programs are using similar instructions then they are fighting for the same ALU to do the same thing and as such wont run faster, they may infact run a little slower due to other concerns (shared cache and pipeline bubbles).

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×