Yikes. I will take that as "no, there is not any easy way to do that". I guess the fair thing to do in the mean time is to just start my strong scaling test from one node and go from there. I was seeing weird spikes in MPI_Reduce_scatter_block communication time when using c2-c8 anyway.<br>
<br>Jack<br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 6:56 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">
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>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 5, 2013 at 8:49 PM, Jack Poulson <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>> wrote:<br>
> So it turns out that running in c32 mode yields nearly a 2x speedup over c16<br>
> mode (one thread per process in both cases). Unfortunately this results in<br>
> another question.<br>
><br>
> My previous strong scaling test ran the same problem on 1, 2, 4, 8, 16, ...,<br>
> and 16384 processes, using c1 through c16 for the first tests and c16 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 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 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 GB/s<br>
>> would almost explain the 4x difference in performance (the >2x factor is<br>
>> *after* adjusting for the fact that BGQ's clock is 1.75x slower than my 2.8<br>
>> GHz desktop).<br>
>><br>
>> Also, the desktop results were not using any vendor libraries at all. 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 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 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 and<br>
>>> > reference implementations on my desktop, I would expect the BGQ timings<br>
>>> > to<br>
>>> > be a factor of 1.75 slower due to clockspeed differences. Would anyone<br>
>>> > have<br>
>>> > an explanation for the additional factor of more than 2x? My algorithm<br>
>>> > spends most of its time in sin/cos/sqrt evaluations and dgemm with 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>
</div></div></blockquote></div><br>