[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Some questions about runtime model,sdm
|
Great questions.
On Sep 3, 2006, at 10:03 PM, yang ke wrote:
Hi,all
I ' ve just managed to launch a parallel job across multiple nodes
by a small change in orte_server.c. :-)
I know that our v1.1 is coming in the near weeks, and it has been
made great change from v1.0, still I have some questions, hope it
will be helpful.
1. About Runtime Model
Nathan, I think asychronous updating will be better for the runtime
model esp. for job launching. Currently we use a <RUN ...> command
follwed by a <GETPATTR ...> command to BLOCKLY launch a job and
then to construct its job structure, which often makes the user
staring at a Progress Bar for a boringly long time to go on
operate. The runtime can quickly return a job id, but other
attributes,like process pid(real pid),would not be returned soon
(maybe after all tasks launched). We can make better use of this
knowledge for finer monitoring of job status: process status.
First construct the job structure on higher layer model
(java),then LISTEN to lower layer(such as slurm or orte) to return
attribute events.The lower layer should have good sense of process
attributes and status changes, and report process attributes and
status changes timely. Anytime there occurs some error,we can find
out which process fails instead of a whole job error.
I have tested that on SLURM,but I doesn't know if ORTE
supports such process status report.Will we get such changes?
See Nathans/my reply in separate email.
2. About Scalable Debugger Manager
recently I study a paper-
"Extending a traditional debugger to debug massively parallel
applications",Susanne M.Balle,Journal of Parallel and Distributed
Computing 64(2004) 617-628
It suggests some good practice on improving debugging preformance.
PS: Greg's "architeture of a parallel relative debugger" is listed
in the References. :-)
I looked into the source of sdm, and I am afraid sdm client may be
a bottleneck when issuing debug instructions to servers and
receiving debug responses from servers, for it has to finish a set
of processes one by one. If we are to debug 10K processes, sdm
client will be busy dispatching a deubg instruction and will be
buried in a flood of reponses. Fortunately, implementation of sdm
in MPI way fills me with courage. We can dispatch debug
instructions in a way similar with MPI_BCAST() and aggregate debug
responses with MPI_GATHER(). Alternately, we can adopt some idea
from Susanne's paper,for example,we use a tree-like network to
dispatch and aggregate.
Again,from that paper, I find out there are 3 types of debugging
messages:
Type1------Identical outputs from each of the debugger/aggregators
Type2------Identical outputs apart from containing different numbers
Type3------Widely differing outputs
sdm has made Type 1 aggregations,using hash table(so cool!),but
Type 2 still needs to be aggregated,so I hope future sdm work out
some way to aggregate Type 2 messages.
I recently checked in a change to the SDM that does pretty much what
you describe. I allocate task ID's based on the optimal broadcast
strategy, then each MPI process sends to a small set of processes
rather than one controller process sending to everyone. So for
example, if there are 10 processes (task ID's 0-9), 0 would send to
(1, 2, 4, 8), 1 would send to (3, 5, 9), 2 to 6, and 3 to 7.
For the return journey, I aggregate messages at each of the
intermediate processes as they propagate back to the root process.
This substantially reduces the amount of traffic in the network. Of
course, it is always possible for every message to be different, in
which case this approach is no better than the simply passing each
message back. However in practice this seems to rarely occur.
Take a look at src/client/client_svr.c in the SDM project which is
where most of this is implemented. Comments appreciated.
3. About Open MP debugging support
PTP now supports MPI debugging well.Does future PTP support Open MP
debugging? If so, how?
Can we still use gdb?
By Open MP debugging, I assume that you really mean a threaded model?
The SDM is really designed for MPI debugging, so for threaded models
and other more complex architectures (for example the Cell), I think
the SDM will need to be replaced with different backends. I don't see
any reason why any debugger with thread support (such as dbx)
couldn't be used to support OpenMP debugging. The Eclipse UI portion
of the debugger should (hopefully) not need to be changed much,
though we might want to extend the parallel debug view to support
threads as well as processes. The debugger API provides a bitmask in
each command to specify which processes the command applies to, so it
should work equally well for threads.
If gdb thread support is good enough then it should work too.
Hope to see ptp v1.1 soon, and good luck to you.
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone
call rates.
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
