如何对APL进行优化，使其在数组处理方面具有出色的性能？它执行的一些示例技巧和优化是什么？

Question

我感兴趣的是APL是如何在它所做的事情上如此高效的，以至于有时被基准测试为优于C。所以我很好奇，APL编译器做了哪些优化来使语言如此高效？

Answer 1

以下是一些如何做到这一点的示例：

blog

• Packed数组无栈遍历：video

• Vector位布尔值：video

• Hashed，documentation

• Special指令：video

• Pipelines数组：video

，

• ：blog，video，CRCs代码

与此相关的是，这些讨论了上述背后的原则：

• 根据运行时看到的数据模式以及懒惰/笨拙的APL如何完全跳过某些代码来选择算法：video
• Less通过读取整个简单数组来寻求延迟，并通过无分支代码避免分支预测失败：

(APL与这些想法保持一致，并鼓励使用这些风格，比许多其他语言更容易)。

Answer 2

就性能而言，您不能将两种语言(如C和APL)进行比较，因为性能在很大程度上取决于语言的实现和所使用的库。同一个C程序在一个平台上可能很慢，在另一个平台上可能很快。关键的一点是，性能几乎完全是给定语言实现的属性，而不是语言本身的属性。

在使用APL的情况下，可以将给定操作所需的CPU周期分为两部分:解释器开销(处理组成APL程序的标记)和原语(如加法、减法等)。在大多数APL解释器中，解释器的开销是相当小的(这意味着在这一部分上的优化不能获得太多的性能。Amdahls定律)。在早期的APL中(比如1970年)，情况就不同了。在当前的解释器中，APL原语的处理是在C/C++中实现的，因此部分CPU周期在性能方面与C相同(再次请记住，实现可能会有所不同)。

我在APL原语级别执行了一些基准测试(不同的标量函数，从简单的(整数加法)到不那么简单的(复杂的arcus cosinus)以及它们的外积)。有些令人惊讶的结果是，不同标量函数的性能不是由计算函数的复杂性决定的，而是由内存(包括缓存)的访问时间和CPU的分支预测决定的。例如，如果您在循环中执行相同的APL操作，则第二次迭代的速度通常是第一次的两倍，并且后续迭代将在大约第四次迭代后稳定下来(在i5-4570CPU上)。

测量值波动很大，这使得老式的性能测量(如解释器X的速度是解释器Y的两倍)变得毫无意义。

根据经验，如果APL程序的平均向量大小(即⍴，X)为20或更大，那么您可以完全忽略解释器开销，APL程序具有与可比C程序大致相同的性能。

APL比C更快的情况(理论上是不可能的)经常可以追溯到在C和APL中使用不同的算法。一个典型的实际示例是在一种情况下使用heapsort进行排序，而在另一种情况下使用快速排序。这也是实现的不同，而不是语言本身的不同。