[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-2.9.1 impressions
Re: guile-2.9.1 impressions
Wed, 5 Dec 2018 23:21:02 -0600
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.)
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