Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys <address@hidden> wrote:
>
>> The GUILE 2.0 release
>>
>>   https://lwn.net/Articles/428288/
>>
>> has one big red flag for me.
>>
>>   * Switch to the Boehm-Demers-Weiser garbage collector
>>
>
> We can easily measure this, by adding the following to
>
> #(display (version))
> #(display " gc time taken: ")
> #(display (* 1.0 (/ (cdr (assoc 'gc-time-taken (gc-stats)))
> internal-time-units-per-second)))
> #(display "\n")
>
> on mozart-hrn-3, over 3 runs, we get
>
> 2.0.14  - avg 2.1s
> 1.8.8 - avg 0.31s
>
> so the new GC is about 5-10x slower than the old one. With GUILE 1.8,
> garbage collection covers typically is 10% of the runtime, so all things
> equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total.
>
> It would be good to see how the JITting of code impacts Scheme
> execution.

Boehm GC can work in a background thread I think.  And Guile-v2
applications typically just let all their data be treated as pointers
rather than using a smob-marking algorithm like we do, and it is
conceivable that Boehm GC's individual mark function does not scale.

However, considering everything a pointer for a 32bit application that
can eat a significant ratio of the total address space is a nightmare:
there would be just too much memory pinned down due to conservative
garbage collection.

On a 64bit application, this would be somewhat more tenable, but we'd
need to override operator new for smobs.

Or do we?  Maybe the heap is collected by default, and we need to switch
that off?

-- 
David Kastrup