views:

75

answers:

4

I am doing some expensive caluations right now. It is one programm, which I run several instances of at the same time. I am running them under linux on a machine with 4 cpus with 6 cores each. The cpus are Intel Xeon X5660, which support hyper thearting. (That's some insane hardware, huh?) Right now I am running 24 processes at once. Would it be better to run more, b/c of HT ?

+4  A: 

Don't think, measure

update

How long is a piece of string?

chibacity
@Chibacity: I agree that there's nothing like a good benchmark, but you also need to think (have some background knowledge) to design a good benchmark.
Eric J.
@Eric J: but no benchmark is a sufficiently accurate model of real operation, thus it is a wholly empirical determination. To mix metaphors: how much does a hen weigh?
msw
A: 

Without more information on your calculations it's going to be difficult, if not impossible, to give you a definitive answer. Even with this information there's a good chance any answer would be a guess.

You really need to do some timings/profiling of your solution. However, in the first instance you need to be able to configure the number of threads/processes you run at any one time.

Once you have this you can set up a scenario, run it and measure the result.

Repeat for different values and see which performs best.

ChrisF
+1  A: 

Measuring first is a good idea, but you can also consider following:

  • If the processes may block (particulary on IO), more of them is probably better.
  • If the processes do a lot of math most of their time, you may take advantage of HyperThreading with more processes.
  • On the other hand, if the processes have any shared state (memory or files), too much of them will increase contention and cache thrashing.
Viktor Svub
@Victor: In his case IO is probably light (writing away results now and then).
Eric J.
Thanks I don't have the time right now to write an extensive benchmark b/c I need to write a thesis. So you gave me somewhat of an idea.
Maarten
A: 

I was about to type almost exactly what Viktor wrote, so I have him +1 instead.

I would like to add that processes impose more overhead when there is a context switch than threads.

If your application architecture allows it, consider a single process with multiple threads or perhaps N processes with M threads each, where N and M are determined by benchmarking.

Eric J.