Add RVV Optimizations for RISC-V Architecture Platforms #1043
No reviewers
Labels
No labels
announcement
bug
build
CI
dependencies
documentation
duplicate
enhancement
experience feedback
feature request
github_actions
help wanted
install
invalid
Long-term
optimization
portability
question
target-specific
test issue
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Cyan4973/xxHash!1043
Loading…
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This Pull Request aims to build upon the previously closed PR (This Pull Request aims to build upon the previously closed PR (#898) by focusing on optimizing xxHash performance for platforms based on the RISC-V architecture through Vector Extension (RVV) optimizations. ) by focusing on optimizing xxHash performance for platforms based on the RISC-V architecture through Vector Extension (RVV) optimizations.And this PR has pass check on qemu with vlen=128,256,512.
For illustration, here are some benchmark numbers, on a Spacemit(R) X60 @1.6 Ghz
command line:
CFLAGS="-march=rv64gcv -O2 -DXXH_FORCE_MEMORY_ACCESS=0" make checkcommand line:
CFLAGS="-O2 -DXXH_FORCE_MEMORY_ACCESS=0" make checkby the way,when I use
CFLAGS="-march=rv64gcv -O3 -DXXH_FORCE_MEMORY_ACCESS=0" make check, Performance with -O3 optimization is unexpectedly lower than with -O2.I still find reason about it
This can indeed happen.
Generally, the main reason is that
-O3tends to bloat the binary size, by generating too many specialized code paths. In a micro benchmark always hitting the same code paths, it's probably a win. But in a real world performance, other factors come in. Larger binary size also means instruction cache get filled more quickly. It can evict other tasks from there. Jumps are larger. etc. The impact on instruction cache, which is often quite small, is likely the main culprit.If
-O2and-O3give roughly the same performance, I would recommend-O2.Problem is, it's difficult to reach this conclusion for all targets simultaneously. It's likely true for some, but not others, that still benefit from
-O3. Hence why the default is generally-O3, because it's supposed to generate the fastest binaries, and this is generally true, just not always.I understand now, thank you so much.I noticed that in the AVX2-optimized code path, the optimization level is explicitly set to -O2 using GCC pragmas:
Should I also use this approach in my code to resolve the problem?
If you imply that
-O2is always better than-O3for yourRVVcode path,then yes.
This conclusion could be more difficult to reach for RISC-V architecture than for
AVX2ones, due to the wider variety of chip designs. I personally don't know the domain enough to tell if it's always true, or generally true, or just sometimes true.OK, I understand. I currently only have one RISC-V computer, and the -O2 optimization is better than -O3 on this machine. I think we should only consider whether to set the optimization level to -O2 in the code if more machines show this situation.Therefore, it's best to keep the current code as it is for now.