为什么要鼓励朱莉娅的脱胎换骨？

Question

似乎朱莉娅鼓励写去写代码。甚至还有一个套餐试图为您做到这一点。

我的问题是为什么？

首先，从用户体验的角度来看，向量化代码更简洁(代码更少，bug可能性更小)、更清晰(因此更易于调试)、更自然的代码编写方式(至少对于来自科学计算背景的人，Julia试图迎合他们)。能够编写像vector'vector或vector'Matrix*vector这样的东西是非常重要的，因为它对应于实际的数学表示，这就是科学计算人员在他们的头脑中(而不是在嵌套循环中)的想法。我讨厌这样的事实，这并不是最好的方式来写这篇文章，并且把它转换成循环会更快。

目前看来，在编写快速代码的目标与简洁/清晰的代码之间似乎存在冲突。

第二，这是甚麽技术原因？好的，我知道矢量化代码会创建额外的临时代码，等等，但是向量化函数(例如，broadcast()、map()等)具有多线程的潜力，我认为多线程的好处可以超过时间性函数的开销和向量化函数的其他缺点，使它们比循环的正则函数更快。

在Julia中，当前向量化函数的实现是否在幕后进行隐式多线程处理？

如果没有，是否有工作/计划向矢量化函数添加隐式并发，并使它们比循环更快？

Answer 1

为了方便阅读，我决定把上面的评论变成一个答案。

朱莉娅背后的核心发展声明是“我们很贪婪”。核心开发人员希望它能做所有的事情，并且做得很快。特别要注意的是，该语言应该解决“两种语言问题”，在这一阶段，它似乎将在1.0版点击时完成这一任务。

在您的问题的上下文中，这意味着您询问的所有内容要么已经是Julia的一部分，要么计划在1.0版中完成。

特别是，这意味着如果您的编程问题导致代码向量化，那么编写向量化代码。如果使用循环更自然，那么就使用循环。

到v1.0命中时，大多数矢量化代码应该比Matlab中的等效代码更快或更快。在许多情况下，这一发展目标已经实现，因为许多向量/矩阵操作在Julia发送到适当的BLAS例程由编译器。

关于多线程，本地多线程目前正在为Julia实现，我相信主分支上已经有了一组实验性的例程。相关的问题页面是这里。由于Julia调用BLAS，某些向量/矩阵运算的隐式多线程在理论上已经可用。我不确定它是否是默认打开的。

但是请注意，在MATLAB中，许多矢量化操作仍然(目前)要快得多，因为MATLAB多年来一直在编写专门的多线程C库，然后在引擎盖下调用它们。一旦Julia有了原生多线程，我希望Julia会超过MATLAB，因为到那时，整个dev社区都可以浏览标准的Julia包，并在可能的情况下升级它们以利用本地多线程。

相反，MATLAB没有原生多线程处理，所以您依赖Mathworks以底层C库的形式提供专门的多线程例程。

Answer 2

您可以和编写vector'*matrix*vector (如果您更喜欢标量输出，则可能是dot(vector, matrix*vector) )。对于矩阵乘法之类的东西，使用向量化表示法要好得多，因为它调用底层BLAS库，这些库比基本上任何语言/编译器组合生成的代码都更加优化。

在其他地方，正如您所说的，您可以通过避免临时中间产物而受益于开发:例如，如果x是一个载体，则表达式

y = exp(x).*x + 5

创建3个临时向量:一个用于a = exp(x)，一个用于b = a.*x，另一个用于y = b + 5。相比之下，

y = [exp(z)*z+5 for z in x]

不创建临时中间产物。由于julia中的循环和理解速度很快，编写去捕获版本并没有什么坏处，实际上它的性能应该会稍微好一点(特别是在适当的情况下使用性能注释(如@simd ))。

线程的出现可能会改变一些事情(使向量化的exp比“天真的”exp更快)，但总的来说，我认为这是一个“正交”问题: julia可能会使多线程变得非常容易使用，以至于您自己可能会使用多个线程编写操作，因此向量化的“库”例程仍然没有比您自己编写的代码更好的优势。换句话说，您可能使用多个线程，但仍然编写开发代码以避免那些临时代码。

从长远来看，“足够聪明的编译器”可能会通过自动删除其中一些操作来避免临时人员，但这是一条比看起来更困难的路线，可能会给粗心大意的人设置陷阱。

然而，你所说的“向量化代码总是更简洁，更容易理解”的说法是不正确的:很多时候，在编写Matlab代码时，你必须走到极致，才能想出一种矢量化的编写方法--在考虑循环时，实际上是简单的操作。您可以在邮件列表中搜索无数的示例；我记得如何利用Julia找到矩阵中的连通分量也是如此。