Possible performance regressions on some CPUs after #3449 (C fast loops) about zstd

[iksaif]

Thanks for the update, I'll try this out in the next few weeks!

[terrelln]

Hi @iksaif sorry for the delay, but I have several updates:

1. PR #3827 drastically speeds up the fast C & assembly Huffman decoders on very small data like in the github corpus.
2. PR #3826 may improve c7g Graviton 3 performance. It manually unrolls the inner loops, because I've found that in certain scenarios the compiler wasn't unrolling the inner loops. If that was the case for c7g, then I would expect significant performance improvements.
3. PR #3826 also provides the ability to disable the fast C decoding loops at compile time by defining the C macro HUF_DISABLE_FAST_DECODE, in case you still see subpar performance after these PRs.

Please let me know if you see any more issues with performance after these PRs, and we will look into them. I can't guarantee a super fast turnaround time, but we always try to handle outstanding issues before we make releases.

[iksaif]

👋 any finding ? thanks!

[iksaif]

I can confirm that the latest version from git is back to v1.5.2 level of performances on c7g !

 1# 9114 files       :   7484607 ->   2603666 (x2.875),  183.3 MB/s,  435.3 MB/s
 1#silesia.tar       : 211957760 -> 132055991 (x1.605),  700.0 MB/s, 1143.6 MB/s

[iksaif]

CC: @terrelln since you authored the original PR you are probably interested about this

I haven't looked at why things might be slower, but given the results it might be interesting to offer the option to not build the generic C versions of the fast decoding loops since it's unclear that they offer a significant performance boost on modern CPUs and compilers

Also maybe I did something wrong in those tests, I'm happy to re-run them if necessary

[iksaif]

This also relates to:

• #3278 - which shows that assembly versions are not as performant as we think (for benchmark 1)
• #3155 which looks at custom ASM functions for aarch64 (but it looks like trusting the compiler could be faster)

[terrelln]

Thanks for the report @iksaif!

I will spend some time investigating next week.

At first glance, the performance on c7g Graviton 3 looks bad across the board. But, everything else has just regressed the GitHub case, which is a bunch of small files. Which maybe suggests that we need to either improve the Fast-C & ASM loops for small literals sections, or automatically use the old code versions for small literals sections.

[terrelln]

Great, I'm glad to hear it! Looks like it was running into the loop unrolling problem.