From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Linas Vepstas Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: guile-2.9.2 and threading Date: Tue, 9 Jul 2019 15:46:19 -0500 Message-ID: References: <87h892ault.fsf@netris.org> Reply-To: linasvepstas@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d90801058d45a755" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35082"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Guile User , Guile Development To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jul 09 22:48:28 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkx2J-00090f-2G for guile-devel@m.gmane.org; Tue, 09 Jul 2019 22:48:27 +0200 Original-Received: from localhost ([::1]:56030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkx2F-00037l-EX for guile-devel@m.gmane.org; Tue, 09 Jul 2019 16:48:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37630) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkx0e-00034T-Qj for guile-devel@gnu.org; Tue, 09 Jul 2019 16:46:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkx0Y-0000VS-8T for guile-devel@gnu.org; Tue, 09 Jul 2019 16:46:41 -0400 Original-Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:32771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkx0W-0000OD-6B; Tue, 09 Jul 2019 16:46:36 -0400 Original-Received: by mail-lf1-x135.google.com with SMTP id x3so15173lfc.0; Tue, 09 Jul 2019 13:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=sZhFqd6t8HEbtMIpGC0vQDsqdzLW+MqifgHUs9JcqF4=; b=R/bGNfh30nlIPjt8rDj1eNtzwsP/+8UJejXjJvT8QTfmGqCTI3yz/NZJF5709ARkq2 95lT4fs8byZoHOxCDGsMTaTfTCkCLCoLxL7IEO/ZZru3jzJ5PdZWLS8qWPdgCzC6ps5Z EsAh4R9x6D49RQBEzh9FIGSMygVKAIib87k0fyY6o5WqzF8QnXt/2OYVFIqlZhRyzmO3 WeBDgIoGLvt3NefCpNzLrP1PSz6aKGnv7OU43UwwrqrgFUa/jtetero9rrZR8l0HZCTP ejc48nmGZzkJr4KoZt5CC2ES7o1ik74SdvWwl4c4L2AFj4WIWfyRrJIuAptr+2p133Hu 2SmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=sZhFqd6t8HEbtMIpGC0vQDsqdzLW+MqifgHUs9JcqF4=; b=PwV45MgvzVUjNtD3kKWxikGPmSLBetXbrxtmImSYju7UBj/Q0Lw8h7Z8FLOk32vz0M kmxOESvI1jWmiPoA9OmAarwXu975p4rhz7GVnsTyGgKFZ2WrRq4WB8lBsLPjwNqcXu0/ xi6H/FyBGpszc4Rd4vqsvgw6258sKGLHXnx/vYI/e5dJ/2rZ5ZHyGU+qpt83pvTapbq+ qm1Qnfj1/8Cv4Tuf7vqvpyVMc0oi4oT9Xj9UhA/iP92WLb396HGedTSU/vFCuR12tlws eEw5vMTplgEFPvZ8GDO4dbYGNi9Ow+V+t9y8qTkgajCBFJZAAOD+qH5tcEZT9NjLaDNp KqBw== X-Gm-Message-State: APjAAAXjd2S/5tj0ImKJ9VY+Wyn7AgWDgtVIPAzhW/17tHTdHCV4qFDh L3l3QoU18OYVCW7p391Z9fQKmRCdgbRgvMiAKnyN8tmI X-Google-Smtp-Source: APXvYqwuvrQwU7s2jWnhicTfH/weWEioMt264pMn4EjvRdyY3rjGncIcbGj2d1xwnH6hsrRkBQpK7vem2g5UcYSFUPo= X-Received: by 2002:a19:ed07:: with SMTP id y7mr13244102lfy.56.1562705191829; Tue, 09 Jul 2019 13:46:31 -0700 (PDT) In-Reply-To: <87h892ault.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::135 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20001 gmane.lisp.guile.user:15626 Archived-At: --000000000000d90801058d45a755 Content-Type: text/plain; charset="UTF-8" Hi Mark, Sorry for the late reply; my email client mananged to hide your email where I won't see it. I need to fix this. On Thu, Jun 6, 2019 at 11:28 PM Mark H Weaver wrote: > > You'll need to look at the stack frames on the Scheme stack. It can be > done from GDB if necessary, but it might be sufficient to use Guile's > debugger. > > My first thought was to suggest ",break lock-mutex", but that doesn't > work, presumably because it's a C primitive (although we should fix > that), but I was able to patch in a pure Scheme wrapper for it, which > then allows us to set a Scheme breakpoint: > > I'll poke around and report back. Meanwhile, some orienting remarks. Since last email, I've accumulated several CPU-months running guile-2.9.2 with zero crashes and zero hangs. So I like it! For threading, I see three or four different behaviors or modes; sometimes it works great, sometimes it doesn't work at all, and I'm still trying to figure out why. A works-great example: (par-for-each (lambda (stuff) (... little bit of scheme + CPU-intensive C++)) some-precomputed-list) The "CPU-intensive C++" are calls that take at least a millisecond to run, sometimes seconds. The above will very happily use all 24 cores and deliver a 24x speedup over single-threaded. Yay! A works-poorly example: (par-for-each (lambda (stuff) (.. (fold (lambda () numeric addition after tiny C++)) some-list) list) Here, "tiny C++" is something that just enters C++ and leaves almost immediately; it's used to grab and return a numeric value. This runs as if it were single-threaded, and delivers performance equivalent to being single-threaded. I don't know why; this is what I reported in the earlier emails. A doesn't-work example: mostly same as "works-poorly", but performance is worse-than-single-threaded. Sometimes 2x worse. Why, I don't know. (It does seem to do a LOT of gc; that might account for all of the slowdown; not sure. These loops iterate over millions/tens-of-millions of items and can take an hour to complete...) The worse-than-single-threaded behavior was actually the norm for guile-2.2; its no longer the norm (yay!). In guile-2.2, there seemed to be some kind of livelock, where two threads were 1.5x faster than one, three threads were 1.2x faster than one, and four threads were slower, and sometimes one-thousand-fold slower! (but still making forward progress, i.e. not a deadlock) That era seems to be over, yay! I'll report on the rest, later, when I get a chance (the compute jobs are hard to manage, and take an hour to set up) -- Linas -- cassette tapes - analog TV - film cameras - you --000000000000d90801058d45a755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Sorry for the late = reply; my email client mananged to hide your email where I won't see it= . I need to fix this.

