UO-OACISS / apex

Autonomic Performance Environment for eXascale (APEX)
Other
38 stars 24 forks source link

Refactor the API. #37

Open khuck opened 9 years ago

khuck commented 9 years ago

We need to review the events published by OCR and think about re-doing the API to be more useful. Here's a link to the OCR and Legion type events:

https://docs.google.com/presentation/d/1WabD-rOOVMODfHlh3F2PUiQjsGbfLi69KkPyG7tFeVw/edit#slide=id.gc56cbbd08_0_35

In particular, we need to think about task lifetimes and dependencies. We also should think about how we can unify (somehow) the C and C++ interfaces so that we don't have so much code duplication, or maybe some way to generate the API for either C or C++ or both.

khuck commented 8 years ago

Here are some proposed contents for apex_events.h:

#pragma once

/**
 * Typedef for enumerating the different event types
 */
typedef enum _apex_event_type {
    APEX_TASK_CREATE = 0,         /* parent ID */
    APEX_TASK_DEPENDENCY_REACHED, /* event ID, data ID, task ID, parent ID, permission */
    APEX_TASK_READY,              /* why ready */
    APEX_TASK_EXECUTE,            /* why delay, fet(?) */
    APEX_TASK_FINISHED,           /* */
    APEX_TASK_DESTROY,            /* */
    APEX_DATA_CREATE,             /* locale, parent ID, size, layout */
    APEX_DATA_NEW_SIZE,           /* new ID */
    APEX_DATA_MOVE_FROM,          /* taskset loc */
    APEX_DATA_MOVE_TO,            /* source loc */
    APEX_DATA_REPLACE,            /* new ID */
    APEX_DATA_DESTROY,            /* */
    APEX_EVENT_CREATE,            /* parent task ID */
    APEX_EVENT_ADD_DEPENDENCY,    /* data/task/event ID, parent task ID */
    APEX_EVENT_TRIGGER,           /* */
    APEX_EVENT_DESTROY,           /* */
} apex_event_type;                /* */

typedef taskID uint_64;
typedef eventID uint_64;
typedef dataID uint_64;
typedef time uint_64;
typedef userID uint_64;
typedef locExID uint_64;
typedef physicalLocationExe hardwareDescription;
typedef physicalLocationMemory hardwareDescription;
typedef size uint_64;
typedef layout uint_64;
typedef permission uint_64;
pmucci commented 8 years ago

Thanks for these. So hpx itself does not "count" these events or does so only in terms of time?

Phil

Apologies for brevity and errors as this was sent from my mobile device.

On Dec 21, 2015, at 11:24, Kevin Huck notifications@github.com wrote:

Here are some proposed contents for apex_events.h:

pragma once

/**

Typedef for enumerating the different event types / typedef enum _apex_event_type { APEX_TASK_CREATE = 0, / parent ID / APEX_TASK_DEPENDENCY_REACHED, / event ID, data ID, task ID, parent ID, permission / APEX_TASK_READY, / why ready / APEX_TASK_EXECUTE, / why delay, fet(?) / APEX_TASK_FINISHED, / / APEX_TASK_DESTROY, / / APEX_DATA_CREATE, / locale, parent ID, size, layout / APEX_DATA_NEW_SIZE, / new ID / APEX_DATA_MOVE_FROM, / taskset loc / APEX_DATA_MOVE_TO, / source loc / APEX_DATA_REPLACE, / new ID / APEX_DATA_DESTROY, / / APEX_EVENT_CREATE, / parent task ID / APEX_EVENT_ADD_DEPENDENCY, / data/task/event ID, parent task ID / APEX_EVENT_TRIGGER, / / APEX_EVENT_DESTROY, / / } apex_event_type; / */ typedef taskID uint_64; typedef eventID uint_64; typedef dataID uint_64; typedef time uint_64; typedef userID uint_64; typedef locExID uint_64; typedef physicalLocationExe hardwareDescription; typedef physicalLocationMemory hardwareDescription; typedef size uint_64; typedef layout uint_64; typedef permission uint_64;

— Reply to this email directly or view it on GitHub.

khuck commented 8 years ago

Those events aren’t HPX specific - if anything, they are OCR/Legion specific. They came from a meeting held in mid-2015 between Sandia, Intel and LLNL (that we found out about after-the-fact). We haven’t had a chance to integrate any of these ideas into APEX and/or HPX.

HPX does keep track of these counters, but only with respect to tasks I think. I do think HPX has a concept of task states (and corresponding counters), such as created, scheduled, yielded, executing, completed, etc. - we don't tie into them explicitly. But we could/should - it just depends on whether you want to suffer the overhead of monitoring those state transitions.

pmucci commented 8 years ago

Ok, understood.

Yes, as we discussed, we will eventually decide to pay for the performance penalty to measure this stuff. I’m assuming we should be able to measure the implications of such code with benchmarks… I do doubt whether HPX or similar run-times are as lean as they claim to be, there’s a lot of pointer-dereferencing in ‘dem ‘dar hills.

Good to know about the events though. Definitely food for thought.

Thanks!

Philip J. Mucci Minimal Metrics LLC 7125 Wells Ave | Navarre FL 32566 Ph: 415.577.9899 | Fax: 415.689.3976
www.minimalmetrics.com http://www.minimalmetrics.com/

On Dec 21, 2015, at 6:07 PM, Kevin Huck notifications@github.com wrote:

Those events aren’t HPX specific - if anything, they are OCR/Legion specific. They came from a meeting held in mid-2015 between Sandia, Intel and LLNL (that we found out about after-the-fact). We haven’t had a chance to integrate any of these ideas into APEX and/or HPX.

HPX does keep track of these counters, but only with respect to tasks I think. I do think HPX has a concept of task states (and corresponding counters), such as created, scheduled, yielded, executing, completed, etc. - we don't tie into them explicitly. But we could/should - it just depends on whether you want to suffer the overhead of monitoring those state transitions.

— Reply to this email directly or view it on GitHub https://github.com/khuck/xpress-apex/issues/37#issuecomment-166451404.