On Sat, 31 Dec 2022, Zelphir Kaltstahl <zelphirkaltst...@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
