High performance computing system

Abstract

A method including providing a SHARP tree including a plurality of data receiving processes and at least one aggregation node, designating a data movement command, providing a plurality of data input vectors to each of the plurality of data receiving processes, respectively, the plurality of data receiving processes each passing on the respective received data input vector to the at least one aggregation node, and the at least one aggregation node carrying out the data movement command on the received plurality of data input vectors. Related apparatus and methods are also provided.

Description

FIELD OF THE INVENTION

The present invention relates to high performance computing systems in general.

BACKGROUND OF THE INVENTION

In high performance computing (HPC) systems many applications are written in a manner that requires communication between the systems which perform portions of the work (termed herein “processes”).

Part of the communications includes collective operation such as (by way of non-limiting example) doing sum of multiple vectors (element-wise add operation) from multiple processes, one per process, and sending a copy of the resulting vector to all the participating processes; this operation is called “all-reduce”. Another non-limiting example would be sending the result to only one of the processes; this operation is called “reduce”.

In addition to the compute elements (that is, reduce and all-reduce involve mathematical operators) there are data movement commands such as (by way of non-limiting example) all2all, gather, all gather, gather v, all gather v, scatter, etc. Commands of this type are defined in the well-known Message Passing Interface specification, and other communication Application Programmer Interface definitions.

SUMMARY OF THE INVENTION

The present invention, in certain embodiments thereof, seeks to provide an improved system and method for high performance computing.

There is thus provided in accordance with an exemplary embodiment of the present invention a method including providing a SHARP tree including a plurality of data receiving processes and at least one aggregation node, designating a data movement command, providing a plurality of data input vectors to each of the plurality of data receiving processes, respectively, the plurality of data receiving processes each passing on the respective received data input vector to the at least one aggregation node, and the at least one aggregation node carrying out the data movement command on the received plurality of data input vectors.

Further in accordance with an exemplary embodiment of the present invention the data movement command includes one of the following: gather, all gather, gather v, and all gather v.

Still further in accordance with an exemplary embodiment of the present invention the at least one aggregation node produces an output vector.

Additionally in accordance with an exemplary embodiment of the present invention at least one of the plurality of data input vectors includes a sparse vector.

Moreover in accordance with an exemplary embodiment of the present invention the at least one aggregation node utilizes a SHARP protocol.

There is also provided in accordance with another exemplary embodiment of the present invention apparatus including a SHARP tree including a plurality of data receiving processes and at least one aggregation node, the SHARP tree being configured to perform the following: receiving a data movement command, receiving a plurality of data input vectors to each of the plurality of data receiving processes, respectively, the data receiving processes each passing on the respective received data input vector to the at least one aggregation node, and the at least one aggregation node carrying out the data movement command on the received plurality of data input vectors.

Further in accordance with an exemplary embodiment of the present invention the data movement command includes one of the following: gather, all gather, gather v, and all gather v.

Still further in accordance with an exemplary embodiment of the present invention the at least one aggregation node is configured to produce an output vector.

Additionally in accordance with an exemplary embodiment of the present invention at least one of the plurality of data input vectors includes a sparse vector.

Moreover in accordance with an exemplary embodiment of the present invention the at least one aggregation node utilizes a SHARP protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:

FIG. 1 is a simplified pictorial illustration of a high-performance computing system constructed and operative in accordance with an exemplary embodiment of the present invention;

FIG. 2 is a simplified pictorial illustration of a high-performance computing system constructed and operative in accordance with an alternative exemplary embodiment of the present invention;

FIG. 3A is a simplified pictorial illustration showing distribution of data, in a system similar to that of FIG. 1, to all processes; and

FIG. 3B is a simplified pictorial illustration showing distribution of data, in a system similar to that of FIG. 1, to a single process.

DETAILED DESCRIPTION OF AN EMBODIMENT

General Introduction

By way of introduction (but without limiting the generality of the present application), the concept behind exemplary embodiments of the present invention is to use the SHARP protocol to accelerate (at least the operations) gather, all gather, gather V, and all gather V.

The SHARP algorithm/protocol is described in US Published Patent Application 2017/0063613 of Bloch et al, the disclosure of which is hereby incorporated herein by reference.

In certain exemplary embodiments of the present invention, computations which may be described herein as if they occur in a serial manner may be executed in such a way that computations already occur while data is still being received.

The inventors of the present invention believe that current methodology for addressing the above-mentioned scenarios is to use software algorithms in order to perform the operations mentioned above. The software algorithms involve a large amount of data transfer/movement. Significant overhead may also be generated on a CPU which manages the algorithms, since multiple packets, each with a small amount of data, are sent; sometimes identical such packets are sent multiple times to multiple destinations, creating additional packet/bandwidth overhead, including header overhead. In addition, such software algorithms may create large latency when a large number of processes are involved.

In exemplary embodiments of the present invention, one goal is to offload work from the management CPU/s by simplification of the process using the SHARP algorithm/protocol (referred to above and described in US Published Patent Application 2017/0063613 of Bloch et al, the disclosure of which has been incorporated herein by reference); latency as well as bandwidth consumption may also be reduced in such exemplary embodiments.

Embodiment Description

In exemplary embodiments of the present invention, the SHARP algorithm/protocol (referred to above) is used to implement at least: gather; gather v; all gather; and all gather v.

In general, in exemplary embodiments of the present invention, the gather operation is treated as a regular reduction operation by using a new data format supporting sparse representation. When using the sparse representation each process/aggregation point sends its data to the SHARP network, while allowing the aggregation to move forward; this is different from a regular aggregation operation which assumes that each one of the processes/aggregation points contribute the exact same vector size.

It is appreciated that, in certain exemplary embodiments, within the SHARP network, a sparse representation may be converted to a dense representation; in certain cases, a dense representation may be able to be processed with greater efficiency. It is also appreciated that, in such a case, both sparse and dense representations may co-exist simultaneously in different points within the SHARP network.

In exemplary embodiments of the present invention, the following protocol updates are made relative to the SHARP protocol (see US Published Patent Application 2017/0063613 of Bloch et al, the disclosure of which has been incorporated herein by reference):

• • The SHARP operation header carries an indication the SHARP payload is sparse
  • The SHARP operation header uses a “sum” operation to eliminate the need to create a new operation

The following is one possible non-limiting example of an appropriate data format useable in exemplary embodiments of the present invention:

Index data size in bytes data [ ] data [ ] represents a list of data elements, each of which can be byte/s or bit/s. A special index value is reserved to mark the end of the data.

In exemplary embodiments, the following is an example of SHARP protocol behavior for using sparse data: An aggregation point looks at the data that arrives. If there is a matching index the aggregation point will implement the operation that is mentioned in the operation header; as a consequence of the matching index, the aggregation point will add the single index data to the result vector (that is, will concatenate the single data to the result vector).

The following, in exemplary embodiments, are non-limiting implementations of various operations:

1. How to implement gather:

Each process sends its data with index=rank_id, data_size=data size contributed, the result vector will include data from all the processes because each index will be unique and aggregation nodes will concatenate all the received data.

In gather, each process sends data, and that data is (in the end of the gather) held by a single process.

2. How to implement all-gather:

Similar to gather but ask SHARP protocol to send the result to all the processes that contributed to this operation. In all-gather, each process sends data, and that data is sent to all other processes.

3. How to implement gather v:

Each process sends a variant data size, indicating the amount of data that it sent; the SHARP protocol generates a result that includes all the data with variant size. A rank id, identifying the sending process, may also be sent.

The addition of “v” indicates that each process may send a vector of any size which that process wishes to send; otherwise, gather v is similar to gather.

4. How to implement all-gather v:

Similar to gather v but ask SHARP protocol to send the result to all the processes that contributed to this operation. Similarly to gather v, in certain exemplary embodiments the amount of data that is sent, and/or a rank id, may be provide by processes which send data, although it is appreciated that including such information is generally optionalThe addition of “v” indicates that each process may send a vector of any size which that process wishes to send; otherwise, all-gather v is similar to all-gather.

As indicated above, the data format is exemplary only, and is in no way meant to be limiting. Without limiting the generality of the foregoing, it is appreciated that certain optimizations, including compression of meta-data (index and data size), may be used.

In exemplary embodiments, the present invention utilizes the SHARP protocol all-reduce ability in which processes send data for reduction. However, the all gather operation differs from previously-used examples of the SHARP protocol all-reduce: in all-reduce each process sends a vector of size X and the result is also of size X (an element-wise operation is performed). In all gather or all gather v, each process j sends vector of size Xj where the result vector size is Sum(Xj). In order to support this operation, each process to sends its own data Xj and all of the data is gathered into a single large vector. Persons skilled in the art will appreciate how the same principles apply to the other operations described herein.

Reference is now made to FIG. 1, which is a simplified pictorial illustration of a high-performance computing system, generally designated 100, constructed and operative in accordance with an exemplary embodiment of the present invention. FIG. 1, by way of non-limiting example, depicts a particularly small system including only 4 processes 110; it is appreciated that, in general, a much larger number of processes would be used.

In FIG. 1, each of the 4 processes 110 (designated P1, P2, P3, and P4) is depicted as sending vectors 120 (designated X1, X2, X3, and X4; corresponding respectively to P1, P2, P3, and P4), the vectors 120 being various sizes, for an operation to be carried out. An aggregation node 130 gathers all of the data received (the vectors 120, X1, X2, X3, and X4) from the 4 processes 110 (P1, P2, P3, and P4) into a single vector 140.

Assuming, as described above, that the sparse vector format includes indexes, the aggregation node will be able to generate an ordered vector as depicted in FIG. 1. In general, if (by way of non-limiting example), indexes range from 0-100, the resulting sorted vector may be sorted in order of the indexes. This feature would allow finding data relating to a given index more easily.

The aggregation operation will be carried out (in a manner more complex than that shown for purposes of simplicity of illustration in FIG. 1) on multi-level aggregation, as is usual in SHARP (see US Published Patent Application 2017/0063613 of Bloch et al, the disclosure of which has been incorporated herein by reference), thus achieving scalability and hierarchical operation.

