...
The functions in the C_API are:
| Function Name | Description |
|---|---|
| MXImperativeInvokeEx |
...
| invokes an operator to perform the computation | |
| MXNDArrayCreateEx |
...
| creates an |
...
| ndarray |
| MXNDArrayGetDType |
...
| returns the data type of the ndarray | |
| MXNDArrayGetShape |
...
| returns the shape of the ndarray (as a tuple where each element is the size of a dimension) | |
| MXNDArraySyncCopyFromCPU |
...
| called when data is initially residing outside of an MXNet data structure (ie. numpy.ndarry rather than mxnet.numpy.ndarray). Data is copied into the mxnet data structure |
...
| MXNDArrayWaitAll |
...
| wait for all asynchronous operations to finish in MXNet. This function is only used in benchmarking to wait for work to happen. In a real program there is no waiting, data dependencies are evaluated and computation executed as needed in a As Late As Possible (ALAP) way |
...
The function in the Engine API are:
| Function Name | Description |
|---|---|
| WaitForVar |
...
| Takes a variable reference as input and waits until that variable has been computed before returning |
...
Other API functions:
| Function Name | Description |
|---|---|
| ResourceParallelRandomSetSeed |
...
| sets the random number generator seed |
Operators we intended to call in the code:
| Operator Name | Description |
|---|---|
| sum |
...
| sum a tensor along a particular axis | |
| diag |
...
| compute the diagonal of the tensor |
Whats happening here...
From the code, we can identify the major events in our test application
...
We still have the same sequence of events at the beginning to initialize the MXNet ndarray (MXNDArrayCreateEx, MXNDArrayGetShape, MXNDArrayGetDType, MXNDArraySyncCopyFromCPU). Then the diag operator runs, followed by the sum operator, and finally the waitall. When you look at this, be careful about the assumptions that you make. In this version of the timeline it appears that the operator executes after the MXImperativeInvokeEx runs, and seems to imply an inherent ordering. But realize that there is no dependency between the diag operator finishing and the next MXImperativeInvokeEx launching the sum operator. In this case it just-so-happens that the diag operator finishes so quickly that it appears that way. But in reality the main thread is launching the operators and not waiting for them to finish. Lastly, keep in mind that in this case by the time we hit the MXNDArrayWaitAll everything is already done and we return immediately, but in other circumstances it may sit here waiting for everything to finish (like we saw earlier in the first run). To summarize, we
Summary
We ran the MXNet profiler on a simple application and tried to understand the runtime behavior of MXNet. We were able to see some underlying functionality that manages operator execution and data allocation and some unexpected initialization routines.
...