From: Andrew Morton <akpm@linux-foundation.org>
To: zengzhaoxiu@163.com
Cc: linux@horizon.com, peterz@infradead.org, jjuran@gmail.com,
James.Bottomley@HansenPartnership.com, geert@linux-m68k.org,
dalias@libc.org, sam@ravnborg.org, davem@davemloft.net,
Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
James Hogan <james.hogan@imgtec.com>,
Michal Simek <monstr@monstr.eu>,
Ralf Baechle <ralf@linux-mips.org>,
Ley Foon Tan <lftan@altera.com>, Jonas Bonn <jonas@southpole.se>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Chen Liqin <liqin.linux@gmail.com>,
Lennox Wu <lennox.wu@gmail.com>,
linux-kernel@vger
Subject: Re: [patch V4] lib: GCD: Use binary GCD algorithm instead of Euclidean
Date: Fri, 6 May 2016 16:00:41 -0700 [thread overview]
Message-ID: <20160506160041.2b5e47757329c288efaed4fb@linux-foundation.org> (raw)
In-Reply-To: <1462527763-15301-1-git-send-email-zengzhaoxiu@163.com>
On Fri, 6 May 2016 17:42:42 +0800 zengzhaoxiu@163.com wrote:
> From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
>
> The binary GCD algorithm is based on the following facts:
> 1. If a and b are all evens, then gcd(a,b) = 2 * gcd(a/2, b/2)
> 2. If a is even and b is odd, then gcd(a,b) = gcd(a/2, b)
> 3. If a and b are all odds, then gcd(a,b) = gcd((a-b)/2, b) = gcd((a+b)/2, b)
>
> Even on x86 machines with reasonable division hardware, the binary
> algorithm runs about 25% faster (80% the execution time) than the
> division-based Euclidian algorithm.
>
> On platforms like Alpha and ARMv6 where division is a function call to
> emulation code, it's even more significant.
>
> There are two variants of the code here, depending on whether a
> fast __ffs (find least significant set bit) instruction is available.
> This allows the unpredictable branches in the bit-at-a-time shifting
> loop to be eliminated.
>
> ...
>
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -27,6 +27,7 @@ config ALPHA
> select MODULES_USE_ELF_RELA
> select ODD_RT_SIGACTION
> select OLD_SIGSUSPEND
> + select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
> help
argh. Please don't always put new items at end-of-list. That's the
perfect way of maximizing the number of patch collisions. Insert it at
a random position. avoiding the end (if the list isn't alpha-sorted,
which it should be).
<fixes it all up>
>
> ...
>
> --- a/arch/mips/include/asm/cpu-features.h
> +++ b/arch/mips/include/asm/cpu-features.h
> @@ -180,6 +180,16 @@
> #endif
> #endif
>
> +/* __builtin_constant_p(cpu_has_mips_r) && cpu_has_mips_r */
> +#if !((defined(cpu_has_mips32r1) && cpu_has_mips32r1) || \
> + (defined(cpu_has_mips32r2) && cpu_has_mips32r2) || \
> + (defined(cpu_has_mips32r6) && cpu_has_mips32r6) || \
> + (defined(cpu_has_mips64r1) && cpu_has_mips64r1) || \
> + (defined(cpu_has_mips64r2) && cpu_has_mips64r2) || \
> + (defined(cpu_has_mips64r6) && cpu_has_mips64r6))
> +#define CONFIG_CPU_NO_EFFICIENT_FFS 1
> +#endif
#defining a CONFIG_ variable is pretty rude - defining these is the
role of the Kconfig system, not of header files macros.
This was easy:
--- a/arch/mips/include/asm/cpu-features.h~lib-gcd-use-binary-gcd-algorithm-instead-of-euclidean-fix
+++ a/arch/mips/include/asm/cpu-features.h
@@ -187,7 +187,7 @@
(defined(cpu_has_mips64r1) && cpu_has_mips64r1) || \
(defined(cpu_has_mips64r2) && cpu_has_mips64r2) || \
(defined(cpu_has_mips64r6) && cpu_has_mips64r6))
-#define CONFIG_CPU_NO_EFFICIENT_FFS 1
+#define CPU_NO_EFFICIENT_FFS 1
#endif
#ifndef cpu_has_mips_1
--- a/lib/gcd.c~lib-gcd-use-binary-gcd-algorithm-instead-of-euclidean-fix
+++ a/lib/gcd.c
@@ -10,7 +10,7 @@
* has decent hardware division.
*/
-#if !defined(CONFIG_CPU_NO_EFFICIENT_FFS)
+#if !defined(CONFIG_CPU_NO_EFFICIENT_FFS) && !defined(CPU_NO_EFFICIENT_FFS)
/* If __ffs is available, the even/odd algorithm benchmarks slower. */
unsigned long gcd(unsigned long a, unsigned long b)
_
next parent reply other threads:[~2016-05-06 23:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1462527763-15301-1-git-send-email-zengzhaoxiu@163.com>
2016-05-06 23:00 ` Andrew Morton [this message]
2016-05-07 8:41 ` [patch V4] lib: GCD: Use binary GCD algorithm instead of Euclidean George Spelvin
2016-05-07 11:23 ` Sam Ravnborg
[not found] <20160507084129.7284.qmail@ns.horizon.com>
2016-05-07 10:46 ` Andreas Schwab
2016-05-08 12:52 ` Zhaoxiu Zeng
2016-05-06 9:42 zengzhaoxiu
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=20160506160041.2b5e47757329c288efaed4fb@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=ink@jurassic.park.msu.ru \
--cc=james.hogan@imgtec.com \
--cc=jejb@parisc-linux.org \
--cc=jjuran@gmail.com \
--cc=jonas@southpole.se \
--cc=lennox.wu@gmail.com \
--cc=lftan@altera.com \
--cc=linux-kernel@vger \
--cc=linux@arm.linux.org.uk \
--cc=linux@horizon.com \
--cc=liqin.linux@gmail.com \
--cc=mattst88@gmail.com \
--cc=monstr@monstr.eu \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=rth@twiddle.net \
--cc=sam@ravnborg.org \
--cc=schwidefsky@de.ibm.com \
--cc=vgupta@synopsys.com \
--cc=ysato@users.sourceforge.jp \
--cc=zengzhaoxiu@163.com \
--cc=zhaoxiu.zeng@gmail.com \
/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