From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Linas Vepstas Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: guile-2.9.1 impressions Date: Wed, 5 Dec 2018 23:21:02 -0600 Message-ID: References: Reply-To: linasvepstas@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1544073593 32713 195.159.176.226 (6 Dec 2018 05:19:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2018 05:19:53 +0000 (UTC) To: Guile User , Guile Development , Thomas Morley Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Dec 06 06:19:49 2018 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUm4h-0008MU-7g for guile-user@m.gmane.org; Thu, 06 Dec 2018 06:19:47 +0100 Original-Received: from localhost ([::1]:38892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUm6n-0000B8-Hq for guile-user@m.gmane.org; Thu, 06 Dec 2018 00:21:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUm6F-0000Aq-Kg for guile-user@gnu.org; Thu, 06 Dec 2018 00:21:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUm6B-00006C-Dd for guile-user@gnu.org; Thu, 06 Dec 2018 00:21:21 -0500 Original-Received: from mail-it1-x132.google.com ([2607:f8b0:4864:20::132]:40951) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gUm6A-0008WD-LO; Thu, 06 Dec 2018 00:21:18 -0500 Original-Received: by mail-it1-x132.google.com with SMTP id h193so23979694ita.5; Wed, 05 Dec 2018 21:21:18 -0800 (PST) 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; bh=M7JWC2P4DS+vAQWQh8ZYT3T58u5JGxvaU8hG9B+BCFQ=; b=vOM/vETM7gBdf/SV/LLqsGnXt/hD72R3F5WC7jN1cP8MNwepDus5dvu6IVUo0jByMW EUE9jwYznyW2Tziry28BDs2w6TnWXQcuylHDuXKCQw1QXSKiXWW1IBhuHD1o2pQA5Hu9 NF6j+lCLpPFr3G3HRzqe6sRaDm2eyiUL6NNAqHKU8oPJ5n4ABjsVwQXt2uSKhx/QMiqU 4CgVhZr+mic2iyhf+GAcxkqFqNAVmDfFNcBWjFy+wQnj/f78nI6HWWB9PYiUaiwm8qSK DR+VgluqrIS4b9vRQIHYbyIdxstIHeQDjwRGWvuiNL050My7zG6LfNgWdSETxgtVxrjD WnWA== 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; bh=M7JWC2P4DS+vAQWQh8ZYT3T58u5JGxvaU8hG9B+BCFQ=; b=H/wGX+RCxZMRvaeEMJg0wF8xT+BU3E8iIv6HNnXAzDO154ViaheVJI3/btULQ8DqO2 lRwQ4nKnloaL8KIVfaqwoqAgCPWphe8RgvFOxJteN75RccK4Ufe2MqlNdDE1CB92KW9o pIji/1N5tfNZCeZ+EFGqhvkXIgOuqQVj9cT/ZprCY9sQViDOyQODpOEQzToaS5/e6Us1 M/wkvVFR5pPRpA+IFagS9TLjzoclC6rUcFbkRgqAnYv2w1S5j7GK0Se3C2WvQKEhozdo Z3wx0bkO2SvhTSodc+YJAfjfES26Ob39QSULDfHKAKLcwDbChTZTeHMmQNLMsIX7bR5V G37w== X-Gm-Message-State: AA+aEWamp6hzXJYLcMG0NkMv5C3qdiSytINDn3S4jvxu5z44OsYbo3tH 6ealPZ5xjUaBsgTX5l/5AH6CYWLl88jJEvnrswj+q2Ya X-Google-Smtp-Source: AFSGD/UbUvMqEe+KpiWGGikRYsZaYiTH0f36tRsH8PCIGrzv9eNEVSpJVPadu00vGdAYtOHoB1pxNx2X9WL8KbRtC/s= X-Received: by 2002:a05:660c:81a:: with SMTP id j26mr17804246itk.70.1544073677429; Wed, 05 Dec 2018 21:21:17 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::132 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15027 gmane.lisp.guile.devel:19771 Archived-At: 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)") Well -- oh -- ha -- I think this is the same culprit that is one of my significant bottlenecks. Although I'm mixing C++ and guile very intensely, my main C++-calling-into-guile is more-or-less eval-string. (its actually scm_eval_string() for me). So I think that I can call and and return from scm_eval_string() about 40K/sec on a five-year-old vintage machine, passing it some trivial thing to evaluate. (Python is in a similar ballpark, if that provides any motivation.) I'll bet, given Thomas' comments, that scm_eval_string() was thinner and faster on guile-1.8.8 Thomas also mentioned the "string problem" ... I recall that, when I looked string handling in the guile-2.1.x codebase, there was a whole lotta pointless conversion back and forth between utf8 and double-byte wide chars. It was just tangled, for no good technical reason. Code read like a bleary-eyed 3AM coding session, with "obvious" inefficiencies in it. Fixing it seemed "easy"; there's no comp-sci in it, nothing subtle. It was mostly just a tangle of spaghetti trying to handle locales every which by by converting .. too many times. I thought I might fix that but I got .. busy doing other things. This might be an unfair complaint, as it might very well be fixed in guile-2.2 or guile-2.9 but ... if there is a string problem, the impression that strings are slow, I suggest that an audit of the string handling code may well reveal that the excessive conversions are still there. In particular, I think the excessive string-conversion code showed up in guile-2.0 and got worse in 2.2 as broader utf8 support was added ... (I also humbly suggest that the guile internals should be 100% utf8. >From long experience, utf8 is amazingly clean and simple, and all the other encoding schemes are just horrid messes of hacks and ick and needless complexity and confusing confusion.) -- Linas On Wed, Dec 5, 2018 at 9:56 PM Linas Vepstas wrote: > > So I pulled guile-2.9.1(beta) today, and gave it a spin. Looks > good/great! One bug -- some crazy multithreading bug, > reported as #33641 > > My use case: guile calling C++ code, which calls guile, which > calls C, ad nauseum. I have some 133 unit tests, of which > maybe 3/4ths tweak guile in some way. All but the > multi-threading pass, so happy! > > Some comments about performance in this crazy-quilt > mixed environment. Most of code, both guile and C/C++ > is fairly "thin", not doing a whole lot, before transitioning > into the other language. Thus, the performance is dominated > by the cost of the switch. > > There are two different switches: from C++ to guile, and > from guile to C++. For the first, I'm seeing a rate of about > 30K switches/sec C++ into guile (and back, this includes the return). > > Calls going the other way are about 800K switches/sec > from guile into C++ (this also includes the return). This is > on a 2014-vintage machine. > > Clearly a big difference between the two. Many years ago, > I profiled this, but don't recall the results. The profile did not > reveal anything I could control very much or at all. > > Thus, In this scenario, I don't really expect the gnu lightning > bytecode to affect performance very much; I'm mostly > bottlnecked in the switching of environments. > > FWIW, I'm seeing speedups of 1x to 1.5x for interpreted > mode, and 1.3x to 2x for compiled code. Don't read too > much into these numbers: They're crazy mixes of calls > going in both directions. But still, that's really quite good, > all things considered! > > -- Linas > > I cc'ed both guile-user and guile-devel; I'm not subscribed > to guile-devel, but also I did not see a 2.9.1-beta announce > on guile-user! > -- > cassette tapes - analog TV - film cameras - you -- cassette tapes - analog TV - film cameras - you