mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Tejun Heo <tj@kernel.org>, Joe Perches <joe@perches.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] lib/vsprintf.c: Even faster decimal conversion
Date: Wed, 11 Mar 2015 14:52:29 -0700	[thread overview]
Message-ID: <20150311145229.523118d7190cebece1304d2a@linux-foundation.org> (raw)
In-Reply-To: <1426028472-19614-1-git-send-email-linux@rasmusvillemoes.dk>

On Wed, 11 Mar 2015 00:01:11 +0100 Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

> The most expensive part of decimal conversion is the divisions by 10
> (albeit done using reciprocal multiplication with appropriately chosen
> constants). I decided to see if one could eliminate around half of
> these multiplications by emitting two digits at a time, at the cost of
> a 200 byte lookup table, and it does indeed seem like there is
> something to be gained, especially on 64 bits. Microbenchmarking shows
> improvements ranging from -50% (for numbers uniformly distributed in
> [0, 2^64-1]) to -25% (for numbers heavily biased toward the smaller
> end, a more realistic distribution).
> 
> On a larger scale, perf shows that top, one of the big consumers of
> /proc data, uses 0.5-1.0% fewer cpu cycles.
> 
> I had to jump through some hoops to get the 32 bit code to compile and
> run on my 64 bit machine, so I'm not sure how relevant these numbers
> are, but just for comparison the microbenchmark showed improvements
> between -30% and -10%.
> 
> The bloat-o-meter costs are around 150 bytes (the generated code is a
> little smaller, so it's not the full 200 bytes) on both 32 and 64
> bit. I'm aware that extra cache misses won't show up in a
> microbenchmark as used above, but on the other hand decimal
> conversions often happen in bulk (for example in the case of top).
> 
> I have of course tested that the new code generates the same output as
> the old, for both the first and last 1e10 numbers in [0,2^64-1] and
> 4e9 'random' numbers in-between.
> 
> ...
>
> Test and verification code on github
> <https://github.com/Villemoes/dec>.  It would be nice if someone could
> verify the code on architectures other than x86 - in particular, I
> believe it _should_ work on big-endian, but I have no way of testing
> that. Benchmark numbers would be nice too, of course.

That would be nice.

It would be best to make this as easy as possible for people.  Create a
tarball, attach that to a request sent to linuxppc-dev@lists.ozlabs.org
along with simple instructions along the lines of

	tar xfz tarball.tar.gz
	cd ./dec
	make
	./whatever

and magic might happen!

  reply	other threads:[~2015-03-11 21:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20 23:51 [RFC] " Rasmus Villemoes
2015-03-05 15:22 ` Rasmus Villemoes
2015-03-05 16:03   ` Joe Perches
2015-03-05 16:10     ` Tejun Heo
2015-03-05 22:24       ` Rasmus Villemoes
2015-03-10 10:47         ` Rasmus Villemoes
2015-03-10 12:42           ` Tejun Heo
2015-03-10 12:57             ` Rasmus Villemoes
2015-03-10 23:01               ` [PATCH v1] " Rasmus Villemoes
2015-03-11 21:52                 ` Andrew Morton [this message]
2015-03-19 21:41                   ` Rasmus Villemoes
2015-03-12 18:49                 ` Jeff Epler
2015-03-13  0:08                 ` Jeff Epler
2015-03-13  0:30                   ` Jeff Epler
2015-03-13  8:58                 ` [PATCH] lib/vsprintf.c: silence sparse warnings about decpair[] initialization Rasmus Villemoes
2015-03-19 21:44                   ` [PATCH] lib/vsprintf.c: improve put_dec_trunc8 slightly Rasmus Villemoes
2015-03-18  0:50 ` [RFC] lib/vsprintf.c: Even faster decimal conversion Denys Vlasenko
2015-03-18  0:52   ` Denys Vlasenko
2015-03-18 17:10   ` Rasmus Villemoes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150311145229.523118d7190cebece1304d2a@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome