Bochs hyper-threading support

[Brendan]

Hi,

Do you still have those HT files? Would very much like to do that myself if necessary.

I put all the files and information for adding hyper-threading support to Bochs on my web server. This should make it easy for other OS developers to add HT support.

The URL is:
http://bcos.hopto.org/bochs.html

Hopefully it will also make it easy enough for the Bochs developers to add HT support to the official Bochs project, so I don't need to hack each new version of Bochs .


Cheers,

Brendan

[Brendan]

Hi,

Just a quick note - I messed it up .

One of the files (cpuid.cc) within the source code tar.gz from my site was the older version rather than the HT version. I changed the name of the corrected tar.gz to "bochs-ht-source.tar.gz" so you know it's the right one (rather than something cached somewhere). Thanks go to Stanislav Shwartsman for pointing this out.

If you've downloaded this, please try again and accept my apologies..

As a side note, it looks like if HT support can be shown to be "heavily tested" it will be included in the official Bochs 2.2 release. With this in mind, if anyone tries HT support please let me know which OS/s you tried and if it worked or not so I can pass the information on .


Thanks,

Brendan

[Poseidon]

what's hyperthreading exactly?

[zyp]

A feature found in Pentium 4s allowing the cpu pretend being two cpus, giving some of the features of a multiprocessor based system.

[srg]

A feature found in Pentium 4s allowing the cpu pretend being two cpus, giving some of the features of a multiprocessor based system.

I've heard that Hypertheadding only works like this if one thread is doing integer math and the other is doing fp at any one time.

srg

[AR]

Hyperthreading (IIRC) is basically the same as Dual Core, except instead of there being 2 completely seperate chips, they share the Instruction Unit, so effectively whenever one "half" is doing a memory read or waiting for something, the other "half" can execute.

This is ment to give some performance improvement but I wouldn't imagine it would be that great since the "CPUs" effectively take turns processing instructions.

[srg]

Hyperthreading (IIRC) is basically the same as Dual Core, except instead of there being 2 completely seperate chips, they share the Instruction Unit, so effectively whenever one "half" is doing a memory read or waiting for something, the other "half" can execute.

This is ment to give some performance improvement but I wouldn't imagine it would be that great since the "CPUs" effectively take turns processing instructions.

I'd just heard that was an Intel marketing based myth.
Maybe they just got the wroing end of the stick, ok.

srg

BTW Totally agree with the sig statement, any os that allows use programs to write in the kernel space is asking for trouble, no wonder it wasn't very stable. Although Win9x's goals were compatibility over stability.

[Brendan]

Hi,

I've heard that Hypertheadding only works like this if one thread is doing integer math and the other is doing fp at any one time.

Not really. The problem with modern CPUs is that there's many reasons for "pipeline stalls", including waiting for data to come from memory, situations where one instruction needs to wait for the results of a previous instruction, branch mis-prediction and situations where the pipeline/s needed for an instruction are in use.

The idea of hyper-threading is to execute multiple unrelated instruction streams at once, so that if one instruction stream is stalled for any reason the other can continue.

For example, if the code reads from memory (and the data isn't in the cache) it can take a relatively large amount of time for the data to become available. Without hyper-threading this can leave the CPU with nothing to do.

That's why the actual performance improvement of hyper-threading can't be easily predicted - it depends on what each stream of instructions is actually doing. If both streams are using different pipelines (e.g. if one stream is doing integer math and the other is doing fp), or if both streams spend a lot of time waiting for data from memory (e.g. working on large arrays with random access patterns) then you'd get a very good improvement.

If both streams are highly optimized to avoid all pipeline stalls, then HT won't help at all. In practice it's very rare for this to happen though.

Performance increase associated with HT is estimated to be between 5% and 60%. This is total performance increase, rather than the performance of a single instruction stream (which is reduced rather than improved, as the same CPU's resources are shared).

This has led to people using poorly written (single threaded) applications commenting that hyper-threading makes the application run slower. It'd be the same if you compared a computer with a single 2 GHz CPU to a computer with a pair of 1.4 GHz CPUs.


Cheers,

Brendan

[Candy]

So, the conclusion is that if you run multiple badly-written (or compiled) programs next to each other they both speed up. If you run two very different programs next to each other they speed up.

Common usage is however either using badly-written (compiled) programs one at a time (common users) or using multiple properly compiled or optimized programs simultaneously. Both cases trash the processor speed. It was written with the windows power user in memory, and there just plain aren't many power users fitting the windows access pattern.

[Colonel Kernel]

So, the conclusion is that if you run multiple badly-written (or compiled) programs next to each other they both speed up. If you run two very different programs next to each other they speed up.

Common usage is however either using badly-written (compiled) programs one at a time (common users) or using multiple properly compiled or optimized programs simultaneously. Both cases trash the processor speed. It was written with the windows power user in memory, and there just plain aren't many power users fitting the windows access pattern.

The amount of instruction-level parallelism (ILP) that can be exploited from an instruction stream depends mostly on what the code is actually trying to do. For example, FP-intensive code tends to have few branches, and these branches tend to be very predictable (think tight loops doing 3D calculations, or audio/video transcoding, or whatever). This kind of code tends not to cause pipeline stalls, unless the FPUs themselves are not well pipelined (depends on the microarchitecture under discussion... I'm not too familiar with the implementation details of AMD vs. Intel FPUs). Compilers can also do some nice optimizations like loop unrolling on this kind of code to remove dependencies between instructions and give it the highest potential ILP.

Integer code is typically the opposite. It branches more unpredictably, and it is usually full of data dependencies between instructions. It is extremely difficult for compilers to optimize these dependencies away (otherwise I would think IA-64 would be a lot more popular ).

In other words, we're dealing with the nature of the code itself, not how it was written or compiled, or what OS it runs on, or what kind of user is involved.

From the point of view of a hyperthreaded processor, the two threads being run simultaneously just looks like one instruction stream where there are no explicit dependencies between many of the instructions. They will only hamper each others' execution when there is contention for the same functional units, or if they're kicking each other out of the caches (which is a known problem with HT processors IIRC). HT is not perfect... a good rule of thumb for an MP OS is to schedule threads onto separate cores before pairing them up on a single HT core.