盡管如此，我還是認(rèn)為PyTorch對研究者更加友好，更適合快速實(shí)現(xiàn)新方法，并且改進(jìn)了與C++的兼容性。TensorFlow的優(yōu)勢仍然是Google生態(tài)系統(tǒng)（TFLite，Android的TFLite，TPU等）的集成。但是，無論我使用哪個(gè)，仍然存在很多問題，這些問題主要與Python相關(guān)。

PyTorch聲稱它不是用于C++框架的API，然而，一旦構(gòu)建它，和Cython以及Numba一起使用，就可以了。如果我們通過名為TensorFlow.jl的Julia API 使用TensorFlow，那么我們就不再面臨任何懸而未決的問題，因?yàn)镴ulia的內(nèi)存管理要好得多。

更一般而言，深度學(xué)習(xí)模型的許多緩慢現(xiàn)象是由內(nèi)存I/O引起的。不管我們是做對象檢測還是關(guān)鍵點(diǎn)注釋，以及想要實(shí)時(shí)顯示，這些幾乎都沒問題。只需考慮在視頻流上運(yùn)行的任何內(nèi)容。與加快應(yīng)用于此的深度學(xué)習(xí)模型速度相比，克服內(nèi)存I/O問題要付出更多的努力（這是我的部分日常工作）。

那么，深度學(xué)習(xí)框架發(fā)展會走向何方呢？自動(dòng)區(qū)分仍然是一個(gè)巨大的問題，尤其是對于真正罕見的功能。使用Swift進(jìn)行TensorFlow實(shí)驗(yàn)，PyTorch？誰知道呢，他們要往哪里前進(jìn)。

我不是C++的忠實(shí)擁護(hù)者（我更喜歡C而不是C++），因?yàn)樗菀壮鲥e(cuò)，可能導(dǎo)致安全問題。即使人們可能傳輸了所有的編碼采訪而構(gòu)建了有缺陷的C++軟件（是的，我強(qiáng)烈反對編碼采訪），人們還是應(yīng)該正確地學(xué)習(xí)它，反復(fù)強(qiáng)調(diào)是無濟(jì)于事的。

在HPC（高性能計(jì)算）中，許多軟件已經(jīng)或者正從FORTRAN遷移到C++，我不明白。因?yàn)閷⒔?jīng)過良好測試的FORTRAN代碼遷移到（未經(jīng)測試的）C++對我來說沒有任何意義。改變一種編程語言到另一種極其相似的語言，為什么多此一舉？我仍然認(rèn)為，從長遠(yuǎn)來看，Rust（適用于系統(tǒng)級和GUI的所有產(chǎn)品）和Julia（適用于機(jī)器學(xué)習(xí)）的組合將獲得成功。

目前正在使用的是什么？好吧，我已經(jīng)從TensorFlow/Keras切換到以PyTorch為主，因?yàn)槲倚枰嗟淖远x/非標(biāo)準(zhǔn)功能。但這并不意味著我不再使用TensorFlow/Keras。在2020年，我希望朝著僅使用Julia框架邁進(jìn)。