Re: [Starpu-devel] Fwd: Strong interest in contributions and integrations

[Andra Hugo <andra.hugo@inria.fr>]

Hi Fangli, 

Sorry I pushed the send button by mistake before finishing editing :)

Here is the continuation :) 

----- Mail original -----
> De: "Fangli Pi" <hpcfapix@hlrs.de>
> À: "Andra Hugo" <andra.hugo@inria.fr>
> Cc: "starpu-devel" <starpu-devel@lists.gforge.inria.fr>, "Dennis Hoppe" 
> <dennis.hoppe@hlrs.de>, "Dmitry Khabi"
> <khabi@hlrs.de>, "Michael Gienger" <gienger@hlrs.de>
> Envoyé: Lundi 23 Mai 2016 17:26:01
> Objet: Re: [Starpu-devel] Fwd: Strong interest in contributions and   
> integrations
> 
> Hi Andra,
> 
> Thanks very much for your reply. Although I cannot answer all the questions
> right now, they are all very valuable and we will take time to try to
> implement towards the direction.
> 
> Following what I can answer now:
> 
> 1. I did feed energy in Joule back to the profiling_info->power_consumed.
> Because in StarPU handbook, it is written that "double
> starpu_task_expected_power() returns expected power consumption in J", and I
> thought that they need to be consistent. (Am I right?)
>

Yes indeed, as Sam said it might be a bad naming in starpu.


> 2. I didn't use directly the time (start_time, submit_time, etc.) in the
> profiling_info because these times are relative to the initialization time
> of StarPU, however I need the absolute date and time. If StarPU could
> provide this, it would be great.
> 

I see, but then you need the relative time wrt to the start time in your 
agent, right?

> 3, 4, 5, 6. It is helpful to get these reviews and I will make changes
> accordingly in soon.
> 

OK.

> 7. The calls to sleep is due to the delay of communication and the database.
> I will try to reduce these by increase the update rate of the database.
> 

OK

> 8. The monitoring framework we use is a light-weight and near-real time 
> tool.
> There is one paper introducing it and one paragraph about overhead measuring
> is included. Please find the paper in the attachment. Since the monitoring
> framework is still under development, its updated overhead (for papi-based
> plugin) is reduced from 2.0%+ to 1.7%+ for an update rate of 100ms, and from
> 18.1% to 14.2% for an update rate of 10ms.
> 

OK looking into it.

> 9. It is true that the energy measurement cannot separate for different CPU
> cores, so that if multiple tasks are executed in parallel, the finally
> retrieved energy data is the energy consumed for all CPU and GPU. One
> possible solution could be that a  task which power data are profiled and
> power model is calibrating is considered to be in a training mode rather
> than an executing mode, and the tasks can only be executed asynchronously.
> Once the tasks are calibrated, it is possible to execute them in parallel.
> 

As far as I know RAPL allows measurements per core, if I'm not wrong? 

> 10. This is an interesting point, which we haven't thought before. Maybe we
> can have a study of starpu threads first and see how hard it is to modify
> the monitoring framework according. It would also be nice if you could
> provide more info in this direction.
> 

Yes I can help with this if as Sam said it proves to be an actual performance 
pb. 
My idea would be just to have some public functions of your agent and server 
that could be called from starpu for each thread. Let me know if this can 
makes sense.

Correct me if I am wrong but you seem to query your server (other process) 
for the energy data for each task ?


> All in all, I will update the repo according to your reviews and I will let
> you know once it is ready.

> 
> Best regards,
> Fangli
> 

Best, 
Andra