Will but it is rather arguable whether ANY consumer centric app would even utilize enough threads to even make use of HT...

Server apps harly have any use for HT IIRC. IMO they shouldn't be splitting more resources into more threads, rather trying the reverse instead- if that is possible without much intervention from native OS.

HT only brings more hot spot on cpu and generally increase heat and power consumption. That's why for now they didnt implement it.

Let's just say that HT was not exactly very good SMT, on a not very good processor core. Nehalem's SMT implementation will probably be substantially different.

Why would you want to put even more cores into a single thread when many resources on each core are sitting idle as it is now? It's bad for perf/watt. SMT done well generally improves perf/watt.


A form of SMT is probably already in Core2 chips, but not enabled for public use. It's not trivial to implement, because they can't just take "HT" from the P4 and put it in there. Completely different chips, so completely different approaches. HT in p4 actually does help many well written applications. At the time most applications were not designed for multithreaded systems, but now they are. So i think it's a good time to reintroduce SMT now. Of course increasing utilization will increase power and hot spots, but it's still better than idle units that are leaking power doing nothing.

Ever heard of Sun's Niagara (UltraSparc T1) chips? 8 cores with 4 threads per core = 32 thread monster.
Now there's Niagara2 (UltraSparc T2) -> 8 cores with 8 threads per core = 64 thread beast.
These are ultra powerful web/transaction servers.

Reverse-HT seems to be a big myth propogated by the AMD fanbois based on some dubios comments from the Inq.


That's where the hi-k dielectric in 45nm comes in to play.

Hi-k dielectric helps with gate leakage, but it does not do much for sub-threshold leakage, which is as much of a problem. Increased utilization is usually preferable in a wide chip such as the core2.

Anyway, as long as who capture the performance crown no matter of slightly higher power consumption will be chosen.

yup u rite,...
power consumption must be considered in order to archive maximum performance...

I liked the Niagara 2 design a lot, but all in all the design itself would have no place in a x86 consumer centric market (even if it ran x86!)
You would have say, 16 threads max. utilized at one moment. Coders don't prefer coding massive parallel code unless it comes with noticible benefits (which aren't required on the consumer market yet)

Generally you want less cores as possible for less complexity while maintaining the highest speed. There are quite a lot of apps that only scale good to dual-core ATM- quads don't even provide a substantial increase. So why more focus on getting the most juice out of your already very capable 4-core? You know for once I'd leak some power.

HT had a nice increase because the P4 was essentially single cored, and most apps tested on it were taking advantage of optimizations for workstations with dual+ Xeons/Opterons I presume.