Hi Robert,
On 02/03/2017 21:12, Robert Sawko wrote:
> Great... Yes, I didn't estimate the degrees of freedom for this. Trying to be
> too quick. I've uploaded the sd7003 case. I added the residual printing and I
> can already see it produced 2x speedup going from 1 to 2 nodes. I am doing a
> full test now.
>
>
> I have several related questions and comments:
> 1) what is [backend] rank-allocator = linear? Does this not conflict with MPI
> options e.g. -rank-by from OMPI or binding policy of MVAPICH. This is
> significant for me as I have two GPUs per socket and 64 hardware threads
> per socket. I don't want 4 process to run on the first socket alone.
So the rank allocator decides how partitions in the mesh should be
mapped onto MPI ranks. The linear allocator is exactly what you would
expect: the first MPI rank gets the first partition, and so on and so
forth. There is also a random allocator. Having four processes on one
socket is probably okay; I doubt you would notice much of a difference
compared to an even split. When running with the CUDA backend PyFR is
entirely single threaded and offloads all relevant computation to the
GPU. We also work hard to mask latencies for host-to-device transfers
so even sub-optimal assignments usually work out.
> I print my bindings in MVAPICH and it looks ok, but I want to double check
> that python is not doing something else under the hood.
>
> 2) What is the rough DoF estimate for the strong scaling limit you observed
> with PyFR?
That is a good question and one which I do not have much of a feel for.
I would say that you want on the order of a thousand *elements* per GPU
and below that you may being to experience a flattening out of your
strong scaling curve.
> 3) At the moment I am setting 4 MPI proc per node as I've got 4 GPUs, but I
> assume there's nothing to stop me from using more. Has anyone looked at
> optimal ratio of MPI processes to GPUs?
One MPI rank per GPU will be optimal. Anything else will just introduce
extra overheads.
Regards, Freddie.