<Aurora_v_kosmose>orz Debian packages Guile 3.0 but not the guile 3.0 version of guile-gnutls <flatwhatson>is there a better way to get a fresh "user" module for a different language than: (use-modules (system base language)) (set-current-module (default-environment 'prescheme)) <flatwhatson>i was a little surprised that ,language prescheme doesn't put me into the default environment, though it kind of makes sense ***taiju` is now known as taiju
***X-Scale` is now known as X-Scale
<ekaitz>does anyone know why that isn't reviewed? <wingo>civodul: does the guix package recompiler ("guix pull" etc) use threads? i am seeing significant gc overhead for multithreaded allocations in some lab tests, with bdw-gc, not using guix <wingo>am trying to assess how much a better allocator would improve guix <wingo>to try, check out https://github.com/wingo/whippet-gc and make; then test the difference between e.g. "GC_MARKERS=8 taskset -c 0-9 ./bdw-mt-gcbench 3 10" and "GC_TRACERS=8 taskset -c 0-9 ./parallel-whippet-mt-gcbench 3 10" <wingo>if you have 10 or more cores of course <wingo>same heap size, same workload, 10x difference in run times <civodul>wingo: hi! the Guix compilation process does use threads <civodul>i think we cap at 4 threads or so, so the upper bound on heap usage is not too high <wingo>with 4 threads the difference is 2.35x <wingo>i think bdw-gc just has a lot more contention over the heap between allocator threads <civodul>bdw-gc allocates one marker thread per core by default, IIRC <civodul>(i was talking about the number of "user threads") <wingo>you can set the marker thread count explicitly using GC_MARKERS, for bdw-gc <wingo>current name for that is GC_TRACERS in whippet <wingo>but the real issue is contention between mutator threads <drakonis>wingo: will you join us at #guile-steel? <drakonis>wingo: those are some really impressive numbers <dsmith-work>wingo: With all this gc work, does that mean Guile might have one less dependency? <wingo>dsmith-work: i sure hope so1