diff options
author | Kaleb S. KEITHLEY <kkeithle@redhat.com> | 2019-03-28 09:36:33 -0400 |
---|---|---|
committer | Shyamsundar Ranganathan <srangana@redhat.com> | 2019-04-16 10:48:06 +0000 |
commit | 27a96f1f344d16de8085ace40c2be99c3cd83139 (patch) | |
tree | b7f9303f6d5d6e147860948687282e1f7dea6c60 /xlators/cluster/afr/src/afr-self-heal-data.c | |
parent | c5bc21ebbc10248848b372db34a33a0fcb9ae2ae (diff) |
rpclib: slow floating point math and libm
In release-6 rpc/rpc-lib (libgfrpc) added the function
get_rightmost_set_bit() which calls log2(3), a call that takes
a floating point parameter and returns a floating point.
It's used thusly:
right_most_unset_bit = get_rightmost_set_bit(...);
(So is it really the right-most unset bit, or the right-most set bit?)
It's unclear to me whether this is in the data path or not. If it is,
it's rather scary to think about integer-to-float and float-to-integer
conversions and slow calls to libm functions in the data path.
gcc and clang have __builtin_ctz() which returns the same result as
get_rightmost_set_bit(), and does it substantially faster. Approx
20M iterations of get_rightmost_set_bit() took ~33sec of wall clock
time on my devel machine, while 20M iterations of __builtin_ctz()
took < 9sec; get_rightmost_set_bit() is 3x slower than __builtin_ctz().
And as a side benefit, we can again eliminate the need to link libgfrpc
with libm.
Change-Id: If9e7e80874577c52223f8125b385fc930de20699
fixes: bz#1692957
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
Diffstat (limited to 'xlators/cluster/afr/src/afr-self-heal-data.c')
0 files changed, 0 insertions, 0 deletions