Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Worker Binding Problem

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Worker Binding Problem


Chronologique Discussions 
  • From: Samuel Thibault <samuel.thibault@inria.fr>
  • To: Berenger Bramas <berenger.bramas@inria.fr>
  • Cc: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] Worker Binding Problem
  • Date: Wed, 9 Sep 2015 12:00:59 +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>

Berenger Bramas, le Wed 09 Sep 2015 11:42:01 +0200, a écrit :
> With two threads it is OK:
> Test with OpenMP:
> [0]Done = 0.826635s
> [1]Done = 0.828059s
> Starpu:
> [0]Done = 0.813087s
> [1]Done = 0.826654s
>
> With three is start to be strange:
> Test with OpenMP:
> [0]Done = 0.825707s
> [2]Done = 0.826624s
> [1]Done = 0.827749s
> Starpu:
> [2]Done = 0.826262s
> [0]Done = 0.826653s
> [1]Done = 1.64255s

That's really odd indeed, there's no ground reason why threads
started by OpenMP and threads started by StarPU should behave
differently. I suspect it could be related with the stack allocation,
which StarPU currently just leaves to the OS. Could you check with
pthread_attr_getstack what the addresses and sizes look like in both
OpenMP and StarPU on your target machine? You could also try to call
alloca(16384) before calling alloca again to allocate the variable you
are working on, to make sure it gets allocated really locally (but there
may also be cache association conflicts, that's why addresses should
be checked too, in case the default pthread stack size happens to just
always bring conflicts while perhaps OpenMP uses smaller stacks by
default, in which case making the size in alloca(16384) vary according
to worker may avoid the conflict).

Samuel




Archives gérées par MHonArc 2.6.19+.

Haut de le page