threads / discuss / 11185

Re: Git and GCC

Subject: Re: Git and GCC

## tl;dr

6 messages between Dec 8, 2007 and Dec 15, 2007.

replies: 5people: 6as markdown or json

J.C. Pizarro· Dec 8, 2007, 02:21 UTC · lore
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"
Johannes Schindelin· Dec 8, 2007, 12:24 UTC · re: J.C. Pizarro · lore
Hi,
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
Show 8 quoted lines
> On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
>
> > 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.
He said SHA-1 is insignificant.
Show 11 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).
> 
> 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".
Patches? ;-)

Ciao, Dscho

Joe Buck· Dec 8, 2007, 19:53 UTC · re: Johannes Schindelin · lore
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
Show 5 quoted lines
> > 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".
On Sat, Dec 08, 2007 at 12:24:00PM +0000, Johannes Schindelin wrote:
> Patches? ;-)

git list, meet J.C. Pizarro. Care to take him off of our hands for a while? He's been hanging on the gcc list for some time, and perhaps seeks new horizons.

Mr. Pizarro has endless ideas, and he'll give you some new ones every day. He thinks that no one else knows any computer science, and he will attempt to teach you what he knows, and tell you to rewrite all of your code based on something he read and half-understood. But he's not interested in actually DOING the work, mind you; that's up to you. When you object that he's wasting your time, he'll start talking about freedom of speech.

Marco Costalba· Dec 8, 2007, 20:28 UTC · re: Joe Buck · lore
On Dec 8, 2007 8:53 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
> Mr. Pizarro has endless ideas, and he'll give you some new ones every day.
That's true.
> He thinks that no one else knows any computer science, and he will attempt
> to teach you what he knows,
It's not the only one ;-) is in good and numerous company.
>  But he's not interested in
> actually DOING the work, mind you; that's up to you.
Where did have you read this ? I missed that part.
>  When you object
> that he's wasting your time, he'll start talking about freedom of speech.
>
Actually he never spoke like that (probably I missed that part too).

Thanks Marco

Daniel Berlin· Dec 9, 2007, 01:51 UTC · re: Marco Costalba · lore
Show 10 quoted lines
>
> Where did have you read this ? I missed that part.
>
> >  When you object
> > that he's wasting your time, he'll start talking about freedom of speech.
> >
>
> Actually he never spoke like that (probably I missed that part too).
>
>
Read gcc mailing list archives, if you have a lot of time on your hands.
Nix· Dec 15, 2007, 00:18 UTC · re: Johannes Schindelin · lore
On 8 Dec 2007, Johannes Schindelin said:
Show 14 quoted lines
> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
>>
>> > 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.
>
> He said SHA-1 is insignificant.

Actually davem also said it *is* significant on SPARC. But of course J. C. Pizarro's suggested solution won't work because you can't just go around replacing SHA-1 in git with something else :) you could *add* new hashing methods, but you couldn't avoid SHA-1, and adding a new hashing method would bloat every object and every hash in objects like commits with an indication of which hashing method was in use.

(But you know this.)
>> 1.   "Don't compress this repo but compact this uncompressed repo
>>       using minimal spanning forest and deltas"
... and then you do a git-gc. Oops, now what?

... or perhaps you want to look something up in the pack. Now you have to unpack a large hunk of the whole damn thing.

Show 5 quoted lines
>> 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".
>
> Patches? ;-)

Replicating a pack to the internet is almost invariably replicating *parts* of a pack anyway, which reduces to the problem with option 1 above...

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
                                                   describes USENET

← back to recent threads