Sujet : Re: The naive reverse reality check (Was: Is Scryer Prologs failure measurable?)
De : janburse (at) *nospam* fastmail.fm (Mild Shock)
Groupes : comp.lang.prologDate : 11. Aug 2024, 11:05:48
Autres entêtes
Message-ID : <v99utc$12eip$2@solani.org>
References : 1 2 3
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2
But I am nevertheless convinced Scryer Prolog
is dead. These good genes only appeared recently.
But I was comparing oranges and apples.
I compared Dogelog Player which has garbage
collection to a Prolog system like Scryer Prolog
which doesn't have garbage collection.
A Prolog system that doesn't have garbage collection
can run faster. The challenge is a runtime engine
that is fast AND has garbage collection.
Mild Shock schrieb:
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.