You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An Event represents a node of the scheduling-graph. Each task is associated with multiple events, describing execution states before (pre_event) and after (post_event) the task execution, as well as the state of the task-result, being initialized (result_set_event) and retrieved (result_get_event).
The Scheduling-Graph is implemented as Out-List, meaning each vertex stores a list of outgoing-edges , called followers.
However this abstraction has some not insignificant special cases which we ought to optimize.
E.g. for CPU-Tasks we know, that the pre_event will never receive any followers. Thus the whole followers list and all associated follow up- checks in Event::notify() could be omitted for this kind of event.
For other kinds of events , e.g. the result_set_event & result_get_event will not be needed by any task which returns void ( this includes all cuda-tasks ).
Implementation could be done as class-inheritance hierarchy.
// only counts number of in-edgestemplate < typenameincount_t >
structSinkEvent { atomic< incount_t > state; };
// keeps out-edgesstructSourceEvent : SinkEvent { ChunkedList< EventPtr > followers ; };
// this event can wake up a worker structWakingEvent : SinkEvent { WakerID waker_id; };
// signals that the task must live at least until this event is reached// `notify()` will release the ownership of the task when the event is reachedstructTaskRefOwnEvent;
structCPUTask {
// pre event is only used to check if task is ready, therefore only needs to be SinkEventstructPreEvent : virtual SinkEvent {};
// post event is always sourcestructPostEvent : virtual SourceEvent , TaskRefOwnEvent {};
structResultSetEvent : WakingEvent {};
structResultGetEvent : TaskRefOwnEvent {};
};
structCudaTask {
// a cuda task must be able to notify other tasks through the pre-event.structPreEvent : SourceEvent {};
structPostEvent : SourceEvent {};
};
evaluation:
(+) would save us a lot of bytes per task.
(-) might require v-table for Event
(->) maybe solve this by encoding the type into EventPtr with bitmagic
(?) how can the event types be known statically
(->) need to select a specific event-configuration for each task.
(->) provide possibility to enable/disable optional Task-Properties via template in emplace_task() ?
The text was updated successfully, but these errors were encountered:
An
Event
represents a node of the scheduling-graph. Each task is associated with multiple events, describing execution states before (pre_event
) and after (post_event
) the task execution, as well as the state of the task-result, being initialized (result_set_event
) and retrieved (result_get_event
).The Scheduling-Graph is implemented as Out-List, meaning each vertex stores a list of outgoing-edges , called
followers
.However this abstraction has some not insignificant special cases which we ought to optimize.
E.g. for CPU-Tasks we know, that the
pre_event
will never receive any followers. Thus the wholefollowers
list and all associated follow up- checks inEvent::notify()
could be omitted for this kind of event.For other kinds of events , e.g. the
result_set_event
&result_get_event
will not be needed by any task which returnsvoid
( this includes all cuda-tasks ).Implementation could be done as class-inheritance hierarchy.
evaluation:
Event
emplace_task()
?The text was updated successfully, but these errors were encountered: