Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
crc32c: Add ppc64le fast zero optimized assembly. #15100
branch-predictor left a comment
Unfortunately I don't have any PPC hardware at hand, so I can't test it myself, and I have no former experience with PPC either, so I can't be particularly elaborate in your case, sorry. Still, a few general nits.
Changing the reflect32 used in the ppc64le fastzero path was a big help! In order to avoid any issues with licensing I simply used a better version of this function that was already included in the Ceph codebase (see the _reverse_bits function in src/common/hobject.h).
I had previously wanted to measure against @aclamk 's pull request #11966 so I setup a git repo to test the fastzero code in isolation. I linked this in the other pull request but I'll link here again for convenience.
Link to the test program:
My conclusions are posted in the repo itself, here:
Now that reflect32 is faster, I had to retest and update the conclusions at the above link. My new conclusion is that on ppc64le the optimized assembly fastzero algorithm is faster than @aclamk 's fastzero algorithm in #11966. On x86 architecture @aclamk 's fastzero algorithm is faster than the optimized x86 assembly.
Sorry for the delay in getting this updated. @branch-predictor had made a review comment about common code between src/common/crc32c_ppc.c and src/common/hobject.h. I also wanted to update to the latest code to integrate with #11966 but then I ran into some problems compiling on ppc64le architecture with latest master.
The issue is described here:
Once I've tested that one I'll make the pull request, then resume this drop.
referenced this pull request
May 31, 2017
Not sure if this was ever officially approved by @branch-predictor. Does that need to happen before it can be retested in the CI environment?
I'd prefer not to move these functions from reverse.cc into a .h file, just because those functions are already being called from both C++ and C files, and making them inline functions (or C++ class related functions that are called from C code) just adds to that complexity.
Please let me know if that is ok. If not and you're waiting on me to take the next action by rewriting some of this please let me know.
@kestrels My only objection is adding extra .cc/.h for just two functions, it's not a showstopper or some kind of criminal offense. Besides, I have no way to do a live test of your code, so please don't consider me as some kind of official Ceph authority. ;)