IRC channel logs

<rlb>ekaitz: I assume the thing you're running spawns multiple threads?

<ekaitz>rlb: it doesn't, but if I run `time guile ...` it uses a 140% of CPU

<ekaitz>and has more user time than wall time

<rlb>Guile by default, I think has some internal thread(s), e.g. the signal handling thread, though that one should never be doing much. I don't recall whether or not the gc, for example, does work in its own thread.

<rlb>(that, or something like it, may be what you're seeing)

<ekaitz>yeah, I suppose

<ekaitz>i guess i cannot flatten that in any way

<rlb>And right, if you really need to limit it to real time == run time, you'll need cgroups or something.

<rlb>I suspect.

<rlb>i.e. force the kernel to restrict it to "a single cpu's worth".

<ekaitz>okay

<ekaitz>i can just ignore it really

<ekaitz>but I wanted to know what was the impact of restricting it to one cpu

<rlb>As long as you track the user/system/wall clock times you can at least compare things regardless of how many cores were used, but if you actually care about "serialized performance", then that's different. (/usr/bin/time -v PROG ... is sometimes handy for summaries).

<rlb>(not shell "time ...")

<ekaitz>yeah, GNU Time

<ekaitz>i'm using it already

<ekaitz>i'll try that verbose output and see what I get

<ekaitz>thanks

<mwette>ekaitz: I believe you can configure guile build with `--without-threads'

<ekaitz>mwette: that's interesting!

<mwette>not sure that stops the gc

<mwette>my guess is the gc woudl be syncrhonous with the single process thread.

<ekaitz>that should be, yeah

<ekaitz>i may try later, but also my case here I don't think it deserves that much effort

IRC channel logs

2026-06-28.log