Logtalk方法调用性能优化

Question

在玩 Logtalk 时，与普通 Prolog 相比，我的程序似乎用 Logtalk 对象执行的时间更长。我做了一个基准测试，比较了普通 Prolog 中简单谓词的执行与下面等效的 logtalk 对象封装：

%%
% plain prolog predicate
plain_prolog_simple :-
  fail.

%%
% object encapsulation
:- object(logtalk_obj).

    :- public([simple/0]).
    simple :-
      fail.

:- end_object.

这是我得到的：

?- benchmark(plain_prolog_simple).

Number of repetitions: 500000
Total time calls: 0.33799099922180176 seconds
Average time per call: 6.759819984436035e-7 seconds
Number of calls per second: 1479329.3346604244
true.

?- benchmark(logtalk_obj::simple).

Number of repetitions: 500000
Total time calls: 2.950408935546875 seconds
Average time per call: 5.90081787109375e-6 seconds
Number of calls per second: 169468.0333888435
true.

我们可以看到 logtalk_obj::simple call 比 plain_prolog_simple 调用慢。我使用 SWI Prolog 作为后端，我尝试设置一些日志对话标志，但没有成功。

编辑：我们可以找到 https://github.com/koryonik/logtalk-experiments/tree/master/benchmarks

的基准代码示例

怎么了？为什么会有这种性能差异？如何优化Logtalk方法调用？

Answer 1

简而言之，您正在 顶级 INTERPRETER 对 ::/2 目标的 Logtalk 编译进行基准测试。这是一个典型的基准测试错误。顶层的目标，无论是普通的 Prolog 目标、模块明确限定的谓词目标，还是消息发送目标，都将始终被解释，即即时编译。

在已编译 源文件中，您的消息发送目标的性能接近普通 Prolog，这是最常见的情况。请参阅 Logtalk 发行版中的 benchmarks 示例，了解避免上述陷阱的基准测试解决方案。

性能差距（普通 Prolog 和 Logtalk 目标之间）取决于所选的后端 Prolog 编译器。当可以进行静态绑定时，成熟的 Prolog VM（例如 SICStus Prolog 或 ECLiPSe）的差距可以忽略不计。然而，一些 Prolog VM（例如 SWI-Prolog）缺乏一些优化，这会使差距更大，特别是在紧密循环中。

P.S。 Logtalk 开箱即用，带有用于开发而非性能的设置配置。请特别参阅有关 optimize 标志的文档，应该为静态绑定优化打开该标志。

更新

从您存储库中的代码开始，假设 SWI-Prolog 作为后端编译器，尝试：

----- code.lgt -----
% plain prolog predicate
plain_prolog_simple :-
  fail.

% object encapsulation
:- object(logtalk_obj).

    :- public(simple/0).
    simple :-
      fail.

:- end_object.
--------------------

----- bench.lgt -----
% load the SWI-Prolog "statistics" library
:- use_module(library(statistics)).   

:- object(bench).

    :- public(bench/0).
    bench :-
        write('Plain Prolog goal:'), nl,
        prolog_statistics:time({plain_prolog_simple}).
    bench :-
        write('Logtalk goal:'), nl,
        prolog_statistics:time(logtalk_obj::simple).
    bench.

:- end_object.
---------------------

保存两个文件然后启动 Logtalk：

$ swilgt
...
?- set_logtalk_flag(optimize, on).
true.

?- {code, bench}.
% [ /Users/pmoura/Desktop/bench/code.lgt loaded ]
% (0 warnings)
% [ /Users/pmoura/Desktop/bench/bench.lgt loaded ]
% (0 warnings)
true.

?- bench::bench.
Plain Prolog goal:
% 2 inferences, 0.000 CPU in 0.000 seconds (69% CPU, 125000 Lips)
Logtalk goal:
% 2 inferences, 0.000 CPU in 0.000 seconds (70% CPU, 285714 Lips)
true.

time/1 谓词是元谓词。 Logtalk 编译器使用元谓词属性来编译 time/1 参数。 {}/1 控制结构是一个 Logtalk 编译器绕过。它确保其参数在普通 Prolog 数据库中按原样调用。

Answer 2

与提供 time/1 元谓词的 SWI-Prolog 和 YAP（可能是其他）一起使用的基准测试技巧是将此谓词与 Logtalk 的 <</2 调试控制构造和 logtalk 内置对象。使用 SWI-Prolog 作为后端编译器：

?- set_logtalk_flag(optimize, on).
...
?- time(true).  % ensure the library providing time/1 is loaded
...
?- {code}.
...
?- time(plain_prolog_simple).
% 2 inferences, 0.000 CPU in 0.000 seconds (59% CPU, 153846 Lips)
false.
?- logtalk<<(prolog_statistics:time(logtalk_obj::simple)).
% 2 inferences, 0.000 CPU in 0.000 seconds (47% CPU, 250000 Lips)
false.

快速解释，<</2 控制构造在调用它之前编译其目标参数。由于 optimize 标志被打开并且 time/1 是一个元谓词，它的参数被完全编译并且静态绑定用于消息发送。因此，我们在上面得到了相同数量的推论。因此，这个技巧允许您在 Logtalk 消息发送目标的顶层进行快速基准测试。

使用 YAP 类似但更简单，因为 time/1 是内置元谓词而不是 SWI-Prolog 中的库元谓词。

Answer 3

您还可以制作速度相当快的面向对象的解释器。 Jekejeke Prolog 有一个纯粹解释的 (::)/2 运算符。目前没有太多开销。这是测试代码：

Jekejeke Prolog 3, Runtime Library 1.3.0
(c) 1985-2018, XLOG Technologies GmbH, Switzerland

?- [user].

plain :- fail.

:- begin_module(obj).

simple(_) :- fail.

:- end_module.

这些是一些实际结果。普通调用和基于 (::)/2 运算符的调用之间没有如此大的区别。在引擎盖下，两个谓词查找都是内联缓存的：

?- time((between(1,500000,_), plain, fail; true)).
% Up 76 ms, GC 0 ms, Thread Cpu 78 ms (Current 06/23/18 23:02:41)
Yes

?- time((between(1,500000,_), obj::simple, fail; true)).
% Up 142 ms, GC 11 ms, Thread Cpu 125 ms (Current 06/23/18 23:02:44)
Yes

我们仍有开销，将来可能会被移除。它必须这样做，我们仍然为每个 (::)/2 调用做一个微型重写。但也许这会消失，我们正在努力。

编辑 23.06.2018： 我们现在有一个内置的 between/3 并且已经实施了一些优化。上图为尚未出炉的新样机预览

Logtalk方法调用性能优化

Logtalk method calls performance optimization

optimization

prolog

logtalk