Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.prolog > #13991

Re: Request for comments, coroutines and workers ISO core standard

From Mild Shock <janburse@fastmail.fm>
Newsgroups comp.lang.prolog
Subject Re: Request for comments, coroutines and workers ISO core standard
Date 2024-02-23 14:17 +0100
Message-ID <ura5tu$gga5$1@solani.org> (permalink)
References <ura4qj$gfpf$1@solani.org>

Show all headers | View raw


What are the chances and risks?

- Chances: Well lookless and global variable Prolog
    system shows much higher performance. When we
    compare Dogelog Player and formerly Jekejeke Prolog,
    we see something like 3691 ms against 6339 ms.

    Also coroutines offer the same comfort for
    internet programming like threads. For example
    using call_later/1 amazingly this here works:

Threads: SWI-Prolog

?- time(call_with_time_limit(0.5, sleep(1))).
% 20 inferences, 0.000 CPU in 0.507 seconds (0% CPU, Infinite Lips)
ERROR: Unhandled exception: Time limit exceeded

Coroutines: Dogelog Player for Java (works since today)

?- time(time_out(sleep(1000), 500)).
% Zeit 516 ms, GC 0 ms, Lips 308, Uhr 23.02.2024 14:05
Fehler: Ausführung abgebrochen da Zeitfrist abgelaufen.
         user auf 2


- Risks: How bring this to all targets JavaScript, Python
     and Java. JavaScript is obviously the simplest, since
     it offers already Workers. But how about Python and
     Java. Here some ideas:

Python: asyncio
We could view workers as process, and then use
the to_process() primitive call that already exists
in Python. Thus adding to workers to the existing
coroutines in Python.

Java: GraalVM
Java had already in the past so called isolates
http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html
Now they come up again:
https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

The article suggest also one might want to keep
a 32-bit implementation of a Prolog system,
64-bit are the bane of garbage collection.

Mild Shock schrieb:
> Now launching a new campaign. Might take again
> one year or so to complete. Whats the basic idea
> here? Vey easy, perform a bifurcation on this here:
> 
> ISO/IEC DTR 13211–5:2007
> Prolog multi-threading support
> https://logtalk.org/plstd/threads.pdf
> 
> The main new objects and built-in predicates that
> make then underlying concepts of coroutines and
> workers visible are suggested as:
> 
> - call_later(Goal, Delay):
>    Borrowed from Python asyncio. Will create a stackless
>    coroutine. That will at least run after Delay
>    millisecond on top of the current task.
> 
> - create_task(Goal):
>    Borrowed from Python asyncio. Will create a stackfull
>    coroutine. That will run as soon as possible, in
>    a new task.
> 
> - create_worker(Path):
>    Borrowed from JavaScript. Will run the given Prolog
>    text in an a new Prolog processor. Communication with
>    the Prolog processor via asynchorous channels.
> 
> Why do this? Well to have the cake and eat it two.
> Whats the cake here: A totally lockless and global variable
> using Prolog system such as Dogelog Player.
> 
> And whats the additional benefit: Compensate that
> the Prolog system is not freely threading. Allow
> embarrassingly parallel via workers.
> 

Back to comp.lang.prolog | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Request for comments, coroutines and workers ISO core standard Mild Shock <janburse@fastmail.fm> - 2024-02-23 13:58 +0100
  Re: Request for comments, coroutines and workers ISO core standard Mild Shock <janburse@fastmail.fm> - 2024-02-23 14:17 +0100
    Re: Request for comments, coroutines and workers ISO core standard Mild Shock <janburse@fastmail.fm> - 2024-02-23 19:16 +0100

csiph-web