Threads != cores though. The best analogy I can give is that threads are like hands, you are 2 threads 1 core (In this analogy) but you still only have one mouth. You can only eat one thing at a time. You could have 16 hands (threads) but still only one mouth (cores) so it's only going to get you so far (Which is why we don't see 4 core 16 thread CPU's)
There's a reason why Intel has never marketed threads as cores, because they're not. They know that, we know that.
cores shared a floating point unit, and therefore wasn’t a complete core
Cores are independent entities which are effectively mini-chips. Hardware threads are reusing the logic units within the same core during their idle period. This works for like workloads but when the pipeline needs to be flushed then everything stalls until the pipeline get filled again.
Hyperthreading is just there because x86 instructions are different length. By feeding 8 threads, it is much more likely that all 4 cores will be used close to the maximum. If you send 8 identical-length instructions to a hyper threaded x86 it will take twice as long as 4 identical-length instructions.
That's the problem right there.
People are struggling with and arguing about what's essentially a marketing term.
A "core" doesn't really mean anything. There are parts in a modern CPU that are there once, there are parts that are there two, four, eight, sixteen or hundreds of times. What is usually called a core is just a larger bunch of CPU parts that repeats several times. What we call a dual core with HT could be easily called quad core, it's just that the cores' pairs would share a lot more resources, and we (they) decided to call that tight bond "hyperthreading" instead. And many more bonds are still there, it's not like you can yank a core from a CPU and expect it to work, the cores still share resources (like caches) and (just like two threads on a hyperthreaded core) they affect each other a LOT, e.g. a workload on a single core can eat lots of memory bandwidth and cause increased latency and cache misses on different cores.
I've already said it here somewhere and I'll say it again.
As a programmer, I don't give a crap about "cores".
I don't give a crap about single"core" performance or multi"core" performance.
I think in threads.
Either my code is single-threaded, and in that case I only care how fast the CPU is able to execute it.
Or it's multithreaded, and in that case I need to know the number of threads I have to throw at the CPU in order to squeeze all the available performance out of it.
For an old-school quad core and a general workload (memory access AND number crunching) that number could be 4 threads.
For a quad core with HT that number could very well be 8, because some number-crunching parts of the CPU are present more than four times and my threads can benefit from this even though they'll compete for different parts of the CPU and maybe stall each other more often.
For a big.LITTLE CPU that number can by anywhere between 4 and 8, maybe the little cores are really slow and shouldn't really be used for intensive workloads.
Programmers talk about threads, because that's what programs are made of.
Engineers sometimes talk about cores, but in the context of a specific architecture, where the term "core" refers to a specific set of CPU parts.
Marketing departments talk about cores when they need a big number to show on the box.
Laymen have heated discussions about the number of cores and "single core performance" when they could be tending to the garden or playing with the dog or doing anything more enjoyable than falling into this trap.
Btw the same goes for RISC vs CISC.
