git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Noonan <steven@uplinklabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Giuseppe Scrivano" <gscrivano@gnu.org>,
	"Pádraig Brady" <P@draigbrady.com>,
	Bug-coreutils@gnu.org, "Git Mailing List" <git@vger.kernel.org>
Subject: Re: Linus' sha1 is much faster!
Date: Mon, 17 Aug 2009 14:43:55 -0700	[thread overview]
Message-ID: <f488382f0908171443n7fa92342v1ac12f52a17fd048@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.01.0908170852320.3162@localhost.localdomain>

On Mon, Aug 17, 2009 at 9:22 AM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 17 Aug 2009, Steven Noonan wrote:
>>
>> Interesting. I compared Linus' implementation to the public domain one
>> by Steve Reid[1]
>
> You _really_ need to talk about what kind of environment you have.
>
> There are three major issues:
>  - Netburst vs non-netburst
>  - 32-bit vs 64-bit
>  - compiler version

Right. I'm running a Core 2 "Merom" 2.33GHz. The code was compiled for
x86_64 with GCC 4.2.1. I didn't _expect_ it to compile for x86_64, but
apparently the version of GCC that ships with Xcode 3.2 defaults to
compiling 64-bit code on machines that are capable of running it.

>
> Steve Reid's code looks great, but the way it is coded, gcc makes a mess
> of it, which is exactly what my SHA1 tries to avoid.
>
> [ In contrast, gcc does very well on just about _any_ straightforward
>  unrolled SHA1 C code if the target architecture is something like PPC or
>  ia64 that has enough registers to keep it all in registers.
>
>  I haven't really tested other compilers - a less aggressive compiler
>  would actually do _better_ on SHA1, because the problem with gcc is that
>  it turns the whole temporary 16-entry word array into register accesses,
>  and tries to do register allocation on that _array_.
>
>  That is wonderful for the above-mentioned PPC and IA64, but it makes gcc
>  create totally crazy code when there aren't enough registers, and then
>  gcc starts spilling randomly (ie it starts spilling a-e etc). This is
>  why the compiler and version matters so much. ]
>
>> (average of 5 runs)
>> Linus' sha1: 283MB/s
>> Steve Reid's sha1: 305MB/s
>
> So I get very different results:
>
>        #             TIME[s] SPEED[MB/s]
>        Reid            2.742       222.6
>        linus           1.464         417

Added -m32:

Steve Reid: 156MB/s
Linus: 209MB/s

So on x86, your code really kicks butt.

> this is Intel Nehalem, but compiled for 32-bit mode (which is the more
> challenging one because x86-32 only has 7 general-purpose registers), and
> with gcc-4.4.0.
>
>                        Linus
>

  reply	other threads:[~2009-08-17 21:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-14 23:25 Linus' sha1 is much faster! Pádraig Brady
2009-08-15 20:02 ` Bryan Donlan
2009-08-15 20:12   ` John Tapsell
2009-08-15 20:23     ` Linus Torvalds
2009-08-15 20:54       ` Linus Torvalds
2009-08-17  1:55         ` Nicolas Pitre
2009-08-26 11:39           ` Pádraig Brady
2017-04-20 21:35             ` galt
2017-04-20 21:38             ` galt
2009-08-17  8:22         ` Andreas Ericsson
2009-08-16  0:06     ` Theodore Tso
2009-08-16 19:25 ` Giuseppe Scrivano
2009-08-16 20:10   ` Linus Torvalds
2009-08-16 22:15     ` Giuseppe Scrivano
2009-08-16 22:47       ` Linus Torvalds
2009-08-17  1:53   ` Pádraig Brady
2009-08-17 10:51     ` Giuseppe Scrivano
2009-08-17 15:44       ` Steven Noonan
2009-08-17 16:22         ` Linus Torvalds
2009-08-17 21:43           ` Steven Noonan [this message]
2009-08-17 17:32         ` Giuseppe Scrivano
  -- strict thread matches above, loose matches on Subject: below --
2009-08-17  7:23 George Spelvin
2009-08-17 14:20 ` Nicolas Pitre
2009-08-17 17:06 ` Nicolas Pitre
2009-08-17 17:20   ` Paolo Bonzini
2009-08-17 18:54   ` George Spelvin
2009-08-17 19:34     ` Nicolas Pitre
2009-08-17 23:12       ` George Spelvin

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=f488382f0908171443n7fa92342v1ac12f52a17fd048@mail.gmail.com \
    --to=steven@uplinklabs.net \
    --cc=Bug-coreutils@gnu.org \
    --cc=P@draigbrady.com \
    --cc=git@vger.kernel.org \
    --cc=gscrivano@gnu.org \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).