diff options
author | Kaleb S. KEITHLEY <kkeithle@redhat.com> | 2019-03-28 09:36:33 -0400 |
---|---|---|
committer | Amar Tumballi <amarts@redhat.com> | 2019-04-03 04:40:15 +0000 |
commit | 024cafea8965086267645be0eae86bcdf5a5d106 (patch) | |
tree | 440b86b81dd67f4cc071ccfd2ba97ae285deb5bd /xlators/mgmt/glusterd/src/glusterd-volgen.c | |
parent | cada4b432e9373c3ff8423a23c41a455aba4fc4a (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.
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 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
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
Diffstat (limited to 'xlators/mgmt/glusterd/src/glusterd-volgen.c')
0 files changed, 0 insertions, 0 deletions