Re: Taking advantage of multi-processor architecture

Taking advantage of conncurrency ranges from highly trvial up to Halting-Problem difficult. It all depends on what your goals are.

You'll need to take a look at what your code does to the data. Lets say you've got a big loop that processes all the data. Does that loop's next iteration depend on the last one completeing? If not, you can split the data in half, then fork() the processes, giving each process half the data. Then get the data back together.

If this loop does depend on the last iteration completeing, your task may be difficult or impossible.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Comment on Re: Taking advantage of multi-processor architecture

Replies are listed 'Best First'.
Re^2: Taking advantage of multi-processor architecture by Fletch (Bishop) on Feb 11, 2005 at 14:16 UTC
Actually depending on how IO intensive the work is you may find that it's advantageous to split into more processes (or threads) than you have physical processors. If one of the workers becomes blocked waiting on IO the OS will be able to schedule another which can get useful work done while the first one's waiting for its data. One application of this trick is if you're using GNU `make` to tell it to run n+1 jobs on an n processor box (e.g. `make -j 3` on a dual CPU machine). While compiles are usually CPU bound, there's usually enough IO slack that it'll finish a little faster than if you'd just run `-j 2`.	[reply]

Replies are listed 'Best First'.

Re^2: Taking advantage of multi-processor architecture
by Fletch (Bishop) on Feb 11, 2005 at 14:16 UTC

Actually depending on how IO intensive the work is you may find that it's advantageous to split into more processes (or threads) than you have physical processors. If one of the workers becomes blocked waiting on IO the OS will be able to schedule another which can get useful work done while the first one's waiting for its data.

One application of this trick is if you're using GNU make to tell it to run n+1 jobs on an n processor box (e.g. make -j 3 on a dual CPU machine). While compiles are usually CPU bound, there's usually enough IO slack that it'll finish a little faster than if you'd just run -j 2.

[reply]