linux-kernel - Re: + lib-vsprintfc-even-faster-decimal-conversion.patch added to -mm tree

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]

Date:	Mon, 16 Mar 2015 18:19:41 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Tejun Heo <tj@...nel.org>,
	Denis Vlasenko <vda.linux@...glemail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: + lib-vsprintfc-even-faster-decimal-conversion.patch added to -mm tree

On Sat, Mar 14, 2015 at 12:21 PM, Alexey Dobriyan <adobriyan@...il.com> wrote:

Rasmus, I redid benchmarks:
* time is folded into average/variance immediately,
it didn't change anything of importance
* batched conversion in a loop, still removing results where interrupt
intervened

It became worse :-)

On this box some numbers are converted _slower_ with your changes.
Numbers are stable (average, min, max).

New code becomes noticeably faster around ~100000 and up.
But these speedups are diluted because num_to_str() takes ~2% of
top(1)'s CPU time with 5000 processes.

# 3.19.1
$ taskset -c 1 ./bb1 1000000 1000
0                     13114.776199 +- 114.942115   13097-15981
1                     13107.875655 +- 69.779029    13097-16275
10                    31091.129391 +- 4.638450     31087-32529
100                   34098.031121 +- 3.870317     34097-34615
255                   34098.028937 +- 3.714863     34090-34622
1000                  37101.041166 +- 4.003837     37100-38276
10000                 50760.840697 +- 30.528328    50750-52143
65535                 50760.825472 +- 30.126764    50750-52101
100000                59608.431078 +- 8.414339     59605-60144
1000000               77101.574543 +- 6.524058     77077-77637
10000000              88638.113739 +- 723.057589   88095-90125
100000000             86092.934347 +- 6265.582344  84105-106407
4294967295           118092.229892 +- 55.223289   110152-118699
18446744073709551615 210586.971532 +- 62.836890   209125-211120

# 3.19.1+diff
$ taskset -c 1 ./bb2 1000000 1000
0                     12093.654853 +- 9.896411     12089-12789
1                     12093.352964 +- 8.099249     12089-12838
10                    31093.928544 +- 62.655080    28091-34587
100                 * 40688.594709 +- 10.637530    39256-41195
255                 * 40688.571161 +- 10.667900    39991-41195
1000                * 42095.428977 +- 75.946830    39704-42623
10000               * 51724.895173 +- 6.051896     51135-52248
65535               * 51724.839467 +- 6.205925     51114-52241
100000                53103.076152 +- 20.832946    53081-54103
1000000               59602.515756 +- 10.729477    59598-60137
10000000              61104.239490 +- 23.073365    61096-62629
100000000             70857.128601 +- 31.596224    70854-72660
4294967295            79101.747725 +- 32.571835    79093-81102
18446744073709551615 132183.241400 +- 871.759411  122451-134869

I'm attaching full tarball so there is no ambiguity what is measured
and what is not.

    Alexey

Download attachment "num-to-str.tar.gz" of type "application/x-gzip" (6804 bytes)