.. _sec_async:
Computação Assíncrona
=====================
Os computadores de hoje são sistemas altamente paralelos, consistindo em
vários núcleos de CPU (geralmente várias *threads* por núcleo), vários
elementos de processamento por GPU e, muitas vezes, várias GPUs por
dispositivo. Resumindo, podemos processar muitas coisas diferentes ao
mesmo tempo, geralmente em dispositivos diferentes. Infelizmente, Python
não é uma ótima maneira de escrever código paralelo e assíncrono, pelo
menos não com alguma ajuda extra. Afinal, o Python é de thread único e é
improvável que isso mude no futuro. Estruturas de aprendizado profundo,
como MXNet e TensorFlow, utilizam um modelo de programação assíncrona
para melhorar o desempenho (o PyTorch usa o próprio programador do
Python, levando a uma compensação de desempenho diferente). Para
PyTorch, por padrão, as operações de GPU são assíncronas. Quando você
chama uma função que usa a GPU, as operações são enfileiradas no
dispositivo específico, mas não necessariamente executadas até mais
tarde. Isso nos permite executar mais cálculos em paralelo, incluindo
operações na CPU ou outras GPUs.
Portanto, entender como a programação assíncrona funciona nos ajuda a
desenvolver programas mais eficientes, reduzindo proativamente os
requisitos computacionais e as dependências mútuas. Isso nos permite
reduzir a sobrecarga de memória e aumentar a utilização do processador.
Começamos importando as bibliotecas necessárias.
.. raw:: html
.. raw:: html
.. code:: python
import os
import subprocess
import numpy
from mxnet import autograd, gluon, np, npx
from mxnet.gluon import nn
from d2l import mxnet as d2l
npx.set_np()
.. raw:: html
.. raw:: html
.. code:: python
import os
import subprocess
import numpy
import torch
from torch import nn
from d2l import torch as d2l
.. raw:: html
.. raw:: html
.. raw:: html
Para um aquecimento, considere o seguinte problema brinquedo - queremos
gerar uma matriz aleatória e multiplicá-la. Vamos fazer isso no NumPy e
no MXNet NP para ver a diferença.
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
with d2l.Benchmark('numpy'):
for _ in range(10):
a = numpy.random.normal(size=(1000, 1000))
b = numpy.dot(a, a)
with d2l.Benchmark('mxnet.np'):
for _ in range(10):
a = np.random.normal(size=(1000, 1000))
b = np.dot(a, a)
.. parsed-literal::
:class: output
numpy: 0.9818 sec
mxnet.np: 0.0048 sec
Isso é ordens de magnitude mais rápido. Pelo menos parece que sim. Uma
vez que ambos são executados no mesmo processador, algo mais deve estar
acontecendo. Forçar o MXNet a terminar toda a computação antes de
retornar mostra o que aconteceu anteriormente: a computação está sendo
executada pelo *back-end* enquanto o *front-end* retorna o controle ao
Python.
.. code:: python
with d2l.Benchmark():
for _ in range(10):
a = np.random.normal(size=(1000, 1000))
b = np.dot(a, a)
npx.waitall()
.. parsed-literal::
:class: output
Done: 0.9211 sec
De um modo geral, o MXNet possui um front-end para interação direta com
os usuários, por exemplo, via Python, bem como um *back-end* usado pelo
sistema para realizar a computação. Conforme mostrado em: numref:
``fig_frontends``, os usuários podem escrever programas MXNet em várias
linguagens de front-end, como Python, R, Scala e C ++. Independentemente
da linguagem de programação de front-end usada, a execução de programas
MXNet ocorre principalmente no *back-end* de implementações C ++. As
operações emitidas pela linguagem do front-end são passadas para o
back-end para execução. O back-end gerencia seus próprios threads que
continuamente coletam e executam tarefas enfileiradas. Observe que, para
que isso funcione, o *back-end* deve ser capaz de controlar as
dependências entre as várias etapas do gráfico computacional. Portanto,
não é possível paralelizar operações que dependem umas das outras.
.. raw:: html
.. raw:: html
.. code:: python
# warmup for gpu computation
device = d2l.try_gpu()
a = torch.randn(size=(1000, 1000), device=device)
b = torch.mm(a, a)
with d2l.Benchmark('numpy'):
for _ in range(10):
a = numpy.random.normal(size=(1000, 1000))
b = numpy.dot(a, a)
with d2l.Benchmark('torch'):
for _ in range(10):
a = torch.randn(size=(1000, 1000), device=device)
b = torch.mm(a, a)
.. parsed-literal::
:class: output
numpy: 0.8409 sec
torch: 0.0011 sec
Isso é ordens de magnitude mais rápido. Pelo menos parece que sim. O
produto de ponto Numpy é executado no processador cpu enquanto A
multiplicação da matriz de Pytorch é executada no gpu e, portanto, o
último espera-se que seja muito mais rápida. Mas a enorme diferença de
tempo sugere que algo mais deve estar acontecendo. Por padrão, as
operações da GPU são assíncronas no PyTorch. Forçando PyTorch a terminar
todos os cálculos antes de retornar os programas, o que aconteceu
anteriormente: o cálculo está sendo executado pelo backend enquanto o
front-end retorna o controle para Python.
.. code:: python
with d2l.Benchmark():
for _ in range(10):
a = torch.randn(size=(1000, 1000), device=device)
b = torch.mm(a, a)
torch.cuda.synchronize(device)
.. parsed-literal::
:class: output
Done: 0.0023 sec
Em termos gerais, o PyTorch tem um *front-end* para interação direta com
os usuários, por exemplo, via Python, bem como um *back-end* usado pelo
sistema para realizar a computação. Conforme mostrado em: numref:
``fig_frontends``, os usuários podem escrever programas PyTorch em
várias linguagens de *front-end*, como Python e C ++. Independentemente
da linguagem de programação de frontend usada, a execução de programas
PyTorch ocorre principalmente no backend de implementações C ++. As
operações emitidas pela linguagem do *front-end* são passadas para o
*back-end* para execução. O *back-end* gerencia suas próprias threads
que continuamente coletam e executam tarefas enfileiradas. Observe que
para que isso funcione, o *back-end* deve ser capaz de rastrear as
dependências entre várias etapas no gráfico computacional. Portanto, não
é possível paralelizar operações que dependem umas das outras.
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
x = np.ones((1, 2))
y = np.ones((1, 2))
z = x * y + 2
z
.. parsed-literal::
:class: output
array([[3., 3.]])
.. raw:: html
.. raw:: html
.. code:: python
x = torch.ones((1, 2), device=device)
y = torch.ones((1, 2), device=device)
z = x * y + 2
z
.. parsed-literal::
:class: output
tensor([[3., 3.]], device='cuda:0')
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
with d2l.Benchmark('waitall'):
b = np.dot(a, a)
npx.waitall()
with d2l.Benchmark('wait_to_read'):
b = np.dot(a, a)
b.wait_to_read()
.. parsed-literal::
:class: output
waitall: 0.0366 sec
wait_to_read: 0.0066 sec
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
with d2l.Benchmark('numpy conversion'):
b = np.dot(a, a)
b.asnumpy()
with d2l.Benchmark('scalar conversion'):
b = np.dot(a, a)
b.sum().item()
.. parsed-literal::
:class: output
numpy conversion: 0.0216 sec
scalar conversion: 0.0323 sec
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
with d2l.Benchmark('synchronous'):
for _ in range(1000):
y = x + 1
y.wait_to_read()
with d2l.Benchmark('asynchronous'):
for _ in range(1000):
y = x + 1
y.wait_to_read()
.. parsed-literal::
:class: output
synchronous: 0.1225 sec
asynchronous: 0.0829 sec
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
def data_iter():
timer = d2l.Timer()
num_batches, batch_size = 150, 1024
for i in range(num_batches):
X = np.random.normal(size=(batch_size, 512))
y = np.ones((batch_size,))
yield X, y
if (i + 1) % 50 == 0:
print(f'batch {i + 1}, time {timer.stop():.4f} sec')
net = nn.Sequential()
net.add(nn.Dense(2048, activation='relu'),
nn.Dense(512, activation='relu'), nn.Dense(1))
net.initialize()
trainer = gluon.Trainer(net.collect_params(), 'sgd')
loss = gluon.loss.L2Loss()
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
def get_mem():
res = subprocess.check_output(['ps', 'u', '-p', str(os.getpid())])
return int(str(res).split()[15]) / 1e3
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
for X, y in data_iter():
break
loss(y, net(X)).wait_to_read()
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
mem = get_mem()
with d2l.Benchmark('time per epoch'):
for X, y in data_iter():
with autograd.record():
l = loss(y, net(X))
l.backward()
trainer.step(X.shape[0])
l.wait_to_read() # Barrier before a new batch
npx.waitall()
print(f'increased memory: {get_mem() - mem:f} MB')
.. parsed-literal::
:class: output
[04:02:35] src/base.cc:49: GPU context requested, but no GPUs found.
batch 50, time 4.2066 sec
batch 100, time 8.2570 sec
batch 150, time 12.1179 sec
time per epoch: 12.1193 sec
increased memory: 9.424000 MB
.. raw:: html
.. raw:: html
.. raw:: html
.. code:: python
mem = get_mem()
with d2l.Benchmark('time per epoch'):
for X, y in data_iter():
with autograd.record():
l = loss(y, net(X))
l.backward()
trainer.step(X.shape[0])
npx.waitall()
print(f'increased memory: {get_mem() - mem:f} MB')
.. parsed-literal::
:class: output
batch 50, time 0.1447 sec
batch 100, time 0.2817 sec
batch 150, time 0.3972 sec
time per epoch: 12.0468 sec
increased memory: 6.156000 MB
.. raw:: html
.. raw:: html
.. raw:: html
`Discussions `__
.. raw:: html
.. raw:: html