linux-kernel - Re: [RFC] lib/vsprintf.c: Even faster decimal conversion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150305161051.GE23912@htj.duckdns.org>
Date:	Thu, 5 Mar 2015 11:10:51 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Rasmus Villemoes <linux@...musvillemoes.dk>,
	linux-kernel@...r.kernel.org,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [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@...musvillemoes.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@...nel.org>

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/