On Thu, Mar 05, 2015 at 08:03:33AM -0800, Joe Perches wrote: > On Thu, 2015-03-05 at 16:22 +0100, Rasmus Villemoes wrote: > > On Sat, Feb 21 2015, Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote: > > > > > [...] decimal conversion [...] it does indeed seem like there is > > > something to be gained, especially on 64 bits. > > > > > > $ ./test64 > > > Distribution Function Cycles/conv Conv/1 sec > > > uniform([10, 2^64-1]) linux_put_dec 127.72 23047567 > > > uniform([10, 2^64-1]) rv_put_dec 60.73 45932786 > > > +/- -52.45% +99.30% > > [...] > > > 3 + neg_binom(0.50) linux_put_dec 16.85 159560933 > > > 3 + neg_binom(0.50) rv_put_dec 12.59 204607570 > > > +/- -25.31% +28.23% > > > > I'm assuming the underwhelming response means NAK. > > Dunno why you assume that, sometimes it just takes > awhile for people to look at non-critical, infrequent > optimization changes like this. > > Seems sensible enough to me though.
I'd like to see how this actually affects larger operations - sth along the line of top consumes D% less CPU cycles w/ N processes - if for nothing else, just to get the sense of scale, but given that we're already trying pretty hard to optimize the divisions there, I too don't see anything wrong with the patch. I haven't studied the code but looks sensible enough on a glance, so, FWIW, Looks-sensible-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
