Re: Git and GCC

From: J.C. Pizarro <jcpiza@gmail.com>
Date: Dec 8, 2007, 02:21 UTC
Message-ID: <998d0e4a0712071821o520a75c4lbcaae92256071f48@mail.gmail.com>

On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:

Show 20 quoted lines

> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc.  It's been on my TODO list to code up the crypto
> > unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> > the userland interfaces to take advantage of that in things like
> > libssl.  Even a better C/asm version would probably improve GIT
> > performance a bit.
>
> I doubt yu can use the hardware support. Kernel-only hw support is
> inherently broken for any sane user-space usage, the setup costs are just
> way way too high. To be useful, crypto engines need to support direct user
> space access (ie a regular instruction, with all state being held in
> normal registers that get saved/restored by the kernel).
>
> > Is SHA a significant portion of the compute during these repacks?
> > I should run oprofile...
>
> SHA1 is almost totally insignificant on x86. It hardly shows up. But we
> have a good optimized version there.

If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds) that it's faster than SHA1? And to optimize still more it with SIMD instructions in kernelspace and userland.

Show 6 quoted lines

>
> zlib tends to be a lot more noticeable (especially the uncompression: it
> may be faster than compression, but it's done _so_ much more that it
> totally dominates).
>
> 			Linus

It's better

1.   "Don't compress this repo but compact this uncompressed repo
      using minimal spanning forest and deltas"
2.   "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
      burning it to DVD for backup reasons or before replicating it to
internet".

   J.C.Pizarro "the noiser"