Re: guile-2.9.1 impressions

[Linas Vepstas]

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 <address@hidden> 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