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: Sun, 23 Oct 2022 23:18:58 +0000 Message-ID: <87860c1f-e590-8e16-e031-dedc99cd3864@posteo.de> References: <5608809c-89a2-118c-5c05-c46ac3a0e21b@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23298"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user To: Damien Mattei Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Mon Oct 24 05:08:21 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 1omnp6-0005tO-SE for guile-user@m.gmane-mx.org; Mon, 24 Oct 2022 05:08:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omnb7-0002UK-HZ; Sun, 23 Oct 2022 22:53: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 1omkFI-0007jF-HH for guile-user@gnu.org; Sun, 23 Oct 2022 19:19:08 -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 1omkFC-0002t1-RL for guile-user@gnu.org; Sun, 23 Oct 2022 19:19:08 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B1108240026 for ; Mon, 24 Oct 2022 01:18:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1666567139; bh=20rcxyZM2iuMM3xEbg0YE8x5XxP63RkkekQLdj67tPY=; h=Date:Subject:To:Cc:From:From; b=f1Yp0ddbT93eEkLu90yohuilpS8Fh5pM5chrIeyFtPa9aUE8oi1rr0lzvyGaKiMa2 PNPWMxQgc7KHpM4QEbNhQaELQnu9BVzI/3E+osb6rpF8vJKYY0HNJHpIQxFVIco8cm 3BUUfTMMrekGK0ifc64h4wyF3ZOv/t0Q2LrVdsjPakCG25hhNsxLJjwPysUAwGDbUt ghYcowEYEtrfJk/y/mSaPj+i3eD/QDogEhzom7y4j+qwIU5Op6wcfDzHemqaAmYC62 m7+Jitk6ONKq2mJOPANM6ZDQRLvW5ii5yuN0kGL8ldYQGDMkyuvHTppuVn0NBfzKrD uu8+vWdSWjbEA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MwZ023Nznz9rxR; Mon, 24 Oct 2022 01:18:58 +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: -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, HTML_MESSAGE=0.001, 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-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:18672 Archived-At: Hello Damien! On 10/23/22 03:06, Damien Mattei wrote: > after intense coding i finally got the good results, > my assumption about the global variable hash table was true ,it is > incompatible with 'future : the competition for the writing into the hash > table breaks the code. > > If i do writing in hash table out of // region all is ok: > > a simple function to extract the hash table access: > > (define (tag-minterms i umt) >   (when umt >      {mt1 <+ (first {minterms-vector[i]})} >      {mt2 <+ (second {minterms-vector[i]})} >      {minterms-ht[mt1] <- #t} >      {minterms-ht[mt2] <- #t})) > [...] I am not sure what exactly the problem is, which you are trying to calculate, but it looks fairly mathematical to me. Maybe you do not need to share state globally at all? Maybe you can find a way to avoid global shared state? I am guessing, that you want to avoid duplicated computation of part terms? 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. I do not think that futures are to blame here, or parallel map in that case. With a synchronization construct, some kind of mutex, your bottle neck might just become that mutex. Up to you to measure that ; ) Would be nice, if you found a clever way to separate the problems into disjunct parts and then solve them without global state. Regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl