On Thu, 6 Apr 2006, Jun She wrote:
Does MPI support Hyper-Threading CPU? The CPU in my PC is P4 2.6C which is a Hyper-Threading CPU. I try -np 2. But I failed.
Let me clear up a couple of confusions. What most MPI implementations do is that they launch a number of processes as indicated by -np. It is up to your operating system to decide how to schedule those processes and what CPUs to execute them on.
So, for example, it is certainly possible to use -np 100 when you only have 1 CPU: your operating system should be perfectly capable of scheduling 100 processes on your CPU. Of course, you shouldn't get any computational speedup since the CPU is just being rapidly switched from one process to the next instead of executing them in parallel.
Whether MPI can use hyperthreading depends on whether your operating system supports it. Recent versions of the Linux kernel, for example, support hyperthreading CPUs, which it treats as "virtual" extra CPUs. You'll almost certainly want to use a 2.6.x version of the Linux kernel if you have multiple hyperthreaded CPUs, however; if I remember correctly 2.6.x does a better job than 2.4.x of scheduling a mix of physical and virtual CPUs.
However, I suspect that you're unlikely to get much if any speedup from hyperthreading.
First, realize that multiprocessing is not free: there is some communications overhead that is added when you try to parallelize a program like Meep...unless the computational parallelism outweighs this extra communications overhead, the parallel program will actually be *slower* than the serial one. This means, for example, that even if you really have two or more physical CPUs you won't be able to benefit from parallelization until the problem is sufficiently large!
(For example, the problems in the tests/bench.dac program may not be large enough to efficiently parallelize...)
Second, realize that hyperthreading is sharing a single CPU between two processes. The potential benefit from hyperthreading comes mainly from masking memory latency and other sources of pipeline stalls - while one process is waiting for something to be loaded from memory, the other process can be executing some instruction. (This was an idea originated by Burton Smith in the 1980's.) Intel claims that you can get speedups of ~30% from this (not a factor of two), but in practice I've found that matters are often worse e.g. because the two processes are competing for the same cache memory. I suspect that the benefit of hyperthreading may not be enough to outweigh the communications overhead in most cases.
I haven't done extensive benchmarking, though, so your mileage may vary. Cordially, Steven G. Johnson _______________________________________________ meep-discuss mailing list [email protected] http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