In the general case the aggregation node will not assume the indexes are consecutive. For example, in the particular non-limiting example of FIG. 1, not all vectors 120 need be present.

Reference is now made to FIG. 2, which is a simplified pictorial illustration of a high-performance computing system constructed and operative in accordance with an alternative exemplary embodiment of the present invention. The system of FIG. 2, generally designated 200, operates similarly to the system of FIG. 1, with a plurality of processes 210 sending vectors 220 towards aggregation nodes 230. In the system of FIG. 2, two different aggregation nodes 230 are shown as receiving the vectors 220 from the processes 210; this type of architecture allows better scaling. It will be appreciated that, while only two aggregation nodes 230 are shown, in practice a much larger number of aggregation nodes, arranged in a tree structure, may be used (see US Published Patent Application 2017/0063613 of Bloch et al, the disclosure of which has been incorporated herein by reference, for a more detailed discussion).

In the system of FIG. 2, an aggregation/root node 235 ultimately receives all of the vectors 220 and produces a single combined vector 240.

Reference is now made to FIG. 3A, which is a simplified pictorial illustration showing distribution of data, in a system similar to that of FIG. 1, to all processes; and to FIG. 3B, which is a simplified pictorial illustration showing distribution of data, in a system similar to that of FIG. 1, to a single process.

FIGS. 3A and 3B show a system, generally designated 300, which operates similarly to the system 100 of FIG. 1. For purposes of simplicity of illustration, the systems of FIGS. 3A and 3B are based on the system of FIG. 1, it being appreciated that systems based on the system of FIG. 2 may alternatively be used.

In FIGS. 3A and 3B, the systems are shown after the processes 310 have already sent their individual vectors (not shown) to the aggregation node 330, and the combined vector 340 has been produced. In FIG. 3A, a situation is depicted in which the combined vector 340 is sent to all of the processes 310 (as would be the case, by way of non-limiting example, in an all-gather operation); while in FIG. 3B, a situation is depicted in which the combined vector 340 is sent to only one of the processes 310 (as would be the case, by way of non-limiting example, in a gather operation.

In FIGS. 3A and 3B, inter alia, input data is depicted as being provided in order (X1, 2, X3, X4). While providing input data in order may be optimal in certain preferred embodiments, it is appreciated that it is not necessary to provide input data in order.

It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the present invention.

It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined by the appended claims and equivalents thereof:

Claims

1. A method for computation, comprising: in a high-performance computing system that runs an application in which multiple processes perform portions of work of the application, defining a network comprising the multiple processes and at least one aggregation node;in response to a data movement command, passing respective vectors of data having different, respective data sizes from the multiple processes over the network to the at least one aggregation node;at the at least one aggregation node, in response to the data movement command, receiving and concatenating the respective vectors to generate a result vector having a result vector size equal to a sum of the respective data sizes of the received vectors; andoutputting the result vector from the at least one aggregation node to the network,wherein defining the network comprises providing multiple aggregation nodes, comprising a root node, which outputs the result vector, and at least two intermediate aggregation nodes, each of which receives and concatenates the respective vectors from respective ones of the processes.

2. The method according to claim 1, wherein the data movement command comprises a gather command.

3. The method according to claim 1, wherein outputting the result vector comprises sending the result vector to the multiple processes.

4. The method according to claim 1, wherein defining the network comprises providing a hierarchical tree having nodes corresponding to the multiple processes.

5. The method according to claim 1, wherein passing the respective vectors comprises sending the data from the multiple processes with respective indexes, and wherein concatenating the respective vectors comprises adding the data to the result vector according to the respective indexes.

6. The method according to claim 5, wherein sending the data comprises providing indications from the multiple processes to the at least one aggregation node of the respective data sizes of the respective vectors.

7. A high-performance computing system comprising multiple nodes, which are configured to run an application in which multiple processes perform portions of work of the application, wherein a network comprising the multiple processes and at least one aggregation node is defined in the system, such that in response to a data movement command, the multiple processes pass respective vectors of data having different, respective data sizes over the network to the at least one aggregation node, andwherein at the at least one aggregation node, in response to the data movement command, receives and concatenates the respective vectors to generate and outputs a result vector to the network having a result vector size equal to a sum of the respective data sizes of the received vectors,wherein the network comprises multiple aggregation nodes, including a root node, which outputs the result vector, and at least two intermediate aggregation nodes, each of which receives and concatenates the respective vectors from respective ones of the processes.

8. The system according to claim 7, wherein the data movement command comprises a gather command.

9. The system according to claim 7, wherein the at least one aggregation node is configured to send the result vector to the multiple processes.

10. The system according to claim 7, wherein the network comprises is defined as a hierarchical tree in which the nodes correspond to the multiple processes.

11. The system according to claim 7, wherein the multiple processes pass the respective vectors to the at least one aggregation node together with respective indexes, and wherein the at least one aggregation node concatenates the respective vectors according to the respective indexes.

12. The system according to claim 11, wherein the multiple processes provide indications to the at least one aggregation node of the respective data sizes of the respective vectors.