Re: [ANN] Guile-Parallel 1.0.0 released

[Olivier Dion]

On Sat, 31 Dec 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:

> Maybe I can already make use of it in coming AoC puzzles.

Any sort of feeback is welcome!

> I am currently a bit confused about where the line is between a good use-case 
> for guile-parallel and guile-fibers. Or whether they could work well together 
> or 
> the people making them should work together ; )

I haven't use fibers a lot, but I think that if you ever need to handle
asynchronous I/O, for now you should stick with fibers.  Also, fibers
was written by peoples that have a way better understanding of Guile
internal then I do, so I would expect it to be better in some areas.  It
also use epoll(2) instead of select(2), which is way better for events
listening.  I will make the change once Guile has native support for
epoll(2).  I currently only use select(2) for listening on
timerfd_create(2) timers to handle sleeps of userspace threads, so the
impact is marginal.

Where I can see a clear difference is in the primitives offered to the
users.  Fibers works with channels and follows a paradigm à la
Concurrent ML while Parallel works with traditionnal primitives like
barriers, mutexes, semaphores, etc.  Parallel also aims at providing
useful parallel algorithms to the users.  e.g. vector sort.

The ultimate goal of Parallel is to make communication between userspace
threads and kernel threads transparent.  All synchronization primitives
should work for all threads types and for different schedulers.

I think that one can quickly use Parallel without modifying too much its
code base to make it work, e.g. by replacing (rnrs sorting) vector-sort
with (parallel vector) parallel-vector-sort.  You can also replace the
usage of (ice-9 futures) with (parallel futures).  The latter scale
better from my benchmarks.

-- 
Olivier Dion
oldiob.dev