Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Performance decline from StarPU 1.2.3 to 1.2.4

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Performance decline from StarPU 1.2.3 to 1.2.4


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@inria.fr>
  • To: Mirko Myllykoski <mirkom@cs.umu.se>
  • Cc: Starpu Devel <starpu-devel@lists.gforge.inria.fr>
  • Subject: Re: [Starpu-devel] Performance decline from StarPU 1.2.3 to 1.2.4
  • Date: Mon, 1 Oct 2018 15:59:08 +0200
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel/>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
  • Organization: I am not organized

Mirko Myllykoski, le jeu. 27 sept. 2018 20:21:14 +0200, a ecrit:
> On 2018-09-27 18:32, Samuel Thibault wrote:
> > I'm afraid the issue you are getting is that main memory registration
> > for CUDA DMA transfers is quite costly, and actually not worth the
> > cost for the asynchronism benefit. Setting --disable-cuda-memcpy-peer
> > by hand allows to disable asynchronism optimization and thus the data
> > registration. Ideally registration would be cheap, or cached, to avoid
> > the issue. If your temporary data pieces are small (less than 4MB), you
> > could try the attached patch which will make StarPU use a suballocator
> > not only for the CUDA memory but also for the main memory, which we
> > didn't feel would be useful, but perhaps would be.
>
> Compiling StarPU 1.2.4 with this patch (without --disable-cuda-memcpy-peer)
> fixes the problem.

Ok, that's the best option: you keep memcpy-peer which avoids spurious
synchronization, but avoid paying the corresponding cost all the
time. I have commited a more elaborated version of the the patch to all
branches.

Thanks!
Samuel




Archives gérées par MHonArc 2.6.19+.

Haut de le page