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 Subject: Re: guile-2.9.1 impressions Date: Mon, 27 May 2019 20:49:12 -0500 Message-ID: References: <877eahotro.fsf@pobox.com> Reply-To: linasvepstas@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e1a8f50589e8df05" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183191"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Guile Development To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 28 03:50:23 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVRFv-000lWX-45 for guile-devel@m.gmane.org; Tue, 28 May 2019 03:50:23 +0200 Original-Received: from localhost ([127.0.0.1]:55645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVRFs-0002qB-UH for guile-devel@m.gmane.org; Mon, 27 May 2019 21:50:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVRF3-0002Fz-9P for guile-devel@gnu.org; Mon, 27 May 2019 21:49:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVRF1-0004yU-NO for guile-devel@gnu.org; Mon, 27 May 2019 21:49:29 -0400 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:35043) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hVRF1-0004x7-8K for guile-devel@gnu.org; Mon, 27 May 2019 21:49:27 -0400 Original-Received: by mail-lj1-x22e.google.com with SMTP id h11so16119982ljb.2 for ; Mon, 27 May 2019 18:49:26 -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=wN/XVLIbU43ru4kSeOq2GpiqIXMacdSVrCpsAwOOzug=; b=mcmXjvOwgI/ZJd+eLKc4FxUrYfe8JcACJRece8O7vZIZdZyeg77USneUdkn7gs1mMM ZtyAU8/U2hjDqisIFHiWktLqL55A5G1CXgRyTXqxP1M/9zQYoMA6Td5f0b4K7s+Y4CK3 t6gWrG/QAZ8S4G9zoOvDkFByvbB8LCySd9Dpccy3pDBsWIrrXahJmxxatKlFzjvn0bo5 KH144jjOh7/OxGRCT2A+F+L+Nx1R+WlGeNSVMXIi8y9LnTVQ4KL36gXoLJsQ6GKI3/oF RSjPLNGbKQyDnErZ6M9b0lbIjykH2AzCp59zMvNrQBdG7EJa4w6nibwRf6sw+KjMSMBv ZIzA== 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=wN/XVLIbU43ru4kSeOq2GpiqIXMacdSVrCpsAwOOzug=; b=Ipzib8T4e60RPeVlVsDXkU6MbIS5MlP3BkmINVzXUcDJJ7BN8gMphkLI7Wij3HN79O sElbQGGFDoRgs7ZebAeSxmdisGruekmH84nBX2MHsRtqgg+ZVysDC0uDKSmS1z8lUD9P N1REwI/5CXtK9e59XB7HLhgvOToVRa863rnXqdbWML/qz5SzILQfIbJNUil4cEmXIgro xiA2lPBSTs9kkoZLpoRS4QFgFedQvMV6vE0421A5fjLmI6tF2KGm+GSnhAQQDW6bKSin fQPt8WiLNRl5nJwEUEnQ0/I4kBJYsP88G8hoZw/A2KrerUZiYIN9EuUXSK9/L+A5Rv6p 4M8g== X-Gm-Message-State: APjAAAX02nqn29JiDvRC+h/qh+9kxTjPkOytx20fbSUq5pNVKvmAF9AL nir3izN36Q6NvI5av9DRHgubzVDsVyujKXg3op8= X-Google-Smtp-Source: APXvYqw6U2RURh9SS8S5NB5sHHy/iwtyAerpC0lWEHN8sTnBAecZp36hzeDcvNcANgUjNwMfbLQqcOL/O+mDEIn5Wx8= X-Received: by 2002:a2e:568b:: with SMTP id k11mr60434605lje.124.1559008165077; Mon, 27 May 2019 18:49:25 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::22e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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:19931 Archived-At: --000000000000e1a8f50589e8df05 Content-Type: text/plain; charset="UTF-8" I've put in a cumulative of 36 hours guile-2.9.2 multi-threaded stress testing on two different OS/compiler/glibc combinations, and have seen exactly zero crashes or hangs so far. So it's perfect. Sorry for earlier confusion. -- linas On Sun, May 26, 2019 at 11:40 PM Linas Vepstas wrote: > Andy, > > I want to temporarily, maybe permanently retract my last email. I found a > bug(let) in the intialization of my unit test that appears to maybe account > for all observed crashes, maybe. I'm re-verifying on multiple machines but > this will take 24-48 hours. Basically, it looks like guile-2.9.2 is crash > free (for the last 6 hours) on one os/compiler/glibc combination, I have to > cross-check on another. > > --linas > > On Sun, May 26, 2019 at 8:40 AM Linas Vepstas > wrote: > >> Hi Andy, >> >> Thanks! I just tried out the master branch of guile in git (the one >> tagged v2.9.2). It now passes all of my unit tests. So that's good! ... >> More or less -- there's still some infrequent multi-threading bug(s). Let >> me describe. >> >> My unit test just transitions C->guile->C and returns, in rapid >> succession, in 20 threads. So, in pseudocode: >> >> SCM do_stuff(SCM a, SCM b) { >> scm_to_utf8_string(a); >> scm_to_int(b); >> ... minor stuff... return scm_from_int(...); >> } >> scm_c_define_gsubr("do-things",2,0,0, do_stuff); >> >> void thing_doer(int thread_id) { >> for (i=0; i=15000; i++) >> char str[100]; >> sprintf(str, "(do-things foo %d)", i); >> scm_c_catch(scm_eval_string, str); >> } >> >> main () { >> for (int i=1; i<15; i++) // start 15 threads >> std::thread(&thing_doer, i); >> } >> >> I'm guessing the above code spends maybe 90% of its time bouncing between >> guile and C. The string "(do-things foo 42)" changes each time in the loop, >> so, not sure how the compile vs. interpret tradeoff is done. Either way, >> its relatively trivial. Likewise, the do_stuff() C routine is fairly thin; >> after decoding it's args, it doesn't do all that much (sub-microsecond of >> computing). Based on old, old measurements, scm_eval_string really is the >> primary CPU consumer, in the 20-microseconds range. Launching 15 threads >> means that this thing is racing as fast as it can. >> >> Anyway, with guile-2.9.2, the above crashes after about 10-15 minutes, >> either with memory corruption, or with segfault. I worried, so I retested >> with guile-2.2.4 ... which also crashes, but much much less frequently: >> seven times in 44 hours wall-clock time (so once ever 6 hours). Which is >> still more than desired, but...OK. >> >> So where's the crash? No clue. Could be my code, could be guile. Since >> there's a big difference between guile-2.2 and guile-2.9, I'm ready to >> blame guile. I did try to run it with `valgrind --tool helgrind` and got an >> ocean of complaints about guile GC, which are probably harmless. I haven't >> tried to dig deeper yet. >> >> -- Linas >> >> >> On Thu, May 23, 2019 at 2:28 PM Andy Wingo wrote: >> >>> Hi! >>> >>> On Thu 06 Dec 2018 06:21, Linas Vepstas writes: >>> >>> > After sending the email below, I scanned the guile-devel archives, >>> > and I see Thomas Morley talking about Lilypond performance. >>> > The example program he offers up caught my eye: nested deep >>> > in a loop is this: >>> > >>> > (eval-string "'(a b c)") >>> >>> In this case I believe Guile 2.9 / 3 should be significantly faster than >>> 2.2, because `eval' is compiled to native code rather than bytecode. My >>> measurements showed it to be on par with the hand-optimized C >>> implementation from 1.8 and before. Depends of course on how much the >>> expander is part of your workload, there are differences relative to >>> Guile 1.8. Anyway, thanks for the note and I just wanted to mention >>> this point. >>> >>> Regarding Scheme -> C++ transitions, there is the possibility that this >>> too could be much faster with Guile 2.9.x given that these calls are now >>> JIT-compiled instead of interpreted. We'll have to see. >>> >>> Cheers, >>> >>> Andy >>> >> >> >> -- >> cassette tapes - analog TV - film cameras - you >> > > > -- > cassette tapes - analog TV - film cameras - you > -- cassette tapes - analog TV - film cameras - you --000000000000e1a8f50589e8df05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've put in a cumulative of 36 hours guile-2.9.2 multi= -threaded stress testing on two different OS/compiler/glibc combinations, a= nd have seen exactly zero crashes or hangs so far.=C2=A0 So it's perfec= t. Sorry for earlier confusion. -- linas

On Sun, May 26, 2019 at 11:40 P= M Linas Vepstas <linasvepstas@= gmail.com> wrote:
Andy,

I want to t= emporarily, maybe permanently retract my last email. I found a bug(let) in = the intialization of my unit test that appears to maybe account for all obs= erved crashes, maybe. I'm re-verifying on multiple machines but this wi= ll take 24-48 hours.=C2=A0 Basically, it looks like guile-2.9.2 is crash fr= ee (for the last 6 hours) on one os/compiler/glibc combination, I have to c= ross-check on another.

--linas

=
On Sun, Ma= y 26, 2019 at 8:40 AM Linas Vepstas <linasvepstas@gmail.com> wrote:
Hi Andy,

Thanks!=C2=A0 I just tried out the master branch of gu= ile in git (the one tagged v2.9.2). It now passes all of my unit tests.=C2= =A0 So that's good! ... More or less -- there's still some infreque= nt multi-threading bug(s).=C2=A0 Let me describe.=C2=A0

=
My unit test just transitions C->guile->C and returns, in = rapid succession, in 20 threads. So, in pseudocode:

SCM do_stuff(SCM a, SCM b) {
=C2=A0 =C2=A0 =C2=A0 scm_to_u= tf8_string(a);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scm_to_int(b);
=C2=A0=C2=A0=C2=A0=C2=A0 ... minor stuff... return scm_from_int(...);=
}
scm_c_define_gsubr("do-things",2,0,0, do_s= tuff);

void thing_doer(int thread_id) {
= =C2=A0=C2=A0=C2=A0=C2=A0 for (i=3D0; i=3D15000; i++)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char str[100];
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sprin= tf(str, "(do-things foo %d)", i);
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scm_c_catch(scm_eval_string,= =C2=A0 str);
}

main () {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i=3D1; i<15; i++)=C2=A0=C2=A0= // start 15 threads
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 std::thread(&thing_doer, i);
}

I'm guessing the above code spends maybe 90%= of its time bouncing between guile and C. The string "(do-things foo = 42)" changes each time in the loop, so, not sure how the compile vs. i= nterpret tradeoff is done.=C2=A0 Either way, its relatively trivial. Likewi= se, the do_stuff() C routine is fairly thin; after decoding it's args, = it doesn't do all that much (sub-microsecond of computing).=C2=A0 Based= on old, old measurements, scm_eval_string really is the primary CPU consum= er, in the 20-microseconds range. Launching 15 threads means that this thin= g is racing as fast as it can.

Anyway, with guile-= 2.9.2, the above crashes after about 10-15 minutes, either with memory corr= uption, or with segfault.=C2=A0 I worried, so I retested with guile-2.2.4 .= .. which also crashes, but much much less frequently: seven times in 44 hou= rs wall-clock time (so once ever 6 hours).=C2=A0 Which is still more than d= esired, but...OK.

So where's the crash? No clu= e. Could be my code, could be guile. Since there's a big difference bet= ween guile-2.2 and guile-2.9, I'm ready to blame guile. I did try to ru= n it with `valgrind --tool helgrind` and got an ocean of complaints about g= uile GC, which are probably harmless. I haven't tried to dig deeper yet= .

-- Linas


On Thu, May 23, 2019 at 2:28 PM Andy Wingo <wingo@pobox.com> wrote:
=
Hi!

On Thu 06 Dec 2018 06:21, Linas Vepstas <linasvepstas@gmail.com> writes:

> After sending the email below, I scanned the guile-devel archives,
> and I see Thomas Morley talking about Lilypond performance.
> The example program he offers up caught my eye: nested deep
> in a loop is this:
>
> (eval-string "'(a b c)")

In this case I believe Guile 2.9 / 3 should be significantly faster than 2.2, because `eval' is compiled to native code rather than bytecode.=C2= =A0 My
measurements showed it to be on par with the hand-optimized C
implementation from 1.8 and before.=C2=A0 Depends of course on how much the=
expander is part of your workload, there are differences relative to
Guile 1.8.=C2=A0 Anyway, thanks for the note and I just wanted to mention this point.

Regarding Scheme -> C++ transitions, there is the possibility that this<= br> too could be much faster with Guile 2.9.x given that these calls are now JIT-compiled instead of interpreted.=C2=A0 We'll have to see.

Cheers,

Andy


--
cassette tapes - analog TV - film cameras - you


--
cassette tapes = - analog TV - film cameras - you


--
cassette tapes - analog TV - film cameras = - you
--000000000000e1a8f50589e8df05--