Questions about how a computational graph is executed

fengkeyleaf: <p>Hi there,</p>
<p>I am new to the computational graph in pytorch and reading the blog, <a href="https://pytorch.org/blog/how-computational-graphs-are-executed-in-pytorch/" rel="noopener nofollow ugc">How Computational Graphs are Executed in PyTorch</a>, and have several questions about it.</p>
<p>So the first question is about why we need threads in the section, <a href="https://pytorch.org/blog/how-computational-graphs-are-executed-in-pytorch/#graph-traversal-and-node-execution" rel="noopener nofollow ugc">GRAPH TRAVERSAL AND NODE EXECUTION</a>. According to the article, the engine will initialize one thread per device, except for the main thread executing the python interpreter. Does this mean that a thread would exchange data with other threads when computing gradients, that is, executing a computational graph on that thread? Or there is no data exchange, can we say that we have one CPU and one GPU and we don’t move data/tensors to the GPU, the thread on the GPU will be idle and the main thread on CPU would be responsible for executing the computational graph(s)?</p>
<p>The second question is about the ReadyQueue. As far as I know, each thread would have a thread-local ready queue and starts executing a computational graph when the main thread enqueues a RootNode/task into that queue, and then the thread computes gradients as the Figure 5, Animation of the execution of the computational graph, shown. However, the blog also mentions that</p>
<blockquote>
<p>Also, <strong>if the rest of the graph is not on the cpu</strong>, we directly start on that worker while the <code>RootNode</code> is always placed on the cpu ready queue.</p>
</blockquote>
<p>I just don’t get it that how does the cpu ( or the main thread ) know what is the RootNode for a graph that is not on it? Or the cpu builds the graph, record its RootNode, and move the graph to a GPU? Or something like that?</p>
<p>The last question is about the order of enqueuing nodes when a thread executes a computational graph. Take the one in the Figure 5 as an example. Assume there is no data exchange between threads, like between two GPUs or a CPU and a GPU when executing a graph. After the thread_main executes the graph root, is the order of enqueuing its child nodes, LogBackward and SinBackward, also guaranteed as it’s shown in the animation, that is, enqueue LogBackward alwasy before SinBackward? Or it just depends the actual implementation? And what would this happen if there is data exchange between threads? Just curious.</p>
<p>Regards,</p>

soulitzer: <aside class="quote no-group" data-username="fengkeyleaf" data-post="1" data-topic="205217">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/fengkeyleaf/48/70971_2.png" class="avatar"> fengkeyleaf:</div>
<blockquote>
<p>exchange data with other threads when computing gradients,</p>
</blockquote>
</aside>
<p>A thread can exchange data with other threads between computation of nodes, e.g. if I did some compute in forward on one gpu, moved it onto another gpu then did some more compute.  After thread1 finishes compute of backward of the second compute, it enqueues the gradients onto the first device/thread’s queue.</p>
<blockquote>
<p>Or the cpu builds the graph, record its RootNode, and move the graph to a GPU? Or something like that?</p>
</blockquote>
<p>Yes, the graph is built as forward is computed. The root node is simply the node passed to backward.</p>
<blockquote>
<p>The last question is about the order of enqueuing nodes when a thread executes a computational graph.</p>
</blockquote>
<p>If there is a single thread, the order is based on (1) reverse of the original forward + (2) accumulate grad nodes have priority</p>

fengkeyleaf: <p>Hi soulitzer,</p>
<p>Thanks for your explanation.</p>
<p>So in other words, the order of enqueuing nodes is deterministic when there is one thread while it is indeterminism if there are multiple threads and they are exchanging date, like the case you mentioned?</p>
<p>Also, are there in-depth materials about the two points, reverse of forward and grad priority, that I can look into?</p>
<p>regards,</p>

soulitzer: <blockquote>
<p>So in other words, the order of enqueuing nodes is deterministic when there is one thread while it is indeterminism if there are multiple threads and they are exchanging date, like the case you mentioned?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>Also, are there in-depth materials about the two points, reverse of forward and grad priority, that I can look into?</p>
</blockquote>
<p>Not sure, but some more info - sequence_nr is incremented on per thread basis, new threads begin from 0. You can query b.grad_fn._sequence_nr() to observe this value. Grad acc is prioritized by setting its sequence_nr to int max.</p>

fengkeyleaf: <p>Got it, thanks for your time and patient! I’ll dig into what you just mentioned.</p>