[RC5] Does Intel hyperthreading help?

bdragon at distributed.net bdragon at distributed.net
Tue Aug 19 19:01:01 EDT 2003


> From: bdragon at distributed.net [mailto:bdragon at distributed.net]=20
> > It ultimately depends on the process scheduling=20
> > efficiency of your operating system.=20
> 
> Can you even define for us "process scheduling efficiency"? Even if
> you're talking about the number of instructions needed to do context
> switching between processes or threads, which I doubt you are, what
> could that possibly have to do with Hyperthreading?

I'm speaking of how much cpu time is spent determining which process
should gain access to the cpu at any given point. Having a second
apparent processor makes such scheduling issues ease up until you
have one more process seeking cpu resources than you have cpus.

> Hyperthreading acts like a dual-processor system, but with a much slower
> second processor. It only helps when your applications are (1)
> multi-threaded and (2) the different threads utilize different parts of
> the CPU.=20

I would think the same would apply with multiple single-threaded processes
as well, as long as "2" above still applied.

> For example, say  process A utilizes 10% of integer pipeline #1 and 100%
> of the main floating point pipeline. Process B, without Hyperthreading,
> would simply time-slice with process A, that is only one of them would
> be executing at any given time. With hyper-threading turned on, the
> additional 90% of integer pipeline #1 can be utilized to some extent for
> process B, improving the completion time for all tasks.

I don't see how this differs from my statement of the CPU handling
scheduling better than the OS. It does, however, rely upon the OS
scheduling two compatible processes simultaneously, rather than 2
processes competing for identical resources (in which case you simply
have overhead).

Based upon the Intel documentation, Windows XP apparently has specific
hooks for this, however I don't know if that means it attempts to predict
what resources 2 processes or threads are likely to request in an attempt
to best utilize hyperthreading (or if that would even be a net win
given the resources devoted to tracking that data).

> > If the OS is a good scheduler, you'll likely hurt=20
> > performance due to the aforementioned additional overhead.
> 
> This seems to be meaningless techno-babble. What is a "good scheduler"?
> What exactly is the additional overhead?

A good scheduler is one which efficiently allocates resources based
upon your needs. As such, good would be subjective, and varies based
upon your needs.

The overhead would be:
additional cpu procedures to emulate a second processor, govern access
and contention.
additional OS procedures to manage access and contention with a second
CPU
possibly additional OS procedures to measure and hypothecate about
future thread/process resource needs in order to best schedule with
hyperthreading

> > I've heard of performance increases with hyperthreading=20
> > under Windows, fwiw.
> 
> And Linux, BeOS, or any other multi-threaded OS running the right mix of
> multi-threaded *applications*.=20

I have not heard of any results for any other OS, hence my not stating
anything for them. The results noted, if I recall correctly, were spoken
of in this very forum (or it might have been #distributed).

> You obviously have a bias against Microsoft, but do you really think
> Windows just sits there running NOPs at random? There might be a bunch
> of unnecessary, inefficient branches in MS code, but the processor is
> actually doing *something* when it runs through those instructions. I
> can't see how this would make Hyperthreading any more or less effective.

While I'm not a fan of windows, your paranoia is unfounded. See above.



More information about the rc5 mailing list