From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933114AbbCEQK5 (ORCPT ); Thu, 5 Mar 2015 11:10:57 -0500 Received: from mail-qc0-f179.google.com ([209.85.216.179]:35664 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933093AbbCEQKz (ORCPT ); Thu, 5 Mar 2015 11:10:55 -0500 Date: Thu, 5 Mar 2015 11:10:51 -0500 From: Tejun Heo To: Joe Perches Cc: Rasmus Villemoes , linux-kernel@vger.kernel.org, "Peter Zijlstra (Intel)" , Andrew Morton Subject: Re: [RFC] lib/vsprintf.c: Even faster decimal conversion Message-ID: <20150305161051.GE23912@htj.duckdns.org> References: <1424476281-26873-1-git-send-email-linux@rasmusvillemoes.dk> <87r3t3eafm.fsf@rasmusvillemoes.dk> <1425571413.31859.1.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1425571413.31859.1.camel@perches.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 Thanks. -- tejun