GNU bug report logs -
#50384
[PATCH] Optimise search-patch (reducing I/O)
Previous Next
Full log
Message #32 received at 50384 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi guix,
This is a v3, without the base16 and base32 optimisations which
are split-off into <https://issues.guix.gnu.org/50456>. It doesn't
seem this patch series will bring improvements, but feel free to test
(in particular, I wonder if this will help people using a remote daemon,
where transmitting data can take (relatively) long?).
(guix scripts hash) is broken, which would need to be fixed in the final
version, if any. Ludovic has some concerns about dependency tracking in
search-patch which need to be adressed.
I think a more fruitful goal is to somehow parallelize the derivation
computation, with multiple separate connections to the store, such that
if one connection is blocking, the other one can be used for something
separate (threads aren't necessary if current-read-waiter,
current-write-waiter and non-blocking I/O are used).
Now, what improvements does this version of the patch series bring?
(Make sure to start the daemon with ./pre-inst-env guix daemon ...,
and set --localstatedir=/var! Some changes to the daemon were made.)
1. RPC count (tested in a local checkout)
After the patch series:
make && GUIX_PROFILING=rpc ./pre-inst-env guix build -d pigx --no-grafts
accepted connection from pid 4917, user [USER]
/gnu/store/jfjfg7dnis7v6947a0rncxdn3y1nz0ad-pigx-0.0.3.drv
Remote procedure call summary: 5754 RPCs
built-in-builders ... 1
add-to-store ... 3
add-to-store/tree ... 26
add-temp-root-and-valid-path? ... 195
add-text-to-store ... 5529
After the patch series, with (if sha256 ...) replaced with (if #f ...)
in (guix gexp), to simulate the situation before the patch series
/gnu/store/jfjfg7dnis7v6947a0rncxdn3y1nz0ad-pigx-0.0.3.drv
Remote procedure call summary: 5749 RPCs
built-in-builders ... 1
add-to-store/tree ... 26
add-to-store ... 193
add-text-to-store ... 5529
(add-to-store RPCs are converted to add-temp-root-and-valid-path? RPCs)
2. Timing
First do
echo powersave | sudo tee /sys/devices/system/cpu/cpu{0,1,2,3}/cpufreq/scaling_governor
to eliminate CPU frequency scaling effects.
To automatically repeat the tests and compute the standard deviation,
'hyperfine' is used:
HYP=/gnu/store/3ya4iw6fzq1ns73bv1g3a96jvwhbv60c-hyperfine-1.11.0/bin/hyperfine
To determine the effect of the change to 'local-file-compiler' and
'search-patch' and nothing else, I will compare the performance of guix
after the patch series with the performance of guix after the patch series
and 'sha256' replaced by #false.
With #f, --runs=60:
make && ./pre-inst-env $HYP --runs=60 --warmup 1 -- 'guix build -d pigx --no-grafts'
Time (mean ± σ): 15.428 s ± 0.385 s [User: 15.925 s, System: 0.652 s]
Range (min … max): 14.768 s … 16.550 s 60 runs
With sha256, --runs=60
make && ./pre-inst-env $HYP --runs=60 --warmup 1 -- 'guix build -d pigx --no-grafts'
Time (mean ± σ): 15.493 s ± 0.252 s [User: 15.585 s, System: 0.680 s]
Range (min … max): 14.981 s … 16.294 s 60 runs
These numbers don't have a clear difference. Maybe statistics can help? First,
formulate a null-hypothesis. As the total number of RPCs didn't change, the amount
of data sent to the daemon is reduced and some "stats", "open" and "reads" are avoided,
I would expect that the mean decreases. Thus, as null-hypothesis, I choose:
H0: the (theoretical) mean for ‘with sha256’ is less than the mean for ‘with #f’
In the timing tests, the observed mean for 'with sha256’ is actually larger.
But is this significant?
guix environment --ad-hoc r
before.mean = 15.428
before.stddev = 0.385
after.mean = 15.493
after.stddev = 0.252
samples = 60
# ‘statistical’ crate used by hyperfine
# performs N/(N-1) correction XXX
t = (before.mean - after.mean)/(sqrt(samples) * sqrt(before.stddev^2 + after.stddev^2))
v = (samples - 1) * (before.stddev^2 + after.stddev^2)^2/(before.stddev^4 + after.stddev^4)
q = dt(-t, v); q
# p-value: 0.5072571
# Null-hypothesis is not rejected
It's not rejected, though that doesn't prove much since t is almost zero,
so this test cannot reject the hypothesis ‘the means are equal’ or ‘the patch
series makes things slower’ either.
I don't think this patch series helps on my laptop (at least on a hot disk cache, I'd have
to check for a cold cache). However, I wonder if this would help a little for people
using a remote build daemon (with a nfs setup or something) (see GUIX_DAEMON_SOCKET)?
Greetings,
Maxime.
[0001-build-self-Implement-basic-hash-algorithm.patch (text/x-patch, attachment)]
[0002-guix-hash-Extract-file-hashing-procedures.patch (text/x-patch, attachment)]
[0003-store-Define-new-add-temp-root-and-valid-path-operat.patch (text/x-patch, attachment)]
[0004-store-Add-compatibility-fall-back-for-add-temp-root-.patch (text/x-patch, attachment)]
[0005-gexp-Allow-computing-the-hash-of-the-local-file-in-a.patch (text/x-patch, attachment)]
[0006-gexp-Allow-overriding-the-absolute-file-name.patch (text/x-patch, attachment)]
[0007-packages-Compute-the-hash-of-patches-in-advance-when.patch (text/x-patch, attachment)]
[0008-compile-all-compile-Keep-track-of-dependencies-of-co.patch (text/x-patch, attachment)]
[0009-packages-Add-patches-to-the-dependency-list-of-packa.patch (text/x-patch, attachment)]
[0010-gexp-Do-not-intern-if-the-file-is-already-in-the-sto.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 3 years and 246 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.