On Thu, Jun 6, 2019 at 11:28 PM Mark H Weaver <= mhw@netris.org> wrote:

You'll need to look at the stack frames on the Scheme stack.=C2=A0 It c= an be
done from GDB if necessary, but it might be sufficient to use Guile's debugger.

My first thought was to suggest ",break lock-mutex", but that doe= sn't
work, presumably because it's a C primitive (although we should fix
that), but I was able to patch in a pure Scheme wrapper for it, which
then allows us to set a Scheme breakpoint:


I'll poke around and report back. Meanwhile, some orienting rem= arks.=C2=A0 Since last email, I've accumulated several=C2=A0 CPU-months= running guile-2.9.2 with zero crashes and zero hangs. So I like it!=C2=A0 = For threading, I see three or four different behaviors or modes; sometimes = it works great, sometimes it doesn't work at all, and I'm still try= ing to figure out why.

A works-great example:
(par-for-each (lambda (stuff) (... little bit of scheme + CPU-intensi= ve C++)) some-precomputed-list)

The "CPU-inte= nsive C++" are calls that take at least a millisecond to run, sometime= s seconds.=C2=A0 The above will very happily use all 24 cores and deliver a= 24x speedup over single-threaded.=C2=A0 Yay!

=
A works-poorly example:
(par-for-each (lambda (stuff) (.. (f= old (lambda () numeric addition after tiny C++)) some-list) list)

Here, "tiny C++" is something that just enters C+= + and leaves almost immediately; it's used to grab and return a numeric= value. This runs as if it were single-threaded, and delivers performance e= quivalent to being single-threaded.=C2=A0 I don't know why; this is wha= t I reported in the earlier emails.

A doesn't-= work example: mostly same as "works-poorly", but performance is w= orse-than-single-threaded. Sometimes 2x worse. Why, I don't know. (It d= oes seem to do a LOT of gc; that might account for all of the slowdown; not= sure. These loops iterate over millions/tens-of-millions of items and can = take an hour to complete...)

The worse-than-= single-threaded behavior was actually the norm for guile-2.2; its no longer= the norm (yay!). In guile-2.2, there seemed to be some kind of livelock, w= here two threads were 1.5x faster than one, three threads were 1.2x faster = than one, and four threads were slower, and sometimes one-thousand-fold slo= wer! (but still making forward progress, i.e. not a deadlock) That era seem= s to be over, yay!

I'll report on the rest, la= ter, when I get a chance (the compute jobs are hard to manage, and take an = hour to set up)

-- Linas
=
--
cassette tapes - analog TV - film cameras - you
--000000000000d90801058d45a755--