Thoughts on Hyperthreading

[Ribbit]

That makes some sense, although I suspect it's more about what CPU resources each thread is using (e.g. FPU vs. Integer). It does mean that it will be very difficult to write efficient HT-aware programs, as Wombat said. I guess that would also explain the performance decrease most benchmarks I've seen show with HT switched on.

Buddman, is threading performance really that important to you? If it is, you might want to look at building a proper SMP box (more costly, but what the hell, eh? ). If it's not, I doubt the performance increase (if any) from HT would be worth it.

[BuddMan]

Well, I'm waiting for the 3 GHz anyway, whether I get it or not. Hehe, if you guys only knew what I'm doing with this baby. It's gonna be one bad ass rig.

[Ribbit]

Originally posted by BuddMan
Hehe, if you guys only knew what I'm doing with this baby.

Well until I know better, I will assume that you're going to use it solely for playing Commander Keen, and therefore recommend you wait for Hammer or Prescott (not to mention Parhelia 2).

[WyWyWyWy]

VJ is correct as far as I know.

However, I think I've seen benchmark showing that P4 with Hyperthreading also benefits from normal multithreaded applications... have I?

[isochar]

The only real world case I've noticed a difference with hyperthreading is in distributed computing. My box can punch out about 12 SETI WU a day, with hyperthreading enabled it jumps to 18. (Similar performance jump is also seen in Prime95)

IMHO, the major advantage that hyperthreading will give Intel is that the P4's and future processors will have the multi-processor "smoothness" that duallie (and up) users have been enjoying for oh so long.

[Wombat]

You're giving it too much credit. Multi-threading like that only benefits apps when they wouldn't compete over the same resources. There's still a penalty for the context switch, and that's why HT is often (and from what I've seen, usually) slower. An MP box doesn't have the same issues.

[Ali]

But Ht only adds 5% to the die size, and offers from 0 to 30% increase in speed. From Intels point of view its a win win situation.

Making a app mulit threaded is a peice of cake. Making it inteligently mulit-threaded is probably a pain in the arse (never tried being overly intelegent with it).

If you are waiting for the 3.06G to come out anyway, and money is there, then I think it is probably worth it. Even if you dont gain much to start with, in the future you are more likely to see a difference.

Ali

[Wombat]

You left out the negative numbers Ali. Often HT slows down apps. Therefore, it's not a win-win. Also, it's not just the increase in die size, but it's <I>where</I> the circutry is that matters. Just think about HT for a second, and you'll realize that this is all extra impedence and space in the critical paths of execution. That sure matters.

[WyWyWyWy]

I dont think HT "often" slows down applications, it is just when a specific application is multithreaded in a way that HT (or multithreading in general) can't make a good use of.

However, we need to read more facts and see some more (and more) real world expirence to judge it.

I do think it is a win-win though. What do we work with mostly? Operating Systems (Win, Lin, BSD) are multithreaded and if further HT support is added to the kernel, we should see some really smooth operations...

[VJ]

What will be an important step - in my opinion - are the changes in the OS. Currently, Windows treats "both" hyperCPUs (so to speak) as two completely independant processors. If - as I believe is the case on some Linux distributions - the OS were to know in what way the hyperCPUs are related (e.g. if one is doing floating point, the other can't do it), it might be able to schedule the threads much better.
It would then take into account the fact that an app is slowed down by hyperthreading, and keep this application on one hyperCPU (thus not using the hyperthreading).


Jörg

[Wombat]

I dont think HT "often" slows down applications, it is just when a specific application is multithreaded in a way that HT (or multithreading in general) can't make a good use of.

No, really. It's a lot more common than you think. On average, the net gain with HT was about 0. It hurts as much as it helps.

[Ribbit]

Originally posted by VJ
If - as I believe is the case on some Linux distributions - the OS were to know in what way the hyperCPUs are related (e.g. if one is doing floating point, the other can't do it), it might be able to schedule the threads much better.
It would then take into account the fact that an app is slowed down by hyperthreading, and keep this application on one hyperCPU (thus not using the hyperthreading).

All that the Linux HT support does is try to schedule threads on different physical CPUs before using different logical CPUs on the same chip. There's not much the scheduler can do beyond that (that I can see anyway). The scheduler doesn't know whether a given thread is using FPU or not, all it really knows is how much CPU time each thread is using.

On another note, it occurred to me that one thing a programmer could do to make his program more HT-friendly is to have the threads operate out of the same small area of memory at a time, for better cache locality. But this would also be a bad thing for two reasons:

1. Behaviour like that is likely to increase lock contention between the threads, and

2. This is the exact opposite of what you'd do if you were optimising for true SMP.

Since true SMP will give much better performance in any case, and will be much more prevalent among people for whom threading performance matters, I predict that most serious applications will be optimised for SMP first, then HT later.

[WyWyWyWy]

Originally posted by VJ
What will be an important step - in my opinion - are the changes in the OS. Currently, Windows treats "both" hyperCPUs (so to speak) as two completely independant processors.

That's only Win NT & 2K.
XP knows HT.

Hopefully next 2K service pack MS will make it so that 2K knows HT too?

[VJ]

Originally posted by WyWyWyWy


That's only Win NT & 2K.
XP knows HT.

Hopefully next 2K service pack MS will make it so that 2K knows HT too?

Oh, interesting ! I didn't know that...
Indeed, hopefully it will be included in the next 2K service pack (I personally prefer 2K over XP - I always seem to get lost in XP )
Thanks !


Jörg

[KeiFront]

Ali
Making an app mulitthreaded isn't a peice of cake. Making good use of the different threads requires some coding (talking from experience).

Making it inteligently mulit-threaded is certainly a pain in the arse.

At the moment you can better buy yourself a real SMP system instead of a hyperthreaded system (it will probably cost you less and it will be faster). As Wombat says the net gain with HT is about 0.