<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
Hi Marc-Andre,
<div><br>
</div>
<div>Thank you for the replay.
<div><br>
</div>
<div>RE:</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">We analyze on the same scale as the measurement, thus we have one<br>
thread per thread-local trace. Each thread processes its own <br>
thread-local trace. When encountering a communication event, it <br>
re-enacts this communication using the recorded communication <br>
parameters (rank, tag, comm). A send event leads to an issued <br>
send, a receive event leads to an issued receive.<br>
</blockquote>
<br>
(1) Replaying receive events Papers about “parallel replay (or <br>
record-and-replay)” uses (rank, rag, comm) for correct replay of <br>
message receive orders. Unfortunately, (rank, tag, comm) cannot <br>
replay message receive orders even in MPI_THREAD_SINGLE ** In <br>
general ** (Of course, it may work in particular case). You need<br>
to record (rank, message_id_number), and actually (tag, comm) does<br>
not work for this purpose. The details is described in Section 3.1<br>
of this paper ( <a href="http://dl.acm.org/citation.cfm?id=2807642">http://dl.acm.org/citation.cfm?id=2807642</a> ).<br>
</blockquote>
<br>
I think we (Scalasca) does not have requirements as strict as the ones<br>
outlined in the paper. We need only to ensure that the same<br>
send/receive pairs also exchange data during the analysis (ideal case)<br>
or that we can at least detect a mismatch (in case of logically<br>
concurrent messages) and fix it locally, by exchanging the mixed up<br>
message payloads.<br>
<br>
If I understand section 3.1 correctly, the problem with out-of-order<br>
receives (Figure 3) does not pose a problem in our case, as we only<br>
care that msg1 is matched by req1 and msg2 is matched by req2, both in<br>
during measurement and replay. MPI ordering semantics should take care<br>
of that.<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>If I correctly understand, you only need to ensure the same send/receive pairs, </div>
<div>and you ** DO NOT ** care about the message receive orders. </div>
<div><br>
</div>
<div>However, if you do not replay the message receive orders, </div>
<div>you cannot correctly replay the same send/receive pairs </div>
<div>because send destinations can change by message receive orders.</div>
<div><br>
</div>
<div>For example, an application, e.g., N-body, changes send destinations according to some numerical result (X).</div>
<div>In floating-point arithmetic, (a+b)+c is not necessary equal to a+(b+c). </div>
<div>So the numerical result (X=a+b+c) can change according to message receive orders(a, b & c).</div>
<div>It results in non-deterministic send destinations, thereby, non-deterministic send/recv pairs.</div>
<div><br>
</div>
<div>I know it’s really corner case. </div>
<div>So if detecting mismatch is find at least, this problem would be negligible for you.</div>
<div><br>
</div>
<div>Kento</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div align="left"><span lang="EN-US" style="font-size: 10pt; color: rgb(31, 73, 125);">
<hr width="100%" align="left" size="2">
</span></div>
<b style="color: rgb(51, 102, 255);">Kento Sato</b> <span style="color: rgb(102, 102, 102);">| Center for Applied Scientific Computing (CASC) | Lawrence Livermore National Laboratory (LLNL) | </span><a href="http://people.llnl.gov/sato5">http://people.llnl.gov/sato5</a> <span style="color: rgb(102, 102, 102);">|</span></div>
<div><span style="color: rgb(102, 102, 102);"><br>
</span></div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</body>
</html>