The naive reverse reality check (Was: Is Scryer Prologs failure measurable?)

But Scryer Prolog must nevertheless have somewhere
some good genes. Even it posted about a Prolog compiler
written in Prolog itself. Lets make some reality check:
/* Ichiban Prolog */
real    0m39.635s
user    0m59.684s
sys     0m7.891s
/* Dogelog Player for Java */
?- time((between(1,6001,_), nrev, fail; true)).
% Zeit 588 ms, GC 0 ms, Lips 5113263, Uhr 11.08.2024 10:47
true.
/* Trealla Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% Time elapsed 0.549s, 3000503 Inferences, 5.468 MLips
    true.
/* Scryer Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
    % CPU time: 0.302s, 3_024_526 inferences
    true.
/* SWI-Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% 2,994,499 inferences, 0.078 CPU in 0.089 seconds (88% CPU, 38329587 Lips)
true.
Dogelog Player has a Prolog compiler written in
Prolog itself. But the limiting factor is of course
always the runtime engine itself, that executes the
compiled code. You can inline and optimize whatever
you want, if the runtime engine, its architecture,
has some limitations performance wise, you won't
see aby speed. I don't know yet whether I will beat
SWI-Prolog in this test case ever in the near future?
Especially with some cheap effort?
Mild Shock schrieb:

 Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:
 - New tickets: 7 new tickets
- Closed tickets: 2 closed tickets
 To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.