The Regents of the University of California BSD-license in GPLed GCC.
In GPLed GCC-4.1 branch appears a notice of BSD license gcc/config/i386/gmon-sol2.c * Copyright (c) 1991 The Regents of the University of California. * All rights reserved. ... J.C.Pizarro sincerely ;)
Re: Git and GCC
Hi, On Fri, 7 Dec 2007, Daniel Berlin wrote: > On 12/7/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote: > > > > > > >> 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. 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). > > > > > > > > Have you considered alternatives, like: > > > > http://www.oberhumer.com/opensource/ucl/ > > > > > > > > > As compared to LZO, the UCL algorithms achieve a better > > > compression ratio but *decompression* is a little bit slower. See > > > below for some rough timings. > > > > > > > > > It is uncompression speed that is more important, because it is used > > > much more often. > > > > I know, but the point is not what is the fastestest, but if it's fast > > enough to get off the profiles. I think UCL is fast enough since it's > > still times faster than zlib. Anyway, LZO is GPL too, so why not > > considering it too. They are good libraries. > > > At worst, you could also use fastlz (www.fastlz.org), which is faster > than all of these by a factor of 4 (and compression wise, is actually > sometimes better, sometimes worse, than LZO). fastLZ is awfully short on details when it comes to a comparison of the resulting file sizes. The only result I saw was that for the (single) example they chose, compressed size was 470MB as opposed to 361MB for zip's _fastest_ mode. Really, that's not acceptable for me in the context of git. Besides, if you change the compression algorithm you will have to add support for legacy clients to _recompress_ with libz. Which most likely would make Sisyphos grin watching them servers. Ciao, Dscho
Re: Git and GCC
Hi, On Sat, 8 Dec 2007, J.C. Pizarro wrote: > On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> 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. > > 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
VLIW scheduling and delayed branch
Hi, I am trying to enable delayed branch scheduling on our port of Gcc for picochip (16-bit VLIW DSP). I understand that delayed-branch is run as a seperate pass after the DFA scheduling is done. We basically depend on the TImode set on the cycle-start instructions to decide what instructions form a valid VLIW. By enabling delayed-branch, it seems like the delay-branch pass takes any instruction and puts it on the delay slot. This sometimes seem to pick the TImode set instructions, but does not seem to set the TImode on the next instruction. Has anyone faced a similar problem before? Are there targets for which both VLIW and DBR are enabled? Perhaps ia64? Thanks for your help. Regards Hari
Re: The Regents of the University of California BSD-license in GPLed GCC.
J.C. Pizarro wrote: In GPLed GCC-4.1 branch appears a notice of BSD license gcc/config/i386/gmon-sol2.c * Copyright (c) 1991 The Regents of the University of California. * All rights reserved. No doubt. And in the mean time I'm listening to: Title: Bach: Prelude and Fugue in C, BWV 531 Artist: Darren L. Slider Genre: Classical Someone who performs the above Bach prelude and fugue on a house organ. Good enough for those who appreciate Bach, whatever, and not good enough for those who prefer a church organ. If you need a church organ, turn to the Regents of the Church of California. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: Git and GCC
On Sat, 8 Dec 2007, J.C. Pizarro wrote: > > 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 +, 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.
Re: The Regents of the University of California BSD-license in GPLed GCC.
On Sat, Dec 08, 2007 at 12:31:43PM +0100, J.C. Pizarro wrote: > In GPLed GCC-4.1 branch appears a notice of BSD license > gcc/config/i386/gmon-sol2.c > > * Copyright (c) 1991 The Regents of the University of California. > * All rights reserved. And why are you sending this to both gcc and gcc-help? This is known, it is not news, and it is not a problem.
Re: Git and GCC
On Dec 8, 2007 8:53 PM, Joe Buck <[EMAIL PROTECTED]> 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
Re: VLIW scheduling and delayed branch
> Has anyone faced a similar problem before? Are there targets for which > both VLIW and DBR are enabled? Perhaps ia64? I did something similar a few months ago. The problem is that haifa and the delayed branch scheduling passes don't really fit together. delayed branch scheduling happily undoes all the haifa decisions. The question is how much you gain by delayed branch scheduling. I don't have numbers, but it wasn't much in my case. And since your company name is picochip, you certainly value size more than speed ?! I pursued two approaches. The first one was to insert "stop bit" pseudo insns into the RTL stream in machdep reorg, so I didn't have to rely on TImode insn flags during output. But then delayed branch scheduling just took one insn out of an insn group and put it into the delay slot, meaning there was usually no cycle gain at all, just larger code size (due to insn duplication). The second approach was having lots of parallel insns (using match parallel and a custom predicate). machdep reorg then converts insn bundles into a single parallel insn. Delayed branch scheduling then does the right thing. This approach works fairly well for me, but there are a few complications. My output code is pretty hackish, as I didn't want to duplicate outputing a single insn / outputing the same insn as component of a parallel insn group. Tom
Re: gnat1 huge time
Having observed the bug while building a native, SJLJ version of libgnat on x86_64, I have filed PR ada/34400 for this. -- Ludovic Brenta.
Re: Git and GCC
> > 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.
Re: [RFC/RFT] Improving SMS by data dependence export
Hi Alexander, > We would like to ask people interested in SMS performance on PowerPC and > Cell SPU to conduct tests with this patch. Any feedback is greatly > appreciated. I intend to perform testing with this patch (on ppc and SPU), after resolving the miscompilation issues mentioned above. Thanks, Revital
