Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor the API. #37

Open
khuck opened this issue Sep 15, 2015 · 4 comments
Open

Refactor the API. #37

khuck opened this issue Sep 15, 2015 · 4 comments

Comments

@khuck
Copy link
Collaborator

khuck commented Sep 15, 2015

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 khuck changed the title Redo the API. Refactor the API. Sep 15, 2015
@khuck
Copy link
Collaborator Author

khuck commented Dec 21, 2015

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
Copy link

pmucci commented Dec 21, 2015

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 [email protected] 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
Copy link
Collaborator Author

khuck commented Dec 21, 2015

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
Copy link

pmucci commented Dec 22, 2015

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 [email protected] 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 #37 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants