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.user Subject: Re: map-par slower than map Date: Mon, 24 Oct 2022 07:03:23 +0000 Message-ID: <128c0636-e231-daad-8949-959f0d7b86ed@posteo.de> References: <878rl5kh6d.fsf@fcs22.keithdiane.us> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13794"; mail-complaints-to="usenet@ciao.gmane.io" Cc: damien.mattei@gmail.com, guile-user@gnu.org To: Keith Wright Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Mon Oct 24 09:05:44 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 1omrWp-0003IQ-Re for guile-user@m.gmane-mx.org; Mon, 24 Oct 2022 09:05:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omrUx-0003X9-Oj; Mon, 24 Oct 2022 03:03:53 -0400 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 1omrUg-0003Sg-VF for guile-user@gnu.org; Mon, 24 Oct 2022 03:03:31 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omrUe-0004iO-Qk for guile-user@gnu.org; Mon, 24 Oct 2022 03:03:30 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C5256240027 for ; Mon, 24 Oct 2022 09:03:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1666595005; bh=L9t+PpsZ/C1/eCUMV1Gi37F2RPNbZf3XRxOoWGfioQg=; h=Date:Subject:To:Cc:From:From; b=pprGPn5WbpA4IR/ERk1O0+JdFx4N62tzJFm8MI5aLPFXfUjaYHQzZ2/6/0tzsGJz6 +q5FsQrwbUMGGU/aad4R6snQYAIE83pAvMsg7FyNX/dSkat1nE/oOmBx89bbi6aRf5 71bEoLFExU+fKjh2TKYF5nHcE+WGhdeG1NljAEREy4fCPygt5rEOBTPW9Ujob/eP2o V20Uzi0Xs4Rc+Ujww+MRI3ydVCv91jXSOUqG0FVEUzUkSq1iOHU1kqkX7Yf6ZkLngU NqenZG5m82390R/FhGV6A4mra3R5e5EPr+KQODT9mGtmV59egXhgqcgjtb1WTCplOs vg1BBWE+5ecrg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MwmHw4QPTz9rxg; Mon, 24 Oct 2022 09:03:24 +0200 (CEST) Content-Language: en-US In-Reply-To: <878rl5kh6d.fsf@fcs22.keithdiane.us> Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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: , Original-Sender: "guile-user" Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:18678 Archived-At: Hello Keith! On 10/24/22 05:56, Keith Wright wrote: > Zelphir Kaltstahl writes: > >> Of course,if you have global state and do not have a synchronization >> construct for accessing the hash table, I would expect things to >> go wrong at some point, with non-reproducible results. > Indeed. > >> I do not think that futures are to blame here, >> or parallel map in that case. > Are futures to blame? Do you blame the plus sign for > this wrong equation: 4+5=20? > My teachers blamed me for that sort of thing. I do not know your teachers, but in my experience futures work well in Guile : ) Blaming a construct like futures for the results of using shared global state seems really unreasonable. >> With a synchronization construct, some kind of mutex, >> your bottle neck might just become that mutex. > But why make it parallel at all? Unless you have some serious > parallel hardware you will just be wasting time in the scheduler > when you could be computing the answer. Assuming, that parallelization is possible and a problem is not inherently of sequential nature, of course there is hope for a speedup to be achieved. When parallelizing properly (which might involve finding a different algorithm) there might not be any resource conflict between the futures or OS threads running, so time will not be "time wasted in the scheduler". According to what Damien has written the parallelization has already sped up his calculations a lot. I think it is fair to assume, that it is at least partly working : ) I agree though, that pages of boolean expressions are not really that interesting to have in the mailbox ; ) Regards, Zelphir -- repositories: https://notabug.org/ZelphirKaltstahl