Re: [SLE] For or against ..Hyperthreading.
From: Filipe Joel Almeida (fijo.lists_at_netcabo.pt)
Date: 08/31/03
- Previous message: Michael Satterwhite: "[SLE] Scripting"
- In reply to: Adalberto Castelo: "Re: [SLE] For or against ..Hyperthreading."
- Next in thread: Dylan: "Re: [SLE] For or against ..Hyperthreading."
- Reply: Dylan: "Re: [SLE] For or against ..Hyperthreading."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: suse-linux-e@suse.com Date: Sun, 31 Aug 2003 21:52:22 +0100
On Sun, 2003-08-31 at 15:45, Adalberto Castelo wrote:
> There are two contexts you want to analyze this in: scientific
> applications and non-scientific apps. SA are usually compute intensive
> algorithms that take a task and divide it in smaller parts -- the term
> SIMD, tho it usually refers to computer architectures, could also be used
> here (Single Instruction stream, Multiple Data streams). So, in a common
> parallel SA, all pieces are executing the same instructions over and over
> again, but over diff parts of the data. This is by far the most common
> kind of high demand sci app you'll see: weather models, finite element
> analysis, protein folding, pattern discovery, etc. There are other types
> of algorithms (I described the divide-and-conquer type), but they are far
> less common.
>
> NonSA is a context where you have lots of different apps doing different
> things on different data (most common) or one app doing different things
> over the same data.
>
> Now, to answer your question: if you'll run on a SA context, forget about
> HT and go get a real SMP machine. HT will slow you down. Reason: HT is
> just a mechanism that facilitates parallel access to the computing units
> inside the processor (integer units, floating point units, etc.). The
> clock speed is not affected (theoretically). So, if all your threads are
> trying to use THE SAME units, there'll be contention, and delay while a
> thread wants for a unit to clear. These delays involve overheads, that
> will make the app slower than in a single thread mode.
>
> If you'll run on the NonSA context, then HT will perhaps help you (true
> SMP will always be better tho). Reason: mix of apps (integer based,
> floating point based, etc.) may be using different processor units,
> effectively allowing HT to seem like two different processors. It will of
> course depend on the mis of apps. My gut feeling is that it would help.
>
> I hope that helps.
>
> Adalberto
Well Adalberto, that was definitively a pretty good explanation!
But personally I'm also curious about something else. I have asked this
lots of times, one of them in this list, but noone has been able to give
me a good answer.
What are the major benefits of a 64 bit processor over a 32 bit
processor?
Let's say for mail or Database server... would there be significant
benefits from having a Dual Opteron over a Dual Xeon, and stuff like
that?
Can anyone please shed some light on this subject?
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
- Previous message: Michael Satterwhite: "[SLE] Scripting"
- In reply to: Adalberto Castelo: "Re: [SLE] For or against ..Hyperthreading."
- Next in thread: Dylan: "Re: [SLE] For or against ..Hyperthreading."
- Reply: Dylan: "Re: [SLE] For or against ..Hyperthreading."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|