Discussion B-Prolog

In this section we will provide a critical discussion of the comparison with the B-Prolog system. The newest release of the B-Prolog system is still slower than the former release 7.5#8 of the B-Prolog system. The average slow-down factor is around 160.8%. The test program with the least slow down factor is nrev with around 91.0%. The test program with the worst slow down factor is calc with around 225.2%

Picture 11: B-Prolog Performance

The pattern is much more balanced than the pattern for the other Prolog systems. Many of the test programs do not perform very differently from the average. What features could explain this behaviour? We cannot attribute this performance to jumbo instructions. Both B-Prolog [11] and SICStus Prolog [12] are known to do the merging and specialization of instructions. But we have the problem that this technology probably only applies to compiled code and not to interpreted code.

B-Prolog is based on TOAM which does eager environment allocation. The eager environ-ment allocation leads to a degradation in the case of mtak [10]. Further the last call optimiza-tion in the TOAM is directly targeted towards reusing the eagerly created environments [11]. The optimization seems to work well when there are fewer goals between the head and the last call. Maybe this explains the better performance for crypt and qsort.

The performance of the calc test program should be much better. B-Prolog does not place additional unification steps subsequent to DCG actions into the body of a grammar rule to make it steadfast. Therefore it should not be subject to the corresponding performance penalty. But it does not integrate terminals into the head. Instead it handles these terminals via a list equation. This could give a small performance penalty again if list equation is not optimized away since it would prevent first argument indexing.

Comments