[mpich-discuss] Advice on thread support
nrosner at gmail.com
Wed Jan 7 14:05:19 CST 2009
Thank you Larry, that was an interesting comment. Yes, the complexity
issue is a relevant one, which is why i'm
My motivation to consider threads wasn't really to improve
message-passing performance. Our application is loosely coupled: the
tasks (i.e computations carried out by each process) are rather long,
usually between the order of tens of seconds and that of several
minutes, and most messages are exchanged in between (not during) such
tasks. Thus, the rate of messages over time is relatively low, and
short delays (e.g. a 10% increase in msg latency) tend to become
negligible compared to the computations that follow.
However, some of our messages are large (payload around 1 MB per msg,
or even more, I'd say 5 MB in the worst cases), so if the kind of
performance problems you had in mind are throughput-related (as
opposed to just latency), I'd be interested in any further details you
can think of (or pointers to such info).
I'd like to explain why I was considering threads in the first place,
but I'm having trouble doing so without context. I think I'll try to
write a short summary (goal of program, current problem, my ideas
about possible solutions) and post another message to the list.
> I have not heard that hybrid codes (part threaded and part MPI) have any
> performance advantage over pure MPI. I have heard that they have substantial
> complexity disadvantages. Besides, it seems to be necessary to slow down
> MPI in order to add the locking to make THREAD_MULTIPLE work, which is an
> additional performance problem charged against the hybrid approach.
More information about the mpich-discuss