Ross Walker wrote:
>Dear Robert,
>
>Thus I agree with you that Hyperthreading, at least on multiprocessor
>machines should be switched off. I don't know whether this issue is unique
>to the types of simulations we run, I suspect not. Thus I think anything
>that uses multiple threads that do the same thing will suffer when run on a
>multiprocessor (>1 real cpu) hyperthreaded machine. Hyperthreading is
>probably great for SQL database searches but for our types of calculations
>it is fundamentally broken. I think Intel's implementation of hyperthreading
>was rushed for commercial reasons and hence is not very efficient. It is
>fine for single cpu machines (although you should still run jobs as 1 proc
>per machine in this environment) but as soon as you go above that the
>processor scheduling goes haywire and you actually end up loosing out.
>
>So advice to everyone "If you have a multi-cpu machine with hyperthreading,
>TURN IT OFF"
>
>
This advice is not substantiated. I have run PMEMD on dual proc,
hyperthreaded machines with mpirun -np 4, and see a minor speedup relative
to -np 2. There is certainly no loss of performance on my molecular
system. It's probably system-dependent. I used ch_p4, not ch_shmem.
When my department finally gets around
to approving AMBER 8, I will be re-running all of these simulation to
get up-to-date results.
Furthermore, Linux kernel 2.6 has significantly better hyperthread
support, it would be very interesting to use processor pinning (which
should also be available in
RH9 as well) or just let the regular HT-aware scheduler do its thing.
Dave
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Fri Apr 09 2004 - 23:53:00 PDT
