lkml.org 
[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] lib/vsprintf.c: Even faster decimal conversion
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 <linux@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 <tj@kernel.org>

Thanks.

--
tejun


\
 
 \ /
  Last update: 2015-03-05 17:21    [W:0.224 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site