search

ICLDisco / parsec

PaRSEC is a generic framework for architecture aware scheduling and management of micro-tasks on distributed, GPU accelerated, many-core heterogeneous architectures. PaRSEC assigns computation threads to the cores, GPU accelerators, overlaps communications and computations and uses a dynamic, fully-distributed scheduler based on architectural features such as NUMA nodes and algorithmic features such as data reuse.
Other
48 stars 17 forks source link

Global Unique ID for data collection #151

Open abouteiller opened 6 years ago

abouteiller commented 6 years ago

Original report by Reazul Hoque (Bitbucket: rhoque_icl, ).

We need unique ID for data collection, the same we have for task collection.

abouteiller commented 6 years ago

Original comment by Thomas Herault (Bitbucket: herault, GitHub: therault).

The couple ddesc / key makes a unique key.

We don't assign unique ids for the ddesc or store them in a hash table, because we always had the ddesc from the general context.

Giving a unique ID to ddesc (requiring that they are created on all ranks in the same order) and adding a hash table to look them up would be sufficient to implement this, or do you foresee something more intricate?

abouteiller commented 6 years ago

Original comment by Reazul Hoque (Bitbucket: rhoque_icl, ).

I plan to implement exactly what you mentioned in the last paragraph, identical to a taskpool.

The couple ddesc / key is the unique key and to find the ddesc in other ranks we need a unique ID for each DC and store them in a hashtable.

abouteiller commented 6 years ago

Original comment by George Bosilca (Bitbucket: bosilca, GitHub: bosilca).

I understand the need to name the data globally, but enforcing a global ordering of data creation does not feel like the right approach. This is different that we have today in PTG, as the data "naming" is local to a taskpool and not global to the entire execution.

What we need is to really encapsulate data existence with sections of code, so that a series of task can safely name the data they use. I would create explicit function to associate data with a global naming for a certain duration (this will register/unregister the data with a data hashtable) but explicitly, as needed by the DSL.

abouteiller commented 6 years ago

Original comment by Thomas Herault (Bitbucket: herault, GitHub: therault).

Task pools already have unique (global) ids.

Would attaching / detaching data to task pools be an alternative?

abouteiller commented 6 years ago

Original comment by George Bosilca (Bitbucket: bosilca, GitHub: bosilca).

The problem in two-fold. First, the insert_task interface does not rely on a specific taskpool but instead uses one that is predefined. Thus, using the taskpool for insert_task would be exactly the same as having a global order in dc creation. Second, the new insert_task model trim the tracked tasks, a process only tracks data involved in a local computation. Thus different processes might not see the data collections in the same order.

abouteiller commented 3 years ago

Removing version: 3.0.0 (automated comment)