The Bizarre Case Of Zstd's Very Slow Performance On Arch Linux

[NateHubbard]

This is why personally I never advocated or used source based distros like Gentoo.

That's actually not the issue, so your personal recommendation wouldn't help anyone. At some point, all distros are using source code.
Also, I'm using gentoo and don't have this problem.

[Vistaus]

Michael hi! Some corrections:

• Meson is also slow.

Meson slow? For me as an end-user (I'm no developer) it's one of the fastest.

[jacob]

That's actually not the issue, so your personal recommendation wouldn't help anyone. At some point, all distros are using source code.
Also, I'm using gentoo and don't have this problem.

You are missing the point. Distros compile the source code and then test the binary. Except for rare cases when a problem slips through (like here) you know that the binary has been tested and vetted. On source oriented distros where everyone compiles everything differently, there is no QA of the binaries.

[Mr.Elendig]

Obv the real answer here is that all Arch users should buy 5800X's.

5700x is a better buy in almost all cases.

[DanielG]

Haha, turns out that zstd isn't really slower when built with -std=c99, but its builtin benchmark's time measuring code is broken in that case and thus reporting wrong numbers, https://github.com/facebook/zstd/iss...ent-1159725282 says:

to me it looks like the performance of the binaries is basically identically (at least nowhere as different as in the original comment), and the timing used to calculate throughput is just wrong/broken with multithreading and c90/c99

see also https://lists.freebsd.org/archives/f...er/001183.html

[vladpetric]

Profile, then look at the disassembly ...

[caligula]

Let's face it, it's always something with Arch. When has it ever performed well in a multi-distro benchmark? I can't recall a single time in all these years.

Ubuntu has the best launch perf for desktop app binaries. I mean switching 12900k to 13900k didn't make any sense at first, but the hunger grows. Now look at this, where's my new 900W TDP CPU with 10 GHz single thread xz decompression performance.

[Ghjnut]

This comment didn't mature very well. Turns out the problem was in Michael's measurements and not actual performance. This is why ad hoc benchmarking is useless and even harmful when it stirs up pointless fingerpointing when there is nothing wrong in the first place.

Seems like Michael didn't do anything to validate the measurements except for running the same broken benchmark again and again. You know, it wouldn't be too hard to measure the execution time manually to make sure that the reported time is sane.

If Zstd was actually as broken as the benchmarks suggest, someone surely would have figured it out a long time ago.

Stroooooong disagree. In this case it resulted in a code change for defaults of their cmake builds as well as bringing to light this c99 clock behavior.

https://github.com/facebook/zstd/pull/3167/files

Also, https://www.google.com/search?q=site...com+regression . This is exactly what you would hope for from a third-party test-suite

[curfew]

Stroooooong disagree. In this case it resulted in a code change for defaults of their cmake builds as well as bringing to light this c99 clock behavior.

https://github.com/facebook/zstd/pull/3167/files

Also, https://www.google.com/search?q=site...com+regression . This is exactly what you would hope for from a third-party test-suite

You disagree on the wrong issue. I never said that Phoronix Test Suite is useless. I said Michael's careless acts are harmful. In this case he wrote a provocative article based on false information only because he didn't care to validate his results.

[mos87]

GNU autotools >>> CMAKE confirmed