FYI, on 1024 nodes in c64 mode MPI_Reduce_scatter_block was noticeably faster in my application than MPI_Allreduce composed with memcpy (the payloads were double-precision floating-point data). I should mention that each MPI_Allreduce call took place over a different subcommunicator of four processes, and that the whole algorithm only sent log p messages from each of the p=65,536 processes.<br>
<br>Jack<br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 7:32 PM, Jeff Hammond <span dir="ltr"><<a href="mailto:jhammond@alcf.anl.gov" target="_blank">jhammond@alcf.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
MARPN is about 100 LOC and it will take me about 3 minutes to hack<br>
c2-on-1core for you but I'm not going to do it tonight.<br>
<br>
Calling MPI_Comm_split with color= Kernel_ProcessorCoreID() in c32<br>
mode and use the resulting comm with color=0 will give you the same<br>
behavior if your app can be initialized with any subcomm.  If you're<br>
using MPI_COMM_WORLD directly, MPI zealots everywhere (or maybe just<br>
Argonne) will wag their finger at you :-)<br>
<br>
MPI_Reduce_scatter_block sucks on BG and you should continue to use<br>
MPI_Allreduce+memcpy as I suggested on BGP.  See attached showing<br>
allreduce > reduce and know that, at least in some cases (e.g.<br>
MPI_COMM_WORLD), reduce >> reduce_scatter.  Also double > integer, but<br>
I assume you are using doubles.<br>
<br>
I can send you my complete collective test results if you care.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 5, 2013 at 9:08 PM, Jack Poulson <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>> wrote:<br>
> Yikes. I will take that as "no, there is not any easy way to do that". I<br>
> guess the fair thing to do in the mean time is to just start my strong<br>
> scaling test from one node and go from there. I was seeing weird spikes in<br>
> MPI_Reduce_scatter_block communication time when using c2-c8 anyway.<br>
><br>
> Jack<br>
><br>
><br>
> On Tue, Mar 5, 2013 at 6:56 PM, Jeff Hammond <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>> wrote:<br>
>><br>
>> if you are running MPI-only, c32 is the bare minimum requirement for<br>
>> saturating issue rate and this is only true in the ridiculous case<br>
>> where you have a perfect 50-50 mix of ALU and FPU ops.  Most codes<br>
>> need 3 hw threads per core to saturate instruction rate but since c48<br>
>> doesn't exist except in my universe<br>
>> (<a href="https://wiki.alcf.anl.gov/parts/index.php/MARPN" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/MARPN</a>), many codes resort<br>
>> to c64 solely because of instruction issue rate issues (and their<br>
>> inability to thread).<br>
>><br>
>> However, if your code runs faster with c32 than c16, it is not<br>
>> bandwidth-limited, because BGQ hits the bandwidth limit with 1 thread<br>
>> per core without any vector load/store (per Bob Walkup's talk at<br>
>> MiraCon today, if nothing else).<br>
>><br>
>> If you want to run 2 MPI ranks on the same core, I can hack MARPN to<br>
>> give you this via c32 and a fake world or you can implement it<br>
>> yourself manually using the approach that MARPN uses, which is to<br>
>> query the hardware location of ranks and MPI_Comm_split off a comm<br>
>> that has two ranks on the same core.<br>
>><br>
>> Best,<br>
>><br>
>> Jeff<br>
>><br>
>> On Tue, Mar 5, 2013 at 8:49 PM, Jack Poulson <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>><br>
>> wrote:<br>
>> > So it turns out that running in c32 mode yields nearly a 2x speedup over<br>
>> > c16<br>
>> > mode (one thread per process in both cases). Unfortunately this results<br>
>> > in<br>
>> > another question.<br>
>> ><br>
>> > My previous strong scaling test ran the same problem on 1, 2, 4, 8, 16,<br>
>> > ...,<br>
>> > and 16384 processes, using c1 through c16 for the first tests and c16<br>
>> > for<br>
>> > the rest.<br>
>> ><br>
>> > Since my code apparently benefits from using 2 MPI processes per core, I<br>
>> > would like to run the equivalent tests. However, I'm not certain how to<br>
>> > launch, for instance, two MPI processes on one node and have them both<br>
>> > run<br>
>> > on the same core. I could run on one node with c2 mode, but I think that<br>
>> > this would be a bit dishonest, as I suspect that it would really make<br>
>> > use of<br>
>> > two cores.<br>
>> ><br>
>> > Any ideas how to do this?<br>
>> ><br>
>> > Jack<br>
>> ><br>
>> > On Tue, Mar 5, 2013 at 12:27 PM, Jack Poulson <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> The code is almost certainly memory bandwidth limited, and 25 vs. 80<br>
>> >> GB/s<br>
>> >> would almost explain the 4x difference in performance (the >2x factor<br>
>> >> is<br>
>> >> *after* adjusting for the fact that BGQ's clock is 1.75x slower than my<br>
>> >> 2.8<br>
>> >> GHz desktop).<br>
>> >><br>
>> >> Also, the desktop results were not using any vendor libraries at all.<br>
>> >> Just<br>
>> >> g++-4.7 with Ubuntu's stock math libraries.<br>
>> >><br>
>> >> Jack<br>
>> >><br>
>> >> On Tue, Mar 5, 2013 at 11:17 AM, Jeff Hammond <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> The BGQ core is fully in-order with a instruction short pipeline and<br>
>> >>> single-issue per hardware thread and dual-issue per core provided the<br>
>> >>> ALU and FPU instructions come from two different hardware threads.<br>
>> >>><br>
>> >>> A Xeon core is out-of-order with deep pipelines and can decode up to<br>
>> >>> four instructions per cycles.  The Internet refuses to tell me for<br>
>> >>> certain if this means that it is proper to say a Sandy Bridge is<br>
>> >>> quad-issue, but it seems that way.<br>
>> >>><br>
>> >>> The memory bandwidth measured by STREAM may anywhere from 50% to 200%<br>
>> >>> higher on Intel Xeon than BGQ.  BGQ does 25-30 GB/s whereas as a late<br>
>> >>> model Xeon can do 80 GB/s.  If your code is BW-limited, it isn't<br>
>> >>> surprising if a Xeon is ~2x faster.<br>
>> >>><br>
>> >>> In addition to normalizing w.r.t. clock-rate, you should normalize<br>
>> >>> w.r.t. watts per socket.  BGQ uses 60-70W per node unless you're<br>
>> >>> running HPL.  An Intel Xeon uses twice that just for the socket, not<br>
>> >>> including DRAM, IO, etc.<br>
>> >>><br>
>> >>> Note also that the BGQ QPX vector ISA is much more restrictive than<br>
>> >>> AVX w.r.t. alignment.  Additionally, the Intel compilers are way<br>
>> >>> better than IBM XL at vectorizing.<br>
>> >>><br>
>> >>> Finally, ESSL sucks compared to MKL.  That alone may be worth 2x in<br>
>> >>> LAPACK-intensive applications.<br>
>> >>><br>
>> >>> Jeff<br>
>> >>><br>
>> >>> On Tue, Mar 5, 2013 at 12:59 PM, Jack Poulson <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > Hello,<br>
>> >>> ><br>
>> >>> > I have benchmarking my code on Vesta and, while I have been seeing<br>
>> >>> > excellent<br>
>> >>> > strong scaling, I am a little underwhelmed by the wall-clock timings<br>
>> >>> > relative to my desktop (Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz). I<br>
>> >>> > am<br>
>> >>> > using the newest version of bgclang++ on Vesta, and g++-4.7.2 on my<br>
>> >>> > desktop<br>
>> >>> > (both used -O3), and I am seeing roughly a factor of four difference<br>
>> >>> > in<br>
>> >>> > performance on the same number of cores.<br>
>> >>> ><br>
>> >>> > If I ignored the fact that I am using a vendor math library on BGQ<br>
>> >>> > and<br>
>> >>> > reference implementations on my desktop, I would expect the BGQ<br>
>> >>> > timings<br>
>> >>> > to<br>
>> >>> > be a factor of 1.75 slower due to clockspeed differences. Would<br>
>> >>> > anyone<br>
>> >>> > have<br>
>> >>> > an explanation for the additional factor of more than 2x? My<br>
>> >>> > algorithm<br>
>> >>> > spends most of its time in sin/cos/sqrt evaluations and dgemm with<br>
>> >>> > two<br>
>> >>> > right-hand sides.<br>
>> >>> ><br>
>> >>> > Thanks,<br>
>> >>> > Jack<br>
>> >>> ><br>
>> >>> > _______________________________________________<br>
>> >>> > llvm-bgq-discuss mailing list<br>
>> >>> > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
>> >>> > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
>> >>> ><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> Jeff Hammond<br>
>> >>> Argonne Leadership Computing Facility<br>
>> >>> University of Chicago Computation Institute<br>
>> >>> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381" value="+16302525381">(630) 252-5381</a><br>
>> >>> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
>> >>> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
>> >><br>
>> >><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jeff Hammond<br>
>> Argonne Leadership Computing Facility<br>
>> University of Chicago Computation Institute<br>
>> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381" value="+16302525381">(630) 252-5381</a><br>
>> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
>> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Jeff Hammond<br>
Argonne Leadership Computing Facility<br>
University of Chicago Computation Institute<br>
<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381" value="+16302525381">(630) 252-5381</a><br>
<a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
<a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
</div></div></blockquote></div><br>