Turkey3_scratch, there are a lot of sites which explain hyperthreading. Depending on level of detail, you have anything from simple analogies to several page reports getting into the detail of how exactly it interacts with various types of software. Not all software makes the best use of hyperthreading so you can have a program that runs no different from non ht, 5-10% better, 25% better, 5% worse etc. Ht doesn't split a core into 4 virtual cores, only 2. (Unless intel changes their architecture). There are shared resources which if a piece of software is coded properly can make use of the shared data. If not it can hurt performance. For each core with htt, it's capable of processing 2 data pipelines (thread, processes) simultaneously. If one thread stalls waiting on data to catch up, the cpu core can continue processing using the other thread and it keep the cpu cores busier than they would otherwise be. While there's some performance improvement, ideal/best case scenario is about 25, rarely 30% more performance.
I have a feeling it would take ages trying to get into nit picky detail and breaking down how various programs are coded to determine how the cpu interacts with ht involved. That's why it often gets condensed to x amount better performance. Simply knowing for the sake of knowing would take some research and would likely involve understanding coding since the two interact with one another. That's a whole different avenue of research. The trouble is whether or not ht works and how well it works is dynamic and code dependent. It's not as simple as 'bingo, 30% improvement in everything'.
This benchmark page shows how different programs and even different versions of the same program utilize hyperthreading differently.
http://www.extremetech.com/computing/133121-maximized-performance-comparing-the-effects-of-hyper-threading-software-updates
https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.resourcemanagement.doc_41/managing_cpu_resources/c_hyperthreading.html
https://www.pugetsystems.com/labs/articles/Hyper-Threading-may-be-Killing-your-Parallel-Performance-578/
http://www.pcworld.com/article/2971612/software-games/windows-10s-radical-directx-12-graphics-tech-tested-more-cpu-cores-more-performance.html
These are only a handful of programs and others may use ht more effectively but some good comparisons since they took the i5 4690k and the i7 4790k and oc'd them to the same speed (4.7ghz). Many of the problems of comparing an i5 and i7 4790k come from so many variables. One has 6mb cache, the other has 8mb cache. One is clocked stock at 3.5 (3.9 turbo), the other is stock at 4ghz (4.4 turbo). One has hyperthreading, one doesn't. With so many variables, it's apples and oranges really when trying to compare performance. Clocking both at the same speed removes one of the bigger variables, the speed difference. Now we're down to variation in cache size and hyperthreading.
http://www.anandtech.com/show/8227/devils-canyon-review-intel-core-i7-4790k-and-i5-4690k/3
For instance looking at the page above, encoding with handbrake. Just comparing the two cpu's out of the box the i5 achieved 510fps while the 4790k achieved almost 583fps. It appears that hyperthreading gave the i7 a 15% performance advantage - or did it? If you look at the i7 4790 (non k) since it has a closer stock clock to the i5, the difference is 8fps or 1.6%. When clocked the same as the 4790k, the difference is 3%. It's important to consider all factors when comparing cpu performance in real world programs since the larger performance gains of an i7 over i5 aren't always ht related.
How ht works with an i3 compared to a pentium g is a bit different. The fundamentals of ht are similar through the intel lineup but you're comparing 2 simultaneous threads vs 4 instead of 4 vs 8. There's a larger difference at the lower end in most cases. That's why even multithread aware programs that can properly utilize ht show smaller margins of improved performance on a 6c12t 5820k vs a 4c8t 4790k. It's possible that programs aren't 'that' heavily multithreaded but increasing the hardware of a cpu by 50% doesn't net 50% improvements.
With all the specs and details that can make someone's head spin, it's typically a lot easier just to look for a particular benchmark. If a person said to themselves ok, I do video encoding and I use handbrake to do it (handbrake used more often than not because it's open source/free and available to anyone to use). Now, let's compare cpu's on handbrake since that's a program I use (hypothetically). How much faster is one over another? Forgetting all the details, someone can see what all that fancy mumbo jumbo really means. Is it shaving the encoding time in half? Or merely knocking a few seconds off every hour of video? All the impressive theory in the world means squat if it doesn't translate into actual gains. No one can see a benefit whether their cpu uses modules, straight cores, htt etc. What they will actually notice is encoding time differences. 2sec here and 8 sec there means very little. Reducing a 30min encoding project to 20min on the other hand is something the user will appreciate. (Just one example).
Facebook
Twitter
Instagram