[SimGrid-user] Use of SMPI_SHARED_MALLOC

Martin Quinson martin.quinson at loria.fr
Mon Mar 25 21:57:47 CET 2013


Hello,

I just updated the SMPI documentation. The new version is available
here:
http://simgrid.gforge.inria.fr/simgrid/3.10/doc/group__SMPI__API.html

Could you please tell me if this is sufficient for you, or how I could
further improve the page?

Thanks for your feedback,
Mt.


On Mon, Mar 25, 2013 at 05:05:14PM +0000, RAMAMONJISOA, CHARLES EMILE wrote:
> Hello,
> 
> Many thanks for your mail. It points me out how this macro works.
> 
> Actually, SMPI_SHARED_MALLOC can reduce dramatically the memory footprint when executing a distributed application under some conditions. That is because instead of allocating for each contributing process the needed memory space, only one instance of the later is allocated and ALL the processes will share and address this segment. But, depending on the algorithm, the macro can be useless and the result is irrelevant. Testing it with an algorithm like Jacobi iterative method where the convergence is obtained only with computing and exchanging  "border values" between the participating processes, sharing the memory space will make the algorithm unpredictable and most of the time, it did not converge. That is what is called "data dependent application". In the other hand, use of the macro may bring some good results with an distributed algorithm working like a multithreaded application where all processes (threads in this case) share the same memory space.
> Note that we got the same behavior with SMPI_SAMPLE_LOCAL or SMPI_SAMPLE_GLOBAL macros..
> 
> Thank you
> RCE
> 
> 
> -----Message d'origine-----
> De : simgrid-user-bounces at lists.gforge.inria.fr [mailto:simgrid-user-bounces at lists.gforge.inria.fr] De la part de Martin Quinson
> Envoyé : vendredi 22 mars 2013 22:12
> À : simgrid-user at lists.gforge.inria.fr
> Objet : Re: [SimGrid-user] Use of SMPI_SHARED_MALLOC
> 
> 
> On Fri, Mar 22, 2013 at 02:22:08PM +0000, RAMAMONJISOA, CHARLES EMILE wrote:
> > Hi Martin,
> > 
> > Thank you for your reply. 
> > I've checked the example in dt.c as you indicated. As you said, there is not so much documentation on the use of these macros.
> > In fact, I'd like to evaluate the gain obtained in using them in a given platform in comparing the results with the traditional malloc instruction. 
> > 
> > In addition of you are saying, I red from your paper ("Single Node On-Line Simulation of MPI Applications with SMPI") where you stated that the use of these macros is efficient only for "non data dependant application". Perhaps, it is my case (that is the use of the macros is irrelevant)  because I have a test program using the Jacobi iterative method with a "big" matrix. 
> > 
> > So my question is : can these macros help to reduce the memory footprint when running such a program ? 
> 
> And the answer is "yes", of course. 
> 
> The purpose of these macro is that the same line malloc on each process will point to the exact same memory area. So if you have a malloc of 2M and you have 16 processes, this macro will change your memory consumption from 2M*16 to 2M only. Only one block for all processes.
> 
> If your program is ok with a block containing garbage value because all processes write and read to the same place without any kind of coordination, then this macro can dramatically shrink your memory consumption.
> 
> Actually, the behavior of this macro is so trivially stupid that I'm not sure of what we could write to help the potential users. If you could write a little paragraph by reusing parts of what I said and what you understand from it, it would be very welcomed, and I'd use it as an actual documentation.
> 
> Bye, Mt.
> 
> --
> Computers make very fast, very accurate mistakes.
> 
> _______________________________________________
> Simgrid-user mailing list
> Simgrid-user at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/simgrid-user

-- 
If you do not expect the unexpected, you will not find it.   -- Heraclitus                                          



More information about the Simgrid-user mailing list