From: Linas Vepstas <linasvepstas@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: Guile Development <guile-devel@gnu.org>
Subject: Re: guile-2.9.1 impressions
Date: Sun, 26 May 2019 23:40:30 -0500 [thread overview]
Message-ID: <CAHrUA37g2V6N47mKGM=+YRUGMYya78Deg3Rn8VBm1S=XJUi=+Q@mail.gmail.com> (raw)
In-Reply-To: <CAHrUA35_SvZ1QoZ3mDS6m+3FO4HB_Y2SNRPrtzLFOqE3UidJjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]
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 <linasvepstas@gmail.com>
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 <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. 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
[-- Attachment #2: Type: text/html, Size: 5449 bytes --]
next prev parent reply other threads:[~2019-05-27 4:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-06 3:56 guile-2.9.1 impressions Linas Vepstas
2018-12-06 5:21 ` Linas Vepstas
2019-05-23 19:28 ` Andy Wingo
2019-05-26 13:40 ` Linas Vepstas
2019-05-27 4:40 ` Linas Vepstas [this message]
2019-05-28 1:49 ` Linas Vepstas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHrUA37g2V6N47mKGM=+YRUGMYya78Deg3Rn8VBm1S=XJUi=+Q@mail.gmail.com' \
--to=linasvepstas@gmail.com \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).