From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: map-par slower than map Date: Fri, 14 Oct 2022 08:38:54 +0000 Message-ID: References: <5608809c-89a2-118c-5c05-c46ac3a0e21b@posteo.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FDeA30hePf3UpW7gddKV72lb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25682"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user , guile-devel To: Damien Mattei Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Oct 14 10:39:58 2022 Return-path: Envelope-to: guile-devel@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 1ojGEX-0006S6-N2 for guile-devel@m.gmane-mx.org; Fri, 14 Oct 2022 10:39:57 +0200 Original-Received: from localhost ([::1]:37688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojGEW-0006sW-9j for guile-devel@m.gmane-mx.org; Fri, 14 Oct 2022 04:39:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojGDl-0006rV-DK for guile-devel@gnu.org; Fri, 14 Oct 2022 04:39:09 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:35381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojGDj-0007ez-AI for guile-devel@gnu.org; Fri, 14 Oct 2022 04:39:09 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 8050424002A for ; Fri, 14 Oct 2022 10:39:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1665736741; bh=HQ8qN/DmMEz1ardQa7hEAWEXT5RqXjJdIIxDRRCGMSk=; h=Date:Subject:To:Cc:From:From; b=KzqgdvXu6xZ+iUBloOqYgWeHvjmHi+Ol8YQg6Fd22bHr+rBCzpxVKyNi1qeN8Onj0 ApFmr81iH5jZCahjAj7wwafdOiB9rHBM6ZAw6dgFGF1O54mX0AGCsBkt5/7EmeIJ4I CDiPnyNW3RlgAh2jOE6MVP+IXR+e7ONkzKKcd8XXkFxABxWQB2TtDm7a/lCTL6HI/i wMcubLumXhdum8eL9+pkj7MvcDKmdJ3JfY5VkUztR/hosH5uNgFkNTp2jDD0oQPX0X eLc0XeZ60PVTEVYp+Wyu/qouCZ9pQEIMOYnsVPple3ZpjhsD8VsqM1hJ2sWh20sb71 j3pJyj4oQBg7Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Mpftk5CZ2z9rxL; Fri, 14 Oct 2022 10:38:54 +0200 (CEST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:21436 gmane.lisp.guile.user:18648 Archived-At: This is a multi-part message in MIME format. --------------FDeA30hePf3UpW7gddKV72lb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Damien, On 10/14/22 10:21, Damien Mattei wrote: > yes Zelphir i think there is a problem in the threading part of guile, > whatever the code is ,it run well the first time, and after is unstable. Long > ago at the very begin of Java language on my master project at university i > experienced same problem with Java "green" threads, under windows and/or linux > ,i can't remember. > > I'm trying your code and future, which have perheaps also the portability with > other schemes, future can provide "light" // , with carefull code it could be ok. > > in your segment.scm code ,is segment-count possibly replaced by the number of > available CPUs or nodes, if i understand well? > > Regards, > Damien Correct. For each segment one future is used. However, there are scenarios, where one would rather want to interleave the numbers of the whole range, to have a "fairer" workload per future, for example: (1 2 3 4 5 6 7 8 9) -> (1 4 7), (2 5 8), (3 6 9) instead of -> (1 2 3) (4 5 6) (7 8 9) (I seem to remember this to be the case for Mandelbrot set calculations, but might be wrong.) But that is all a matter of forming some segments and what a segment is, not really part of the logic of creating futures. So one could create then in any way that fits ones use-case. I have not generalized that segment logic that far, but it is doable. Anyway, if anyone more knowledgeable could chime in on what the performance differences between futures and parallel map are, that would be great! Or pointing out some flaws that this kind of future usage might have. Or when the point is reached to switch to guile-fibers library. Regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl --------------FDeA30hePf3UpW7gddKV72lb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hello Damien,

On 10/14/22 10:21, Damien Mattei wrote:
yes Zelphir i think there is a problem in the threading part of guile, whatever the code is ,it run well the first time, and after is unstable. Long ago at the very begin of Java language on my master project at university i experienced same problem with Java "green" threads, under windows and/or linux ,i can't remember.

I'm trying your code and future, which have perheaps also the portability with other schemes, future can provide "light" // , with carefull code it could be ok.

in your segment.scm code ,is segment-count possibly replaced by the number of available CPUs or nodes, if i understand well?

Regards,
Damien

Correct. For each segment one future is used.

However, there are scenarios, where one would rather want to interleave the numbers of the whole range, to have a "fairer" workload per future, for example:

(1 2 3 4 5 6 7 8 9)

-> (1 4 7), (2 5 8), (3 6 9)

instead of

-> (1 2 3) (4 5 6) (7 8 9)

(I seem to remember this to be the case for Mandelbrot set calculations, but might be wrong.)

But that is all a matter of forming some segments and what a segment is, not really part of the logic of creating futures. So one could create then in any way that fits ones use-case. I have not generalized that segment logic that far, but it is doable.

Anyway, if anyone more knowledgeable could chime in on what the performance differences between futures and parallel map are, that would be great! Or pointing out some flaws that this kind of future usage might have. Or when the point is reached to switch to guile-fibers library.

Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl
--------------FDeA30hePf3UpW7gddKV72lb--