> The second downside is that threads might start fighting over the
> caches. This
> can be a particular problem if it gets to the stage where each thread is
> the other's data every few instructions. This can result in a massive
> and a net throughput of far less then a single thread would get.
Sounds like you're saying that there is a potential for a HT CPU to
switch context more often. If that is 'generally' true, then yes, I
think you're right, HT wouldn't be so great, if it's generally not the
case then, HT still sounds like a win.
> So in the best case, hyperthreading gives you twice the instruction
> with no slowdown on either thread relative to it running alone. In the
> worst case,
> it halves the size and associativity of your cache, and halves the size
> of the
> re-order buffer, for a massive slowdown, even if there are two threads
> So, basically, it depends on what the workload is.
Hmm, that sounds a little non-deterministic, so in reality it sounds
like the only .. 'real' way to find out how application(x) will perform
under a high system load, is to benchmark it.
I think for the upcoming release of Server software, I try out a
multiprocess binary mcpu=pentium4 compiled with a 184.108.40.206 smp/ht enabled
and without it enabled and see if there is any meaningful performance
increase/decrease... then maybe make an excel spreadsheet... to show net
increases, if they exist... marketing people love those !
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!