[CMake] Add NCCL to TVM and TVM Runtime #15605
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.
Generated by tvm-bot |
junrushao
force-pushed
the
feature/2023-08-21/add-nccl
branch
from
ea8b4a5
to
b9795a5
Compare
|
Not sure about NCCL. Here maybe two noob questions:
|
|
@Hzfengsy Thanks for asking!
You will need to install it separately. |
junrushao
force-pushed
the
feature/2023-08-21/add-nccl
branch
from
b9795a5
to
cc938fa
Compare
This PR introduces NCCL in the cmake system. NCCL is NVIDIA's library for distributed communication.
junrushao
force-pushed
the
feature/2023-08-21/add-nccl
branch
from
cc938fa
to
f55576f
Compare
|
Verified on my side, this is merged. Thanks @junrushao |
junrushao
added a commit
to junrushao/tvm
that referenced
this pull request
Aug 27, 2023
This PR introduces NCCL in the cmake system. NCCL is NVIDIA's library for distributed communication.
junrushao
added a commit
that referenced
this pull request
Aug 28, 2023
…rence/Training (#15622) * [CMake] Add NCCL to TVM and TVM Runtime (#15605) This PR introduces NCCL in the cmake system. NCCL is NVIDIA's library for distributed communication. * [Runtime] Expose ModuleGetFunction as PackedFunc (#15623) This PR exposes `Module.GetFunction` as a global PackedFunc. Previously, the only way to access this method is via TVM's C API, but the C++ PackedFunc API is missing. This PR patches this issue. * [Runtime] Utils to Stringify Device (#15630) There exist some basic functionality to convert Device and DLDeviceType to std::string, but they are not following the common naming convention in TVM, and thus less discoverable. This commit makes changes accordingly: - `runtime::DeviceName` to `runtime::DLDeviceType2Str` - move declaration of `operator << (std::ostream&, Device)` from `runtime/device_api.h` to `runtime/packed_func.h` * [RPC] Enhance RPC Protocol to support TVM Object (#15631) This PR introduces object support in TVM RPC protocol by introducing three new interfaces in `rpc_reference.h`: - `uint64_t GetObjectBytes(Object* obj)`, which is a required implementation that returns the length of the object during serialization; - `void WriteObject(Object* obj)` used to serialize an object to a writable channel; - `void ReadObject(int* type_code, TVMValue* value)`, which deserializes a TVM Object from a channel. To serialize an object, a recommended paradigm is to write its `type_index` first, and then its content. For example, `ShapeTuple` can be serialized as: ```C++ // pseudocode void WriteObject(Object* obj) { if (obj is ShapeTuple) { this->Write<uint32_t>(type_index of ShapeTuple); this->Write<int32_t>(obj->ndim); this->WriteArray<int64_t>(obj->shape); } else { throw Unsupported; } } uint64_t GetObjectBytes(Object* obj) { uint64_t result = 0; if (obj is ShapeTuple) { result += sizeof(uint32_t); # for `type_index` result += sizeof(int32_t); # for `ndim` result += sizeof(int64_t) * obj->ndim; # for content of the shape } else { throw Unsupported; } return result; } ``` To deserialize an object, similar to serialization, the recommended approach paradigm is to read `type_index` and disptch based on it. Caveat on deserialization: RPC Reference itself does not own or allocate any memory to store objects, meaning extra logic is usually required in `ReadObject` to keep their liveness. * [Unity] Disco: A Framework-Agnostic SPMD Runtime for Distributed Inference/Training Disco is a distributed runtime that consists of a controler and a cluster of workers. The controler is responsible for managing the workers by broadcasting commands to all the workers together, and the workers are responsible for executing the commands and. The controler and workers communicate with each other through a bi-directional channel. Different from a generic system, Disco is designed to as "single-program-multiple-data" (SPMD) runtime, which means that all the workers execute the same instruction at the same time, but the data they are working on may be different. For example, in data parallelism, each worker may work on a different batches of the data, but they all execute the same set of instructions. Therefore, imagine there is a virtual machine that executes the program, the structures of workers' register files could be considered as "identical" (single program) although the values may differ (multiple data). **DRef.** Following the design above, consider the program in SPMD in a virtual ISA, then each worker is a virtual machine instance to execute the ISA maintaining its own register file. The controler denotes each of their register files with a unique integer "register id", and the workers use this id to refer to the register file that resides on itself. DRef is a control-side object backed by such a register id. The data it contains is not assumed to be directly accessible by the controler, with an exception for worker-0, which is a special worker that is always co-located with the controler. **Worker-0.** Worker-0 is a special worker that is always co-located with the controler. It is assumed that the controler can synchronize with and access the registers of worker-0. The Disco session provides multiple APIs to interact specifically with the worker-0. To shared data with other workers, a common paradigm in Disco is to copy data from the controler-side NDArray to the worker-0, and then copy it to other workers using primitives on the data plane, for example, `broadcast` and `send`. **Control plane.** The controler broadcasts commands to all the workers as control signals. For example, the control may ask all workers to load a library or call a function respectively. Common control signals include: shutdown, retrievel a global PackedFunc, call packed function, etc. The controler is assumed to keep a message channel to each worker to implement the broadcast behavior, and the message channel may vary depends on usecases. **Data plane.** The data channel is usually used to exchange data between workers, especially for tensor data which is usually large. For example, performing an allreduce operator for sharded matrix multiplication, or broadcasting for an input tensor. For efficiency, the data channel is usually backed by NCCL on NVIDIA GPUs, RCCL on AMD GPUs, or MPI on CPUs. **Session.** A Disco session is a primary interface to interact with the Disco runtime, serving as a global context that manages the control and workers. It could be implemented as a multi-threaded with a pool of workers for single-node multi-gpu scenarios, or TCP sockets for workloads that span over a cluster of nodes. **Channel.** Disco channel is a bi-directional communication channel between the controler and workers for exchanging control signals. It is no different from a generic RPC channel, but adopts TVM's PackedFunc calling convention to support polymorphic and variadic arguments. Co-Authored-by: Lesheng Jin <[email protected]> --------- Co-authored-by: Lesheng Jin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces NCCL in the cmake system.
NCCL is NVIDIA's library for distributed communication.