Objet : Developers list for StarPU
Archives de la liste
- From: Samuel Thibault <samuel.thibault@ens-lyon.org>
- To: Xavier Lacoste <xavier.lacoste@inria.fr>
- Cc: Mathieu Faverge <Mathieu.Faverge@inria.fr>, starpu-devel@lists.gforge.inria.fr, Pierre Ramet <ramet@labri.fr>
- Subject: Re: [Starpu-devel] memory overhead
- Date: Thu, 12 Dec 2013 17:38:51 +0100
- 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>
Hello,
Xavier Lacoste, le Fri 06 Dec 2013 14:53:10 +0100, a écrit :
> Have you go an idea of what could explain this overhead (+8% compared to
> PaStiX
> peak but much more if we don't take into account common data structures,
> which
> may be a more interesting metric....) and the huge number of calls to
> malloc().
Well, we have never spent time on optimizing allocations, so it is
generally not really surprising: we would have a few mallocs for each
task and each data transfer, for instance.
What is particular in your case, however, is that you have a performance
model with a lot of different sizes, which are recorded separately.
That's also one of the sources of overhead at the start of the
application, just to load the multiple-MB performance model file. It
would probably be useful to have a look at using a regression-based
performance model to avoid storing so many measurements.
Samuel
- [Starpu-devel] memory overhead, Xavier Lacoste, 06/12/2013
- Re: [Starpu-devel] memory overhead, Samuel Thibault, 12/12/2013
Archives gérées par MHonArc 2.6.19+.