SICStus Prolog マニュアルを引用するには:
論理プログラミングの背後にある通常の数学的理論では、循環項の作成が禁止されており、変数が項と統合されるたびに発生チェックを行う必要があります。残念ながら、発生チェックは非常にコストがかかるため、Prologはプログラミング言語として実用的ではありません。
ただし、これらのベンチマーク(The Prolog のもの) を実行したところ、SWI Prolog で発生チェック (OC) のオンとオフの間にかなり小さな違い (20% 未満) が見られました。
OC がオフ::- set_prolog_flag(occurs_check, false).で.swiplrc(再起動)
?- run_interleaved(10).
% 768,486,984 inferences, 91.483 CPU in 91.483 seconds (100% CPU, 8400298 Lips)
true.
?- run(1).
'Program' Time GC
================================
boyer 0.453 0.059
browse 0.395 0.000
chat_parser 0.693 0.000
crypt 0.481 0.000
fast_mu 0.628 0.000
flatten 0.584 0.000
meta_qsort 0.457 0.000
mu 0.523 0.000
nreverse 0.406 0.000
poly_10 0.512 0.000
prover 0.625 0.000
qsort 0.574 0.000
queens_8 0.473 0.000
query 0.494 0.000
reducer 0.595 0.000
sendmore 0.619 0.000
simple_analyzer 0.620 0.000
tak 0.486 0.000
zebra 0.529 0.000
average 0.534 0.003
true.
OC がオン::- set_prolog_flag(occurs_check, true).で.swiplrc(再起動)
?- run_interleaved(10).
% 853,189,814 inferences, 105.545 CPU in 105.580 seconds (100% CPU, 8083669 Lips)
true.
?- run(1).
'Program' Time GC
================================
boyer 0.572 0.060
browse 0.618 0.000
chat_parser 0.753 0.000
crypt 0.480 0.000
fast_mu 0.684 0.000
flatten 0.767 0.000
meta_qsort 0.659 0.000
mu 0.607 0.000
nreverse 0.547 0.000
poly_10 0.541 0.000
prover 0.705 0.000
qsort 0.660 0.000
queens_8 0.491 0.000
query 0.492 0.000
reducer 0.867 0.000
sendmore 0.629 0.000
simple_analyzer 0.757 0.000
tak 0.550 0.000
zebra 0.663 0.000
average 0.634 0.003
true.
これらのベンチマークは実際の使用状況を表していませんか? (「かなり代表的」であるために特別に選ばれたことをどこかで読んだことを覚えています) SWI Prolog は、SICStus の人々が気付いていない、OC のコストを小さくするいくつかの最適化トリックを実装していますか? もしそうなら、それらは公開されていますか？（90年代からこれに関する論文をたくさん見つけましたが、最新のものかどうかはわかりません）