Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
app-arch/zstd: multithreaded compression by default (#598)
Integration of Clear Linux's 'multi-thread-default.patch' By default, zstd uses one core for compression. This patch makes zstd use all physical cores detected for compression, increasing performance and reducing compression time. Below's results are from using zstd's built-in benchmark, showing a decrease of 78.13% in compression time with -T0. The benefit is only apparent if compression is CPU-bound and will differ based on machine and file contents. Default (-T1) 19#linux-5.8.tar : 983869440 -> 121381009 (8.106), 4.05 MB/s ,1771.3 MB/s zstd -T1 -b19 -i0 --priority=rt linux-5.8.tar 244.99s user 0.46s system 99% cpu 4:05.47 total Patched default (-T0) 19#linux-5.8.tar : 983869440 -> 121384544 (8.105), 19.2 MB/s ,1756.7 MB/s zstd -T0 -b19 -i0 --priority=rt linux-5.8.tar 297.19s user 0.63s system 554% cpu 53.692 total Source: https://github.com/clearlinux-pkgs/zstd/blob/1.4.5-60/multi-thread-default.patch References: #164
- Loading branch information
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not apply to zstd-1.4.4, which is the current stable version. can you please revert it?
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Jannik2099 I don't think that you should expect from an experimental overlay to cater to your stable needs
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has nothing to do with experimental vs stable, this patch was simply not tested before getting committed. The majority of users run stable on non-user applications, there's no good reason for this overlay shipping stuff that breaks default configs.
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overlay is not for majority of the users, even its recommends like gcc 10 are from testing
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, there is no reason to DELIBERATELY break stuff for people. You'll find a good chunk of package.cflags only applies to specific stable versions aswell
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disregarding my previous comments. I don't really get what the problem is, this should only apply to 1.4.5? Does it break 1.4.4?
Nvm, it's applied to all.
Revert is not needed just lock it to a version.
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the patch doesn't apply to 1.4.4 , which causes the build to fail
Patches can be restricted to >= just like normal ebuilds by renaming the directory, could we do this perhaps? (assuming the patch bashrc can do that aswell)
579ed2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it works the same, you can even do it on your own by renaming the dir [ I know that it will break repo updates since it introduces changes to a git dir which is super annoying ]