summaryrefslogtreecommitdiffstats
path: root/xlators/mgmt
diff options
context:
space:
mode:
authorKaleb S. KEITHLEY <kkeithle@redhat.com>2019-03-28 09:36:33 -0400
committerAmar Tumballi <amarts@redhat.com>2019-04-03 04:40:15 +0000
commit024cafea8965086267645be0eae86bcdf5a5d106 (patch)
tree440b86b81dd67f4cc071ccfd2ba97ae285deb5bd /xlators/mgmt
parentcada4b432e9373c3ff8423a23c41a455aba4fc4a (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')
0 files changed, 0 insertions, 0 deletions