$ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c --single-thread | wc -c
16307922
$ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c -T1 | wc -c
16308523
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-sof
Hmm, I don't think ZSTDMT_compress_advanced_internal is used in out use case,
so disregard the comment about the influence of the thread number. (I'm not
100% sure, though, the zstd source code is somewhat cryptic to me.)
--
You are receiving this because you are subscribed to this thread.
Repl
Possibly related: https://github.com/rpm-software-management/rpm/issues/1304
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/963#issuecomment-658035631
Had a quick chat on IRC with @ffesti and he said it's actually just three
outcomes that rpmbuild may return; success (0), error (1) or missing build deps
(11), in which case adding all three into the man page would be worthwhile.
I'll skim through the code to double-check and go ahead with that.
Also note that threading mode with one thread (T1) is *not* unthreaded mode.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658032466_
But was it identical? Zstd upstream said that it is different.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658032043___
> it compresses a bit worse
I was testing it on xonotic-data and it was 873M in single-threaded compression
and the same size in multi-threaded mode.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-so
I'm also not so sure about the "the multi-threaded output produces the same
compressed data no matter how many threads you use" statement, because the
block size seems to depend on the number of workers (see
ZSTDMT_compress_advanced_internal).
--
You are receiving this because you are subscrib
Note that the zstd people *did* say that threaded compression has a different
output than unthreaded operation: it compresses a bit worse. So the pull
request will break delta rpms.
Can you please change the code so that it uses unthreaded mode if there is no
'T' in the compression flags? I.e.