Does Hyper threading cut CPU cores' clock speed by half?

No. Hyperthreading works by duplicating some parts of a CPU core (The registers and a few other components), but other components, such as the scheduler and ALUs are shared. As a result, while you gain a maximum double throughput in some workloads, if two threads need the same resources at the same time, one thread needs to wait until the other finishes.

The worst case of HTT is *maybe* a 5% performance hit due to poor scheduling, but that's very rare these days. The gains outweigh the benefits.
 


The gains outweigh the benefits?
 
Almost always.

In the Pentium 4 days, due to XP not really being designed for that use case, there were cases of 15% performance loss due to poor scheduling, but as of Vista that really isn't a problem anymore. You can safely treat HTT as adding ~10% performance on average in most cases, sometimes more.
 
He meant the gains/benefits outweigh the drawbacks, LOL.

Actual gains tend to depend on the app, just as with physical cores. Usually, though, a CPU with HT performs about 5-20% better than the same CPU type at the same frequency without HT (i.e. given a Haswell i5 & a Haswell i7 at the same clock frequencies, the i7 will outperform the i5 by 5-20%). It's a noticeable improvement...although not as much as actually going up in physical cores (i.e. a dual-core with HT outperforms a dual-core without HT, but a quad-core without HT will outperform the dual-core with HT).
 
I don't know why people say hyper-threading doesn't help games.. Yeah, not "directly" because of the game's code, but indirectly, does it help with dealing with the background stuff, therefore, increasing minimum fps?
 


In those tests, were there anything running in the background other than the game itself? I'm not asking if the game, itself, benefits directly from HT because of the game's code. I'm asking if HT helps what I said previously.
 
Yes, HT will help with "background" progams just like multiple cores do, in the sense of being able to simultaneously run multiple apps.

However...

Technically speaking, Windows has been able to run "simultaneous" apps for a long time -- well before multi-core CPUs -- by essentially switching back & forth between the apps every so many clock cycles. We can't perceive it directly, of course; when a CPU can run billions of cycles a second, we literally aren't fast enough to see the OS switching from app to app every 10,000 cycles (or every 10 microseconds). However, what we do see is the slowdown in the apps themselves: if an app only gets 20% of the CPU's resources every second because it's sharing CPU resources with 4 other apps, it's going to take 5 times as long to complete its operations.

Multi-core CPUs take it a step further. Each core is separate from the other, & is treated as a separate CPU by the OS. So, if you have a quad-core CPU, & you have 4 apps running simultaneously, then they each have access to a full CPU's resources, & only have to share the other hardware/software in the machine (RAM, disk read/write access, Internet connection, etc.). So, for example, if you have 4 apps that all need 2GB or less of RAM, & you have a quad-core CPU with at least 8GB of RAM, then you can run all 4 apps at full speed; an older single-core CPU, even with the same RAM, would run noticeably slower, because the 4 apps would be sharing a single CPU, instead of each app having their own CPU.

HT bridges the gap between single- and multi-core CPUs. It's kind of a separate OS that layers on top of your normal OS, telling your system that there's twice as many cores as you physically have. Just like with physical cores, it lets you run additional apps on "separate" cores. But in order to do so, the HT "layer" splits the CPU's physical resources: clock cycles, L2/L3 cache, etc. So it doubles your cores from the OS's perspective, but each "core" now has the potential to run slower than normal because each only has access to half the normal resources.

Now, some apps (including games) have been coded to take advantage of multiple cores. Instead of the app running everything through a single core, it splits up its instructions & processes so that they can be fed through multiple cores simultaneously. It's not an automatic thing, though; it has to be specifically set up when the app is developed. HT is probably also similar, in the sense that your app would need to recognize that the CPU is equipped with HT.
 
*sigh*

1: Software really doesn't care how many cores you have; a thread is a thread, and it's up to the OS, not the developer, to handle thread scheduling. And the OS has gotten pretty good at it these days.

2: Hyperthreading does help a ton in games. Easy test: Compare a Pentium to an i3, or an i5 to an i7. You don't notice improvement on i7 chips as much because there isn't any real CPU side improvement to gain, but at the low end, Hyperthreading is the reason an i3 can still perform decently, while a Pentium can't.