[mpiwg-rma] Short question on the ccNUMA memory reality

[William Gropp]

Question 1 is hard to answer.  First, as it came out in my output, the first and last “print x” straddle the two ranks, so I’m not sure what that means.  But the following is valid for the compiler:

On rank 0.  Since x = val_2 follows x = val_1 with no intervening use of x, a good optimizing compiler may eliminate the store to x with val_1 as unnecessary.

On rank 1,  Since x is never assigned in this block, a compiler is permitted to make a copy in a register (which would have the value x had before this block was entered) and than print that value each time print is called  (e.g., it could build the call stack in memory, and just pass that unchanged call stack to print for each call).

And don’t forget - there’s a difference between when the print completes on a process/thread and when the output appears - the system could flush all print output from rank 1 before any print output from rank 0 appears.

If x is volatile, then the compiler isn’t free to do the second (save x and never load it again).  

Bill

William Gropp
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign





On Aug 5, 2014, at 2:53 AM, Balaji, Pavan <balaji at anl.gov> wrote:

> Huh?
> 
>> 1. Question (sequential consistency on one location):
>> ------------
>> 
>> Do I understand correctly that in the following patter
>> on a shared Memory or a ccNUM shared memory
>> 
>> rank 0     rank 1
>>        print x
>> x=val_1    print x
>> x=val_2    print x
>>        print x
>> 
>> the print statements can print only in the following
>> sequence 
>> - some times the previous value
>> - some times val_1
>> - and after some time val_2 and it then stays to print val_2
>> 
>> and that it can never be that a sequence with val_2 before val_1 
>> can be produced, i.e.,
>> old_val
>> val_2
>> val_1
>> val_2
>> is impossible.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20140805/02ebc409/attachment-0001.html>