in reply to Re^2: Parallelization of heterogenous (runs itself Fortran executables) code
in thread Parallelization of heterogenous (runs itself Fortran executables) code

It is all moot if one (or more) of the threads is hogging I/O.

Update 1: while I make a point not to comment on downmodded posts of mine, I have to say that i/o contention among threads is a SERIOUS issue - even on an SMP machine that has multiple cores/cpus. So put that in your pipe and smoke it.

Update 2: I've been asked by BrowserUk to clarify, so here we go. As it was pointed out, threading simply divides time among related processes.

On a single CPU system, the issue of a thread hogging i/o is indistinguishable from a simple blocking thread - sibling threads simply won't get a chance to execute until the thread that is executing finishes with its reads/writes.

On shared memory (multi-core, SMP), the situation changes. Multiple threads may be executing, but if some small subset of the threads are engaging in heavy i/o, things will come screeching to a crawl. My point is that there is an additional contention for i/o bandwidth, and unless there is a high performance disk subsystem available to your threads, simply thowing more CPUs at it won't make a lick of difference - and could in fact make your performance a lot worse than just running the code serially.

We don't know what the OP's code is doing. If it is reading and writing a lot of data, this could have a significant impact on the performance of the threads.
  • Comment on Re^3: Parallelization of heterogenous (runs itself Fortran executables) code

Replies are listed 'Best First'.
Re^4: Parallelization of heterogenous (runs itself Fortran executables) code
by BrowserUk (Patriarch) on Nov 20, 2007 at 23:58 UTC