内置 Prolog 谓词 (is)/2 的性能

Question

更新：11.6.2016

我在 SICStus Prolog 4.3.2 中观察到的令人费解的性能差异在最近发布的 SICStus Prolog 4.3.3 中完全消失了。 荣誉！

我更新了下面的“运行时”表以包括 SICStus Prolog 4.3.3。亮点包括：

• (is)/2 比以前快了 10 倍。
• val_of/2 的速度也非常快，几乎提高了 2 倍！

MEGO;-)

---

当 answering 问题“Size Procedure in Prolog Language” SO-user @ThanosTintinidis 提出了一个非常简单的方法¹介绍初学者导出length/2：

[...] 另请注意，E 仅需要实例化，因为 is 将评估表达式。你可以这样写：

大小（[]，0）。
尺寸([_|Xs], 1+E) :- 尺寸(Xs, E)。

如果你这么称呼它：

?- size([_,_], E)。
E = 1+(1+0)。

很有趣，不是吗？您可能想要评估最后一个E，即调用?- size([1,2], E), N is E。 [...]

有趣吗？ 非常有趣！ 许多有趣的实验摆在面前：

• 左倾与右倾树

  list_sizL([], 0)。 % l左倾 list_sizL([_|Es], N+1) :- list_sizL(Es,N)。 list_sizR([], 0)。 % r右倾 list_sizR([_|Es], 1+N) :- list_sizR(Es,N)。

• 内置(is)/2 vs val_of/2

  val_of(V, E) :- ( E = E1+E2 -> val_of(V1, E1), val_of(V2, E2), V 是 V1+V2 ;数字（E）-> V = E ）。

为了测量运行时间，我使用不同的 Prolog 处理器运行了 go(2000000)²：

去（左）：- 长度（Xs，L）， 成员（B_2，[list_sizL，list_sizR]）， 呼叫（B_2，Xs，E）， 成员（P_2，[是，val_of]）， call_time(呼叫(P_2,N,E), T), ( L = N -> writeq(B_2+P_2=T), nl ; throw(up) )。

在Intel Core i7-4700MQ 上，我使用 SICStus 和 SWI 观察到以下运行时：

| SWI | SICStus | SICStus | | 7.3.20 | 4.3.2 | 4.3.3 | -------------------+--------+---------+---------| list_sizL + (is) | 208 毫秒 | 650 毫秒 | 60 毫秒 | 3.4 倍 list_sizL + val_of | 381 毫秒 | 100 毫秒 | 60 毫秒 | 6.3 倍 -------------------+--------+---------+---------| list_sizR + (is) | 88 毫秒 | 660 毫秒 | 70 毫秒 | 1.2x list_sizR + val_of | 346 毫秒 | 100 毫秒 | 60 毫秒 | 5.7 倍 -------------------+--------+---------+---------|

我对这些（可重现的）结果感到困惑......有人可以告诉我发生了什么吗？

---

^{脚注 1：为了简洁和可读性，变量名称稍作修改。
脚注 2：运行 SWI-Prolog 7.3.20带有合适的命令行参数swipl -G2G -L2G -O。}

Answer 1

我可以确认一个令人惊讶的事实，即在 SICStus Prolog 中，当表达式是一个大的复合词时，val_of/2 比 is/2 快得多，即当 is/2 解释一个表达式时。

在当前的 SICStus 实现中，当算术运算符的参数不是数字时，is/2 需要转义到 Prolog 代码。在解释深层表达式时，所有参数都会以递归方式进行转义，这比 val_of/2 所做的要慢得多，即从普通的 Prolog 到 Prolog 调用。

我对潜在问题进行了概念验证修复，它使上述程序中的is/2 案例与val_of/2 的速度大致相同。此更改已包含在当前版本的 SICStus Prolog (4.3.3) 中。

Answer 2

您正在比较(is)/2 的两个非常不同的实现。 SWI 在实际评估之前检测实例化错误和循环表达式。 SICStus 没有。试试这个：

?- E=(1/0)+_, X is E.
?- E=(1/0)+E, X is E.

SWI 产生一个实例化错误和一个类型错误（因为无限树），而 SICStus 总是评估 1/0 并在这两种情况下产生一个评估错误。而且（至少对于这个例子来说），两者都符合要求。

评估两个树结构的速度差异是由于 SWI 中 ground/1 和 acyclic_term/1 中的尾递归优化。当前算法使用堆栈并从左到右访问参数。因此，嵌套在右侧的树需要恒定的辅助空间，因此速度要快得多。

SICStus 将 Deutsch-Schorr-Waite 用于 acyclic_term/1 和 ground/1，因此没有显式堆栈，因此没有 TRO。至少，左右两边的速度差不多。

Answer 3

简单地说，我认为 SWI-Prolog 对算术进行了更多优化，而 SICStus 对一般控制流有更好的代码生成。

也许可以通过 Partial Evaluation 从 SWI-Prolog 获得更好的性能，Pereira-Shieber 在 Prolog and Natural-Language Analysis 的第 6 章中很好地介绍了这一点。

您还应该给 YAP 一个机会：据报道，它是最快的基于 WAM 的 Prolog。我记得 Jan Wielemaker 在 SWI-Prolog 列表中指出，大部分 YAP 速度是通过大量重写获得的——比如说内联。我认为它建立在（当然实施得很好）部分评估的基础上。