PyTorch contro Tensorflow desideroso

Google ha recentemente incluso nelle build notturne di tensorflow la sua modalità Eager , un'API imperativa per accedere alle capacità di calcolo di tensorflow.

In che modo il desideroso di Tensorflow si confronta con PyTorch?

Alcuni aspetti che potrebbero influenzare il confronto potrebbero essere:

• Vantaggi e svantaggi di desideroso a causa della sua eredità del grafico statico (ad esempio nomi nei nodi).
• Limitazioni intrinseche di una delle due che l'altra non ha.
• Aree in cui una di esse necessita di miglioramenti (ad es. Completezza delle funzionalità, ottimizzazioni computazionali).
• Differenze ecosistemiche (ad es. Tensorboard?).

Nota 1: Yaroslav Bulatov ha scritto una recensione sulle belle caratteristiche di eager .

Nota2: in una domanda precedente , ho richiesto un confronto tra PyTorch e Tensorflow Fold. A quel tempo, mi è sembrato che Fold potesse affrontare PyTorch grazie al supporto di Google. Ho sbagliato molto: alla fine, Google stesso ha abbandonato Fold a favore di Eager. Capisco che ciò era dovuto a limiti intrinseci nella normale API di tensorflow che hanno portato Fold a non essere molto amichevole, il che ha limitato la sua adozione.

Uno dei vantaggi chiave che uso molto è che è compatibile con pdb, quindi

pdb.set_trace # To the rescue

Permette l'uso di strutture dati python

e usiamo il flusso di controllo pitonico invece di usare i principali equivalenti tf.

Inoltre permette di evitare problemi di metaprogrammazione come il "caricamento lento" e l'aggiunta di un sacco di operazioni al mio grafico. Somiglianze anche autograd