PyTorch，你是不是想用Julia？不，我们还想要Python的生态

本文主要是介绍PyTorch，你是不是想用Julia？不，我们还想要Python的生态，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

人生苦短，我用 Python。」这是 Python 开发领域广泛流传的一句话。在过去的几年中，Python 也的确凭借其在易用性、生态等方面的优势一路高歌猛进，在很多编程语言排行榜中稳居前三。

但伴随着 Julia 等新势力的崛起，这种局面正在发生变化。在前段时间出炉的「Stack Overflow 2021 全球开发者调查报告」中，Python 受开发者喜爱程度仅排第六，而 Julia 则排在了第五。虽然生态等方面依然存在不足，但毋庸置疑，Julia 已经成为 Python 有力的竞争对手，其竞争优势包括速度快、简洁等。在 Julia 中，我们可以用类似 Python 的优美语句获得类似 C 的性能。

最近，这种趋势甚至影响到了主流深度学习框架对编程语言的选择，比如 PyTorch：

「PyTorch 将走向何方？为什么它越来越像 Julia，但又不完全像？」这是 PyTorch 核心开发人员 Edward Z. Yang 参与讨论的一个问题。在这个问题下方，他回答道：

我们曾经开玩笑地说：下一个版本的 PyTorch 是用 Julia 编写的。之所以废弃了 Lua Torch 而主要使用 Python 编写的 PyTorch，一个重要的原因是想利用 Python 庞大的生态系统。直到今天，都很难有一种新语言能够克服 Python 的网络效应。

然而，最近我一直在思考我们在 PyTorch 中进行的各种项目，包括：

functorch：直接用 Python 编写像 vmap/grad 这样的转换，以前只能作为调度程序的 C++ 扩展；

FX：图形转换，以前只能借助 C++ TorchScript 完成；

Python autograd implementation：对 autograd 实现做了实验性更改，以前只能用 C++ 进行。

这些项目都有一个共同点：有些功能以前只能用 C++ 实现，而现在 PyTorch 使得用 Python 完成这些功能成为可能，提升了 hackability，并让开发变得更加简易。

PyTorch 以前主要是用 Python 编写的，后来我们将所有内容都移到了 C++，以使其运行得更快。因此，我们越来越多地处于这样一种情况：我们想要拥有这块蛋糕（hackability），同时吃掉它（性能）。

这与 Julia 讲了近十年的故事不谋而合。Julia 的开发团队一直认为：

一种语言必须能被编译为高效的代码，Julia 语言添加了一些限制（类型稳定性），以确保这一点；

一种语言必须允许后续可扩展（多重派发，multiple dispatch），Julia 语言围绕 JIT 编译组织生态系统使这一点成为可能。

上述两个特性的结合为用户提供了一个兼具动态语言灵活性（可扩展性）和静态语言性能（高效代码）的系统。

实际上这也是 PyTorch 一直追求的。我们已经从 Julia 语言中获得了很多灵感，例如 ATEN 的作者 Zachary DeVito 将 PyTorch 调度器中多重派发的设计灵感归功于 Julia。

总体来说，我认为 Julia 可以作为一个非常强大的愿景，并且相比于 Julia，PyTorch 本身也有一些优势。例如 Julia 经常称用户可以直接使用数学运算编写循环并将其编译为高效代码，而我们不需要尝试这样做，因为我们的内核非常复杂，在任何情况下都能实现最佳的低级别实现。

为什么不直接使用 Julia？因为我们既想要 Julia 的愿景，也想要 Python 强大的生态系统。这个方向具有巨大的潜力，但我们也有很多要做的工作和许多未解决的设计问题。我对接下来的发展感到非常兴奋。

从这份回答我们可以看出，PyTorch 逐渐靠近 Julia 已成定势，但鉴于 Python 在生态系统方面的绝对优势，下一代 PyTorch 不太可能直接用 Julia 编写。

对于这一做法，有人表示非常不理解。ta 认为，以 PyTorch 的生态号召力，如果下一版他们直接宣布用 Julia，那么生态问题很快就会迎刃而解。

而且，长远来看，转向 Julia 似乎收益更高。

但也有人认为，PyTorch 的这种做法其实是为用户着想，即把麻烦留给自己，把简单留给用户，这是一种非常值得肯定的态度。

这篇关于PyTorch，你是不是想用Julia？不，我们还想要Python的生态的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！