原文地址:
https://blog.csdn.net/seekiu/article/details/47397067
隨着 Julia 1.0版本的推出,人工智能圈子比較炸鍋, 好像這門小眾語言要趕超Python了, 作為現在編程領域的大佬,Python最被人詬病的就是運算性能,恰巧 Julia 是已高性能並行計算為主打,並且兼顧了語法簡潔和動態性,好奇之下找了找網上的相關資料,發現確實是太小眾了,最后發現了下面這篇文章,覺得有些用處。
以下為原文內容:
上一篇博文中推薦了 Python 的 JIT 編譯器 numba,這兩天又用空余的時間嘗試了一下最近的一個新興語言 Julia。Julia 的目標設定得很高,未來是要成為一個速度上接近甚至超過 Fortran/C 這樣的傳統語言的通用編程語言。然而就我這兩天很初步的嘗試結果看來,它也許有這個能力,但至少目前,對工程計算的人來說,還沒有達到 production-ready 的程度。(當然,這只是基於我個人的編程經驗和需求的結論,很可能不適用於其他人。而且Julia本身是一門相對年輕的語言,很值得持續關注。)
之所以這樣說,有三個方面的理由:
-
作為一個動態語言,它的 JIT 編譯器(在很多情況下)還沒有智能到,讓我可以同時享受動態語言的便利和它的速度優勢。例如最近我在試用 Julia 時最先嘗試的就是把原來用 Numba 寫的函數重寫一遍,然而發現結果非常不好。Julia 版本的函數執行速度相當於純 Python 的速度,與 Numba 版本相差三個數量級,占用的內存也異常地大。后來發現,最主要的原因是三層嵌套循環中,循環長度我按 Python 的習慣定義為變量,而在 Julia 中不變的全局量最好聲明為常量。僅僅這個修改,讓速度提升了兩個數量級,但還不及 numba 的速度。進一步的測試還可以通過一些細小的地方來進一步提升速度,如這篇文章做的那樣,最終高度優化之后速度也許可以達到接近 Fortran。但是,如果要這樣做,為什么不干脆用 Fortran 呢?相比之下,numba 的可用性就要高太多了。不過畢竟它現在的穩定版本還是0.3.10,還需要再給它一點時間發展成熟。
-
作為一個新興、小眾的語言,相關的工具鏈還太弱了。沒有合格的 IDE,Juno 在我看來現在連半成品都還算不上。包管理似乎是用的 Git,有時會出一些奇怪的問題,這時候用
Pkg
倒還不如手動去管理。調試程序也比較痛苦,一方面是很多錯誤信息跟沒給差不多,像我這種不熟悉的人基本只能用print
一半一半地查,另一方面是相關的調試工具也還不夠好用。 -
文檔、相關信息還太少。已經有不少人開始使用 Julia,但網上公開的信息中,官方的文檔還比較簡陋,其他用戶貼出的博客也很少。這導致在遇到問題的時候,很難快速地難過 Google 直接得到問題的答案,而往往需要在社區中等待圈內人士的解答。
另外一個對 Julia 印象不太好的是,官網給出的 benchmark 沒有多少參考價值,至少其結果中 Python 和 Matlab 都很有問題,多半是單純地逐行翻譯出來的程序。這就跟我把 numba 的程序直接翻譯成 Julia,然后得出結論它很慢一樣,是不公平的比較。
不管怎么樣,Julia 目前看來還是值得持續關注的,但是目前,我還不會考慮把它作為主要的計算語言。