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]

Message-ID: <87k2ycprbq.fsf@rasmusvillemoes.dk>
Date:	Thu, 19 Mar 2015 23:15:05 +0100
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.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 Thu, Mar 19 2015, Alexey Dobriyan <adobriyan@...il.com> wrote:

> On Wed, Mar 18, 2015 at 1:04 AM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
>> On Mon, 16 Mar 2015 18:19:41 +0300 Alexey Dobriyan <adobriyan@...il.com> wrote:
>>
>>> Rasmus, I redid benchmarks:
>>
>> tl;dr ;)  Is this an ack or a nack?
>
> New code executes slower for some input on one CPU I've benchmarked,
> both with -O2 and -Os (Core 2 Duo E6550). 

Running Alexey's code on my Core 2 Duo, I can confirm that. However, my
own benchmark did show the claimed 25-50% improvement, depending on
distribution. One difference between our benchmarks is that in Alexey's
case all branches are perfectly predictable - whether that matters I
can't tell [is there a "flush branch prediction" instruction?]. Also, I
found a somewhat subtle flaw in his benchmark [1] which gave the old
code a small (1-2 cycles) advantage. Fixing that and applying the small
tweak I just sent out [2], Alexey's benchmark no longer shows any
difference between the old and new code on the Core 2 Duo.

Rasmus

[1] put_dec was inlined into num_to_str in the old code - in the actual
kernel code, it is and was not, since it has another caller. I somehow
just cargo-culted the noinline_for_stack annotations all over, so it
also wasn't inlined in the benchmark of the new code.

[2] https://lkml.org/lkml/2015/3/19/802
--
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/