DOCSEARCHbyAlgolia
Submit Docs

Celerity Github Documentation

website·Indexed 30 days ago

https://celerity.github.io/docs/

Searchable website documentation for Celerity Github from https://celerity.github.io/docs/.

Tokens
150.2K
Snippets
1.3K
Records
1.6K
Agent score
74%

What's inside Celerity Github Documentation

  1. Overview of closure_hydrator

    The closure_hydrator is a thread-local singleton designed to inject information into objects (such as host/device and local accessors) that have been captured in a lambda closure. It works by utilizing the copy constructor of captured objects to modify them while the containing closure is being copied via the hydrate() function. Accessors retrieve their specific information using unique "hydration ids" assigned at creation. Because kernel command function closures may be copied multiple times by SYCL, the hydrator must be explicitly enabled per-thread to prevent unintended hydration.

  2. Overview of engine_impl

    The engine_impl struct implements the logic for an out-of-order execution engine. It tracks incomplete instructions, manages an assignment queue based on instruction priority, and handles the mapping of instructions to specific hardware targets and lanes.

  3. Overview of live_executor::impl

    The live_executor::impl struct is the internal implementation of the live executor. It manages the execution of instructions by interfacing with a backend, a communicator, and an out-of-order engine. It tracks in-flight asynchronous instructions, memory allocations, host object instances, and cloned communicators.

  4. Overview of live_executor

    The live_executor class is an implementation of the executor used for standard execution of Celerity applications. It resolves internal instruction dependencies using an out_of_order_engine and receive_arbiter, then dispatches the resulting operations to a backend and communicator implementation.
    class live_executor : public executor { /* ... */ };

  5. Overview of region_map_impl

    The region_map_impl class implements a customized R-Tree (based on Guttman 1984) that maps multi-dimensional boxes to values of ValueType. To maintain performance, the implementation automatically merges entries that have compatible boxes and equal values. The class acts as a wrapper around the root node and manages recursive tree operations, entry merging, and the reinsertion of orphaned nodes after updates.
    template <typename ValueType, int Dims>
class region_map_impl { 
    // Implementation of a customized R-Tree
};

  6. Overview of sycl_generic_backend

    The sycl_generic_backend class is a generic implementation of sycl_backend. It serves as a fallback implementation for device copies, particularly in cases where 2D or 3D copies might otherwise be inefficient.
    class sycl_generic_backend : public sycl_backend { /* ... */ };

  7. Overview of the backend class

    The backend class manages asynchronous operations including device- and device-accessible host memory allocation, data copying between host and device, and the launching of host tasks and device kernels. Asynchronous work must be explicitly assigned to in-order queue IDs as assigned by the out_of_order_engine.

  8. Overview of the communicator class

    The communicator class provides an interface for peer-to-peer and collective communication across nodes, designed to be implemented for MPI or similar system APIs.

    Key architectural constraints:

    • Root and Cloning: Celerity maintains one root communicator which can be cloned collectively. The same communicator instance in a "cloning tree" must participate in corresponding operations on each node.
    • Thread Safety: Individual communicator instances are not thread-safe. However, multiple cloned instances can be used concurrently if each is accessed from its own thread.
    • Ordering: Peer-to-peer operations (send, receive, poll) may be re-ordered by the communicator. Collective operations are guaranteed to be executed precisely in the order they are submitted.

  9. Overview of the runtime::impl class

    The runtime::impl class is the primary implementation of the Celerity runtime. It inherits from the base runtime class and serves as a delegate for the task_manager, scheduler, and executor. It manages the lifecycle of buffers, host objects, queues, and reductions, and coordinates the execution of task graphs.
    class runtime::impl : public runtime,
                      private delegate, // task_manager::delegate
                      private delegate, // scheduler::delegate
                      private delegate { // executor::delegate
                      /* ... */
};

  10. Overview of out_of_order_engine

    The out_of_order_engine is a state machine that controls when and how instructions are assigned to execution resources according to their dependency graph. Depending on the instruction type, it can either assign instructions for immediate execution once all predecessors are complete or enqueue them eagerly in backend thread or device queues to reduce launch latencies.

  11. Overview of receive_arbiter

    The receive_arbiter class matches receive instructions to inbound pilots and triggers in-place payload receives on the communicator. Because distributed command graph generation only yields exact destinations for push commands (and not await-pushes), sender nodes communicate exact ranges via pilot messages during execution. The receive_arbiter maintains a state machine for each transfer_id to drive operations until the corresponding async_event for each receive instruction is completed.

  12. Overview of the sycl_backend class

    The sycl_backend class is an abstract implementation of the backend interface. It sources all memory allocations from SYCL and dispatches device kernels to SYCL in-order queues. It implements all backend functions except for copy operations, which are not subject to platform-dependent specialization.
    class sycl_backend : public backend { /* ... */ };