OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 3:47 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Bochs hyper-threading support
PostPosted: Sat Apr 16, 2005 3:42 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Candy wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sat Apr 16, 2005 11:02 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sat Apr 16, 2005 2:28 pm 
what's hyperthreading exactly?


Top
  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sat Apr 16, 2005 5:32 pm 
A feature found in Pentium 4s allowing the cpu pretend being two cpus, giving some of the features of a multiprocessor based system.


Top
  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 3:45 am 
zyp wrote:
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


Top
  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 3:53 am 
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.


Top
  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 3:56 am 
AR wrote:
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.


Top
  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 4:40 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

srg wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 5:32 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3882
Location: Eindhoven
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.


Top
 Profile  
 
 Post subject: Re:Bochs hyper-threading support
PostPosted: Sun Apr 17, 2005 12:02 pm 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 6:06 pm
Posts: 1437
Location: Vancouver, BC, Canada
Candy wrote:
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.

_________________
Top three reasons why my OS project died:
  1. Too much overtime at work
  2. Got married
  3. My brain got stuck in an infinite loop while trying to design the memory manager
Don't let this happen to you!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 71 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group