{"thread":{"id":"11185","subject":"Re: Git and GCC","startedAt":"2007-12-08T02:21:40Z","lastAt":"2007-12-15T00:18:37Z","messageCount":6,"participants":["J.C. Pizarro","Johannes Schindelin","Joe Buck","Marco Costalba","Daniel Berlin","Nix"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"62358","messageId":"998d0e4a0712071821o520a75c4lbcaae92256071f48@mail.gmail.com","threadId":"11185","inReplyTo":null,"subject":"Re: Git and GCC","fromName":"J.C. Pizarro","fromEmail":"jcpiza@gmail.com","sentAt":"2007-12-08T02:21:40Z","receivedAt":"2007-12-08T02:21:40Z","isPatch":false,"sender":{"key":"jcpiza@gmail.com","avatar":null},"body":"On 2007/12/07, \"Linus Torvalds\" wrote:\n> On Fri, 7 Dec 2007, David Miller wrote:\n> >\n> > Also I could end up being performance limited by SHA, it's not very\n> > well tuned on Sparc. It's been on my TODO list to code up the crypto\n> > unit support for Niagara-2 in the kernel, then work with Herbert Xu on\n> > the userland interfaces to take advantage of that in things like\n> > libssl. Even a better C/asm version would probably improve GIT\n> > performance a bit.\n>\n> I doubt yu can use the hardware support. Kernel-only hw support is\n> inherently broken for any sane user-space usage, the setup costs are just\n> way way too high. To be useful, crypto engines need to support direct user\n> space access (ie a regular instruction, with all state being held in\n> normal registers that get saved/restored by the kernel).\n>\n> > Is SHA a significant portion of the compute during these repacks?\n> > I should run oprofile...\n>\n> SHA1 is almost totally insignificant on x86. It hardly shows up. But we\n> have a good optimized version there.\n\nIf SHA1 is slow then why dont he contribute adding Haval160 (3 rounds)\nthat it's faster than SHA1? And to optimize still more it with SIMD instructions\nin kernelspace and userland.\n\n>\n> zlib tends to be a lot more noticeable (especially the uncompression: it\n> may be faster than compression, but it's done _so_ much more that it\n> totally dominates).\n>\n> \t\t\tLinus\n\nIt's better\n\n1. \"Don't compress this repo but compact this uncompressed repo\n using minimal spanning forest and deltas\"\n2. \"After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before\n burning it to DVD for backup reasons or before replicating it to\ninternet\".\n\n J.C.Pizarro \"the noiser\"\n"},{"id":"62411","messageId":"Pine.LNX.4.64.0712081223070.27959@racer.site","threadId":"11185","inReplyTo":"998d0e4a0712071821o520a75c4lbcaae92256071f48@mail.gmail.com","subject":"Re: Git and GCC","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-08T12:24:00Z","receivedAt":"2007-12-08T12:24:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 8 Dec 2007, J.C. Pizarro wrote:\n\n> On 2007/12/07, \"Linus Torvalds\" wrote:\n>\n> > SHA1 is almost totally insignificant on x86. It hardly shows up. But \n> > we have a good optimized version there.\n> \n> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds) \n> that it's faster than SHA1? And to optimize still more it with SIMD \n> instructions in kernelspace and userland.\n\nHe said SHA-1 is insignificant.\n\n> > zlib tends to be a lot more noticeable (especially the uncompression: \n> > it may be faster than compression, but it's done _so_ much more that \n> > it totally dominates).\n> \n> It's better\n> \n> 1. \"Don't compress this repo but compact this uncompressed repo\n> using minimal spanning forest and deltas\"\n> 2. \"After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before\n> burning it to DVD for backup reasons or before replicating it to\n>\tinternet\".\n\nPatches? ;-)\n\nCiao,\nDscho\n"},{"id":"62427","messageId":"20071208195352.GB4731@synopsys.com","threadId":"11185","inReplyTo":"Pine.LNX.4.64.0712081223070.27959@racer.site","subject":"Re: Git and GCC","fromName":"Joe Buck","fromEmail":"joe.buck@synopsys.com","sentAt":"2007-12-08T19:53:53Z","receivedAt":"2007-12-08T19:53:53Z","isPatch":false,"sender":{"key":"joe.buck@synopsys.com","avatar":null},"body":"On Sat, 8 Dec 2007, J.C. Pizarro wrote:\n> > 1. \"Don't compress this repo but compact this uncompressed repo\n> > using minimal spanning forest and deltas\"\n> > 2. \"After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before\n> > burning it to DVD for backup reasons or before replicating it to\n> >\tinternet\".\n\nOn Sat, Dec 08, 2007 at 12:24:00PM +0000, Johannes Schindelin wrote:\n> Patches? ;-)\n\ngit list, meet J.C. Pizarro. Care to take him off of our hands for\na while? He's been hanging on the gcc list for some time, and perhaps\nseeks new horizons.\n\nMr. Pizarro has endless ideas, and he'll give you some new ones every day.\nHe thinks that no one else knows any computer science, and he will attempt\nto teach you what he knows, and tell you to rewrite all of your code based\non something he read and half-understood. But he's not interested in\nactually DOING the work, mind you; that's up to you. When you object\nthat he's wasting your time, he'll start talking about freedom of speech.\n"},{"id":"62428","messageId":"e5bfff550712081228s6bcb064ep23f2bb06ef2c6b9b@mail.gmail.com","threadId":"11185","inReplyTo":"20071208195352.GB4731@synopsys.com","subject":"Re: Git and GCC","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-08T20:28:32Z","receivedAt":"2007-12-08T20:28:32Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 8, 2007 8:53 PM, Joe Buck wrote:\n>\n> Mr. Pizarro has endless ideas, and he'll give you some new ones every day.\n\nThat's true.\n\n> He thinks that no one else knows any computer science, and he will attempt\n> to teach you what he knows,\n\nIt's not the only one ;-) is in good and numerous company.\n\n> But he's not interested in\n> actually DOING the work, mind you; that's up to you.\n\nWhere did have you read this ? I missed that part.\n\n> When you object\n> that he's wasting your time, he'll start talking about freedom of speech.\n>\n\nActually he never spoke like that (probably I missed that part too).\n\n\nThanks\nMarco\n"},{"id":"62443","messageId":"4aca3dc20712081751v6c6a7c84w40d093bcac93a2bb@mail.gmail.com","threadId":"11185","inReplyTo":"e5bfff550712081228s6bcb064ep23f2bb06ef2c6b9b@mail.gmail.com","subject":"Re: Git and GCC","fromName":"Daniel Berlin","fromEmail":"dberlin@dberlin.org","sentAt":"2007-12-09T01:51:24Z","receivedAt":"2007-12-09T01:51:24Z","isPatch":false,"sender":{"key":"dberlin@dberlin.org","avatar":null},"body":">\n> Where did have you read this ? I missed that part.\n>\n> > When you object\n> > that he's wasting your time, he'll start talking about freedom of speech.\n> >\n>\n> Actually he never spoke like that (probably I missed that part too).\n>\n>\n\nRead gcc mailing list archives, if you have a lot of time on your hands.\n"},{"id":"63224","messageId":"877ijg6c9u.fsf@hades.wkstn.nix","threadId":"11185","inReplyTo":"Pine.LNX.4.64.0712081223070.27959@racer.site","subject":"Re: Git and GCC","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2007-12-15T00:18:37Z","receivedAt":"2007-12-15T00:18:37Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 8 Dec 2007, Johannes Schindelin said:\n\n> Hi,\n>\n> On Sat, 8 Dec 2007, J.C. Pizarro wrote:\n>\n>> On 2007/12/07, \"Linus Torvalds\" wrote:\n>>\n>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But \n>> > we have a good optimized version there.\n>> \n>> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds) \n>> that it's faster than SHA1? And to optimize still more it with SIMD \n>> instructions in kernelspace and userland.\n>\n> He said SHA-1 is insignificant.\n\nActually davem also said it *is* significant on SPARC. But of course\nJ. C. Pizarro's suggested solution won't work because you can't just go\naround replacing SHA-1 in git with something else :) you could *add* new\nhashing methods, but you couldn't avoid SHA-1, and adding a new hashing\nmethod would bloat every object and every hash in objects like commits\nwith an indication of which hashing method was in use.\n\n(But you know this.)\n\n>> 1. \"Don't compress this repo but compact this uncompressed repo\n>> using minimal spanning forest and deltas\"\n\n... and then you do a git-gc. Oops, now what?\n\n... or perhaps you want to look something up in the pack. Now you have to\nunpack a large hunk of the whole damn thing.\n\n>> 2. \"After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before\n>> burning it to DVD for backup reasons or before replicating it to\n>>\tinternet\".\n>\n> Patches? ;-)\n\nReplicating a pack to the internet is almost invariably replicating\n*parts* of a pack anyway, which reduces to the problem with option 1\nabove...\n\n-- \n`The rest is a tale of post and counter-post.' --- Ian Rawlings\n describes USENET\n"}]}