From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Olivier Dion via General Guile related discussions Newsgroups: gmane.lisp.guile.user Subject: Re: [ANN] Guile-Parallel 1.0.0 released Date: Sat, 31 Dec 2022 15:31:34 -0500 Message-ID: <87pmbzpb6h.fsf@laura> References: <87wn68p6qi.fsf@laura> Reply-To: Olivier Dion Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24002"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Guile User To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sat Dec 31 21:32:40 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pBiX2-000621-AF for guile-user@m.gmane-mx.org; Sat, 31 Dec 2022 21:32:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBiWR-0004LD-KT; Sat, 31 Dec 2022 15:32:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBiWH-0004KR-0I for guile-user@gnu.org; Sat, 31 Dec 2022 15:31:54 -0500 Original-Received: from smtp.polymtl.ca ([132.207.4.11]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBiWB-0005Ye-Nm for guile-user@gnu.org; Sat, 31 Dec 2022 15:31:52 -0500 Original-Received: from localhost (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 2BVKVY9n019089; Sat, 31 Dec 2022 15:31:39 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 2BVKVY9n019089 In-Reply-To: X-Poly-FromMTA: (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) at Sat, 31 Dec 2022 20:31:34 +0000 Received-SPF: pass client-ip=132.207.4.11; envelope-from=olivier.dion@polymtl.ca; helo=smtp.polymtl.ca X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:18815 Archived-At: On Sat, 31 Dec 2022, Zelphir Kaltstahl 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=20 > for guile-parallel and guile-fibers. Or whether they could work well toge= ther or=20 > 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 =C3=A0 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. --=20 Olivier Dion oldiob.dev