Hi all.<br><br>I usually just keep on looking on this list, but this discussion really called my attention.<br><br>Could someone clarify a bit better *why* would openMP be such a bad performer in comparison to MPI?<br><br>

Moreover, concerning you tests  Dr. Siegert, could you please show us a bit more? I mean for example the scalling you observed throw increasing the number of cores. I really don't immeadiatelly understand how openMP can perform so worst than mpi on a smp machine, given the fact that not having to communicate with the other 31 cores (on cpmd case, all the huge matrixes that should be exchanged) should at least make things a bit easier.

<br><br>But all that from the eyes and view of an young "amadorist".  ;)<br><br>Thanks a lot in advance,<br><br>Jones<br><br><div class="gmail_quote">On Dec 8, 2007 5:55 PM, Martin Siegert <<a href="mailto:siegert@sfu.ca">

siegert@sfu.ca</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Over the last months I have done quite a bit of benchmarking of

applications. One of the aspects we are interested in is the performance of applications that are available in MPI, OpenMP and hybrid versions. So far we looked at WRF and CPMD; we'll probably look at POP as well.

<br><br>MPI vs. OpenMP on a SMP (64 core Power5):<br>walltime for cpmd benchmark on 32 cores:<br>MPI: 93.13s   OpenMP: 446.86s<br><br>Results for WRF on the same platform are similar.<br>In short: the performance of OpenMP code isn't even close to that of the

<br>MPI code.<br><br>We also looked at the hybrid version of these codes on clusters.<br>The difference in run times are in the 1% range - less than the<br>accuracy of the measurement.<br><br>Thus, if you have the choice, why would you even look at anything other

<br>than MPI? Even if the programming effort for OpenMP is lower,<br>the performance penalty is huge.<br><br>That's my conclusion drawn from the cases we've looked at.<br>If anybody knows of applications where the OpenMP performance comes close

<br>to the MPI performance and of applications where the hybrid performance<br>is significantly better than the pure MPI performance, then I would<br>love to hear from you. Thanks!<br><br>Cheers,<br>Martin<br><br>--<br>Martin Siegert

<br>Head, Research Computing<br>WestGrid Site Lead<br>Academic Computing Services                phone: 778 782-4691<br>Simon Fraser University                    fax:   778 782-4242<br>Burnaby, British Columbia                  email: 

<a href="mailto:siegert@sfu.ca">siegert@sfu.ca</a><br>Canada  V5A 1S6<br><br>On Fri, Dec 07, 2007 at 10:56:14PM -0600, Gerry Creager wrote:<br>> WRF has been under development for 10 years.  It's got an OpenMP flavor,

<br>> an MPI flavor and a hybrid one.  We still don't have all the bugs worked<br>> out of the hybrid so that it can handle large, high resolution domains<br>> without being slower than the MPI version.  And, yeah, the OpenMP geeks

<br>> working on this... and the MPI folks, are good.<br>><br>> Hybrid isn't easy and isn't always foolproof.  And, as another thought,<br>> OpenMP isn't always the best solution to the problem.<br>

><br>> gerry<br>><br>> <a href="mailto:richard.walsh@comcast.net">richard.walsh@comcast.net</a> wrote:<br>> > -------------- Original message ----------------------<br>> >From: Toon Knapen <<a href="mailto:toon.knapen@gmail.com">

toon.knapen@gmail.com</a>> > >>Greg Lindahl wrote: > >>>In real life (i.e. not HPC), everyone uses message passing between > >>>nodes.  So I don't see what you're getting at.

<br>> >>><br>> >>Many on this list suggest that using multiple MPI-processes on one and<br>> >>the same node is superior to MT approaches IIUC. However I have the<br>> >>impression that almost the whole industry is looking into MT to benefit

<br>> >>from multi-core without even considering message-passing. Why is that so?<br>> ><br>> >I think what Greg and others are really saying is that if you have to use<br>> >a distributed memory

<br>> >model (MPI) as a first order response to meet your scalability<br>> >requirements, then<br>> >the extra coding effort and complexity required to create a hybrid code<br>> >may not be<br>> >a good performance return on your investment.  If on the other hand you

<br>> >only<br>> >need to scale within a singe SMP node (with cores and sockets on a single<br>> >board growing in number, this returns more performance than in the past),<br>> >then you<br>> >may be able to avoid using MPI and chose a simpler model like OpenMP.  If

<br>> >you<br>> >have already written an efficient MPI code,  then (with some exceptions)<br>> >the performance-gain divided by the hybrid coding-effort may seem small.<br>> ><br>> >Development in an SMP environment is easier.  I know of a number of sights

<br>> >that work this way.  The experienced algorithm folks work up the code in<br>> >OpenMP on say an SGI Altix or Power6 SMP, then they get a dedicated MPI<br>> >coding expert to convert it later for scalable production operation on a

> >cluster. > >In this situation, they do end up with hybrid versions in some cases.  In > >non-HPC > >or smaller workgroup contexts your production code may not need to be > >converted.

<br>> ><br>> >Cheers,<br>> ><br>> >rbw<br>> ><br>> >--<br>> ><br>> >"Making predictions is hard, especially about the future."<br>> ><br>> >Niels Bohr<br>

> ><br>> >--<br>> ><br>> >Richard Walsh<br>> >Thrashing River Consulting--<br>> >5605 Alameda St.<br>> >Shoreview, MN 55126<br>> ><br>> >Phone #: 612-382-4620<br>> >

<br>> >_______________________________________________<br>> >Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>> >To change your subscription (digest mode or unsubscribe) visit

<br>> ><a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>><br>> --<br>> Gerry Creager -- <a href="mailto:gerry.creager@tamu.edu">

gerry.creager@tamu.edu</a><br>> Texas Mesonet -- AATLT, Texas A&M University<br>> Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983<br>> Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843

<br>> _______________________________________________<br>> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>> To change your subscription (digest mode or unsubscribe) visit<br>

> <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br><br>--<br>Martin Siegert<br>Head, Research Computing<br>WestGrid Site Lead<br>Academic Computing Services                phone: 778 782-4691

<br>Simon Fraser University                    fax:   778 782-4242<br>Burnaby, British Columbia                  email: <a href="mailto:siegert@sfu.ca">siegert@sfu.ca</a><br>Canada  V5A 1S6<br>_______________________________________________

<br>Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">

http://www.beowulf.org/mailman/listinfo/beowulf</a><br></blockquote></div><br>