Designing ParallelZone’s ResourceSet Class

The need for a ResourceSet class grew out of Designing ParallelZone’s Parallel Runtime. This page fleshes the details out more.

Why Do We Need the ResourceSet Class?

When viewing resources we need to know the total set of resources, the responsibility of which falls to RuntimeView, and also which of those resources are local/directly accessible by the current process. As discussed in Designing ParallelZone’s Parallel Runtime, the ResourceSet class is ParallelZone’s abstraction for delimiting which resources are part of the process’s local runtime environment.

ResourceSet Responsibilities

As enumerated in Designing ParallelZone’s Parallel Runtime the main responsibilities of the ResourceSet is to:

  1. Scheduling per-thread tasks.

  2. Tracking hardware instances available to the local runtime environment.

  3. Facilitating data movement among ResourceSet instances.

  4. Track resource usage.

  5. Allow logical partitioning of resources.

Additional considerations:

  1. Separate API concerns from backend.

    • May need to use different runtime systems in the future.

    • May need to support different hardware.

    • Hopefully keep dependencies private.

ResourceSet Architecture

../../_images/resource_set.png

Fig. 8 Illustration of the ResourceSet class and its major members.

Fig. 8 shows the architecture of the ResourceSet class. It addresses the responsibilities by:

  1. Having a scheduler which is in charge of scheduling thread-based tasks.

  2. Instances for each hardware resource actually present.

    • Actual instances can be implicit (made on the fly)

    • ResourceSet’s constructor is responsible for finding resources.

  3. CommPP object to send/receive data in object-oriented manner.

    • We decided to have the hardware instances control the process of actually sending/receiving data. For example rs.ram().gather() would gather data into the RAM of the ResourceSet object rs, it’s called on.

    • Decision facilitates controlling the end-point (RAM or memory on the GPU).

    • Exposes a multi-process operation below RuntimeView, which is somewhat awkward.

  1. Accomplished by using PIMPL design paradigm.

At present:

  • Tracking of resource usage

  • Logical partitioning

are not yet implemented or designed.

Additional Notes

We right now assume one RAM bank. Should we generalize this?