igzip/riscv64: Optimize deflate performance with vectorized assembly implementation of compare258

[zl523856]

The hot functions in the three parts—icf_body, deflate_body, and update_histogram—are centered around compare258. By implementing a reusable vectorized assembly version of compare258 (i.e., compare258_rvv) using RISC-V vector extensions, while keeping the original C control flow in the outer layers, we can improve deflate performance.

This optimization has been validated with igzip_perf on the Spacemit(R) X100 platform:

igzip_perf -f 0 -y 0 -b 1024 silesia.tar (6% performance improvement)
new：isal_stateful_deflate-> runtime = 4342565 usecs, bandwidth 423 MB in 4.3426 sec = 97.62 MB/s
old：isal_stateful_deflate-> runtime = 4616307 usecs, bandwidth 423 MB in 4.6163 sec = 91.83 MB/s

igzip_perf -f 0 -y 1 -b 1024 silesia.tar (9% performance improvement)
new：isal_stateful_deflate-> runtime = 3975344 usecs, bandwidth 423 MB in 3.9753 sec = 106.64 MB/s
old：isal_stateful_deflate-> runtime = 4322878 usecs, bandwidth 423 MB in 4.3229 sec = 98.06 MB/s

igzip_perf -f 1 -y 0 -b 1024 silesia.tar (10% performance improvement)
new：isal_stateful_deflate-> runtime = 4233799 usecs, bandwidth 423 MB in 4.2338 sec = 100.13 MB/s
old：isal_stateful_deflate-> runtime = 4656209 usecs, bandwidth 423 MB in 4.6562 sec = 91.04 MB/s

igzip_perf -f 1 -y 1 -b 1024 silesia.tar (6% performance improvement)
new：isal_stateful_deflate-> runtime = 5723116 usecs, bandwidth 211 MB in 5.7231 sec = 37.04 MB/s
old：isal_stateful_deflate-> runtime = 6045445 usecs, bandwidth 211 MB in 6.0454 sec = 35.06 MB/s

All tests successful：
PASS: igzip/igzip_rand_test

[zl523856]

I have pulled the zte-riscv:optimize-deflate2 branch locally and run ./tools/test_checks.sh on a Spacemit(R) X100. The test passed successfully. Could the maintainer please trigger the CI again? Thanks! @pablodelara
test_checks.log

[sunyuechi]

Tested on a BPI-F3 (K1) and the CI failure reproduces reliably. This looks like a misaligned access issue.

[zl523856]

Tested on a BPI-F3 (K1) and the CI failure reproduces reliably. This looks like a misaligned access issue.

Thank you for the guidance. I've successfully reproduced the error and am currently working on a fix.

[sunyuechi]

I think we'd better fix the root cause rather than work around it. The problem is the vlse64 in igzip/riscv64/igzip_deflate_hash_rvv.S; it may be solvable by switching to vle8 or similar.

More importantly, these hash computations often end up slower than the scalar code. Did you benchmark igzip/riscv64/igzip_deflate_hash_rvv.S on its own? If it's slower, maybe it's better to
just drop the vectorization of it altogether.

[zl523856]

I think we'd better fix the root cause rather than work around it. The problem is the vlse64 in igzip/riscv64/igzip_deflate_hash_rvv.S; it may be solvable by switching to vle8 or similar.

More importantly, these hash computations often end up slower than the scalar code. Did you benchmark igzip/riscv64/igzip_deflate_hash_rvv.S on its own? If it's slower, maybe it's better to just drop the vectorization of it altogether.

I haven't tested it individually yet. I'll run some additional verification and fix the unaligned access issue in igzip_deflate_hash_rvv.S on the K1 environment.