Re: Blockers for Guile 2.2

[Han-Wen Nienhuys]

On Sun, Feb 27, 2022 at 10:39 AM Luca Fascione <l.fascione@gmail.com> wrote:
> In other words, is it approximately true that "for (almost) any real-life 
> score the total compilation time
> is proportional to the number of NoteHeads, past a certain size"?
> I'm guessing you need a few pages worth of material to kill away constant 
> overheads, but beyond that
> is it true that if you double the source size you double the compilation time?

it should be, but we have rather complicated page breaking code that
is so hairy that nobody understands it fully. I'm not sure there is
NP-complete snake in the proverbial grass there.

>> I am not sure what you mean by effort spent
>> in "preparing" callbacks, could you elaborate?
>
>
> Imagine the grob is a C++ object that remains opaque to Scheme. So it's a 
> thing for which
> in Scheme you move around a blind pointer, but to read property Y-offset 
> you'd call (grob-get 'Y-offset)
> and grob-get is C++.
> ..

accessing data (eg. offsets):
* on first access, the callback gets executed. This is just evaluating
(<function> <grob-object>).
* on second access, the value is cached in an alist, and looking it up
is extremely cheap.

> Code following a simple pattern like this, once compiled, will largely be 
> dominated by the
> scripting language runtime overhead

>From the outside this may seem plausible, but I doubt your intuition here:

* the callback tables are also alists. They are cheap (they aren't
sped up if you swap them for hash tables)
* Scheme has no marshaling: objects are either direct (scheme -> C++
is bit twiddling), or they are indirect (a tagged pair with a C++
pointer in the cdr)

IMO The real problem is that we don't have good tooling to see what is
going on in the Scheme side of things: C++ has decent perf analysis,
but the Guile side of things just looks like a lot of time spent in
scm_eval(). Some of it is overhead, some if it might be a poorly
implemented Scheme function (which is often easier to fix than
reducing overhead.)

> (*) 'boxing' is a C# word to mean wrap a POD value in an object to move it 
> around in a way
> that is uniform with the other objects in the language. C# people need to 
> keep boxing and
> unboxing costs in their head in code with lots of PODs being moved around, 
> because that
> cost can dominate the execution of their code. I'm not sure what word is used 
> in Guile for this
> concept.

For integers, floats and booleans, the CPU native representation
involves some bit operations. Intermediate conversions could be
short-cut if you have full type information, and have a sequence of
those in a row.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen