Re: [Starpu-devel] question on CPU/GPU tasks distribution

["philippe.helluy@unistra.fr" <philippe.helluy@unistra.fr>]

The difference is a factor of two (400 s instead of 200 s for the GPU 
only). The amount of memory used for the data is (approximately) of 3 GB.

I will try your suggestions and tell you.

Best regards

ph

Le 31/08/2018 à 11:35, Samuel Thibault a écrit :
> Hello,
>
> philippe.helluy@unistra.fr, le ven. 31 août 2018 11:19:59 +0200, a ecrit:
> > Things are worse on bigger tests. The code is faster with GPU-only runs
> > (STARPU_NCPU=0) than with CPU+GPU runs.
>
> Is there a big difference?
>
> > It seems that the dmdar scheduler is
> > not able to take the decision to put all the computations on the GPU only,
> > even when this is the better choice (I tried to change the beta to beta=2,
> > with no effect). In this particular case, the whole data could be put
> > entirely in the GPU memory.
> >
> > Do you have hints on this behavior ?
>
> Well, the problem is that the dmdar heuristic can tend to behave like
> that: when a lot of tasks are ready, the scheduler may find that it
> takes less time to transfer data back to the CPU (which is completely
> idle) and run it there than waiting for the busy GPU to be available.
> I'm surprised that increasing beta does not change, perhaps you could
> use much bigger values.
>
> Also, you may want to try the modular-heft scheduler. I don't know
> if the version in 1.2 behaves correctly, but the version in the 1.3
> branch should be fine. The difference with dmdar is that it does not
> schedule all available ready tasks in advance, but at most a given
> number of tasks or a given amount of computation time per computation
> unit (by default 30 and infinity, they can be configured with the
> STARPU_NTASKS_THRESHOLD and STARPU_EXP_LEN_THRESHOLD environment
> variables). That way, tasks will be put on the CPU only if they
> run not too slower there.
>
> Your application case will probably interest people doing the scheduling
> in StarPU. We will soon open a "task graph market" so you can submit
> your testcase and people will be able to fix heuristics with your
> application case in mind :)
>
> Samuel