Author: Robert Hyatt
Date: 21:41:02 03/08/03
Go up one level in this thread
On March 08, 2003 at 03:10:48, Matt Taylor wrote: >On March 05, 2003 at 18:11:25, Robert Hyatt wrote: > >>On March 05, 2003 at 15:13:41, Aaron Gordon wrote: >> >>>On March 05, 2003 at 11:36:30, Robert Hyatt wrote: >>> >>>>On March 05, 2003 at 02:05:30, Aaron Gordon wrote: >>>> >>>>>On March 04, 2003 at 21:57:58, Nolan Denson wrote: >>>>> >>>>>>There are no draw backs when looking to get a computer that using >>>>>>Hyper-Threading. If you do not like the feature you can just simply turn it off. >>>>>>There are many system on the market that claims to be Hyper Threading enabled. >>>>>>Intel has a utility program that checks for Hyper Threading ... >>>>>> >>>>>>1. You must have the proper CPU's. >>>>>>2. You must have the proper motherboard. >>>>>>3. You bios must support it. >>>>>>4. Your Operating system must support it. >>>>>> >>>>>>Once these things are met your system will indicate that Hyper Threading is >>>>>>enable before booting into the Operating System. >>>>>> >>>>>>It is not an indication that you will see when the computer is turned on and the >>>>>>Bios is posting. >>>>>> >>>>>>Soon all of Intel processcor's will have Hyper Threading. So if what you are >>>>>>using your processor slows down with Hyper Threading, just simply turn it off >>>>>>via the Bios. >>>>> >>>>>How convenient. Have to reboot 20 times per day to turn it on/off just so your >>>>>applications run optimally. I'll be sticking with the cooler running, faster, >>>>>and cheaper AMD chips. :) >>>> >>>>You don't have to do this. Just use an SMT aware operating system and just run >>>>two >>>>tasks, although I think there is _zero_ chance that a parallel algorithm that >>>>works with >>>>two threads on a dual processor will behave _worse_ using two threads on a >>>>single SMT >>>>cpu than it does using just one thread. SMT is not going to _worsen_ >>>>performance, >>>>particularly if spinlocks and spinwaits are used correctly. Since most programs >>>>don't even >>>>use 'em, it isn't an issue at all. >>> >>>If you read around you'll see when SMT is enabled it can hurt performance up to >>>20% just as it helps in some cases up to 20%. Be it SMT or bad programming, it >>>does it. I dislike P4's anyway (hot, slow, etc) and if there's something that >>>can potentially hurt it's performance even more.. well, it's time to glue the >>>cpu to the wall and let the cat use it as a cat scratcher. Thats about all it'd >>>be worth to me. >> >> >>SMT can _not_ hurt performance if you only run one thread. Which I believe I >>clearly said. If you run on an SMT-aware O/S, and have a dual xeon with SMT >>on or off, you will get the _same_ results for any pair of applications you care >>to >>run if you only run two compute threads total, one will run on each physical CPU >>and there is no interaction. >> >>I don't see how SMT can hurt a program, unless it is using a lot of >>spinlocks/spinwaits and >>it doesn't follow the "fix" posted by Intel. A sloppy spinlock/spinwait can >>certainly hurt, >>but then the same program running two threads on a single CPU would do _badly_ >>as >>well, so it is a problem either way. > >You mean using all available processors. If it's one thread, other programs can >compete for limited resources such as execution bandwidth and trace cache space. > >-Matt Sure. I'm assuming _one_ "program" which means the trace cache will be common for all threads, generally. But if you run more threads than processors, whether you mean two threads and one processor or 5 threads and 4 processors, there is a problem when you have spinlock/spinwait code. Because the O/S nor the hardware can recognize that one is spinning while the non-running process would really do useful work.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.