Hi,
The autotools ( automake + libtool + autoconf + ... ) generate many
big
files that they have been slowing the building's computation and
growing
enormously their cvs/svn/git/hg repositories because of generated
files.
To see below interesting links:
1. http://dot.kde.org/1172083974/
2
On Thu, Dec 06, 2007 at 10:35:22AM -0800, Linus Torvalds wrote:
> > What is really disappointing is that we saved only about 20% of the
> > time. I didn't sit around watching the stages, but my guess is that we
> > spent a long time in the single threaded "writing objects" stage with a
> > thra
On Fri, Dec 07, 2007 at 01:50:47AM -0500, Jeff King wrote:
> Yes, but balanced by one thread running out of data way earlier than the
> other, and completing the task with only one CPU. I am doing a 4-thread
> test on a quad-CPU right now, and I will also try it with threads=1 and
> threads=6 for
On 12/7/07, Jeff King <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
>
> > > So it is about 5% bigger. What is really disappointing is that we saved
> > > only about 20% of the time. I didn't sit around watching the stages, but
> > > my guess is that we s
On 12/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Jon Smirl wrote:
> > >
> > > time git blame -C gcc/regclass.c > /dev/null
> >
> > [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
> >
> > real1m21.967s
> > user1m21.329s
>
> We
On Thu, Dec 06, 2007 at 01:02:58PM -0500, Nicolas Pitre wrote:
> > What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objects" stage with a thrashin
On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> > So it is about 5% bigger. What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objec
Hello,
I think you should look at the constraint of the instruction in your md
file, for example (taken from altivec.md file under config/rs6000 dir):
(define_insn "altivec_stvx"
[(parallel
[(set (match_operand:V4SI 0 "memory_operand" "=Z")
(match_operand:V4SI 1 "register_operand"
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, NightStrike wrote:
> >
> > No disrespect is meant by this reply. I am just curious (and I am
> > probably misunderstanding something).. Why remove all of the
> > documentation entirely? Wouldn't it be better to just
On Thu, 6 Dec 2007, Jon Smirl wrote:
> >
> > time git blame -C gcc/regclass.c > /dev/null
>
> [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
>
> real1m21.967s
> user1m21.329s
Well, I was also hoping for a "compared to not-so-aggressive packing"
numb
On Thu, 6 Dec 2007, Jon Smirl wrote:
> I have a 4.8GB git process with 4GB of physical memory. Everything
> started slowing down a lot when the process got that big. Does git
> really need 4.8GB to repack? I could only keep 3.4GB resident. Luckily
> this happen at 95% completion. With 8GB of memor
From: Jeff King <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 12:39:47 -0500
> I tried the threaded repack with pack.threads = 3 on a dual-processor
> machine, and got:
>
> time git repack -a -d -f --window=250 --depth=250
>
> real309m59.849s
> user377m43.948s
> sys 8m23.319s
>
On Thu, 2007-12-06 at 13:04 -0500, Daniel Berlin wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > So the equivalent of "git gc --aggressive" - but done *properly* - is to
> > do (overnight) something like
> >
> > git repack -a -d --depth=250 --window=250
> >
> I gave th
The autotools ( automake + libtool + autoconf + ... ) generate many big
files that they have been slowing the building's computation and growing
enormously their cvs/svn/git/hg repositories because of generated files.
To see below interesting links:
1. http://dot.kde.org/1172083974/
2. http://sam.
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 6 Dec 2007, Jon Loeliger wrote:
>> I guess one question I posit is, would it be more accurate
>> to think of this as a "delta net" in a weighted graph rather
>> than a "delta chain"?
>
> It's certainly not a simple chain, it's more of a set of
Hello Everyone,
I am trying to modify the OpenRISC GCC to modify the existing
instructions and add more instructions into the system. I had to rewrite
most of the or32.md. When I am trying to compile something, it says the
following constaint is not found. Can someone please help me with
readin
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > Well, that's possible with a window 25 times larger than the default.
> >
> > Why did it never use more than three cores?
>
> You have 648366 objects total, and only 647457 of them are subject to
> delta compression.
>
> With a window size
On Thu, 06 Dec 2007 23:26:07 +0100 David Kastrup wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> > Junio C Hamano <[EMAIL PROTECTED]> writes:
> >
> >> Jon Loeliger <[EMAIL PROTECTED]> writes:
> >>
> >>> I'd like to learn more about that. Can someone point me to
> >>> either more document
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > On Thu, 6 Dec 2007, Jon Smirl wrote:
> >
> > > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > > the work. I w
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
>> Jon Loeliger <[EMAIL PROTECTED]> writes:
>>
>>> I'd like to learn more about that. Can someone point me to
>>> either more documentation on it? In the absence of that,
>>> perhaps a pointer to the source
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I was using a four core machine and most of the time
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I was using a four core machine and most of the time
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > When I lasted looked at the code, the problem was in evenly dividing
> > > the work. I was using a four core machine and most of the time one
> > > core would end up with 3-5x the work of the lightest
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > When I lasted looked at the code, the problem was in evenly dividing
> > the work. I was using a four core machine and most of the time one
> > core would end up with 3-5x the work of the lightest loaded core.
> > Setting pack.threads up to 2
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Jon Loeliger <[EMAIL PROTECTED]> writes:
>
>> I'd like to learn more about that. Can someone point me to
>> either more documentation on it? In the absence of that,
>> perhaps a pointer to the source code that implements it?
>
> See Documentation/tech
On 12/6/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
> Vincent Lefevre wrote:
> > It's surprising that you don't mention svk, which is based on top
> > of Subversion[*]. Has anyone tried? Is there any problem with it?
> I must agree with Ismail's reply here. We have used svk for our
> interna
On 2007/12/6, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> For multicores CPUs, don't divide the work in threads.
> To divide the work in processes!
>
> Tips, tricks and hacks: to use fork, exec, pipes and another IPC mechanisms
> like
> mutexes, shared memory's IPC, file locks, pipes, semaphores,
Vincent Lefevre wrote:
It's surprising that you don't mention svk, which is based on top
of Subversion[*]. Has anyone tried? Is there any problem with it?
I must agree with Ismail's reply here. We have used svk for our
internal development for about two years, for the reason of easy
mirroring
Jon Loeliger <[EMAIL PROTECTED]> writes:
> On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
>
>> Git also does delta-chains, but it does them a lot more "loosely". There
>> is no fixed entity. Delta's are generated against any random other version
>> that git deems to be a good delta candidate
On Thu, 6 Dec 2007, Jon Loeliger wrote:
>
> On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
> > Git also does delta-chains, but it does them a lot more "loosely". There
> > is no fixed entity. Delta's are generated against any random other version
> > that git deems to be a good delta candid
Thursday 06 December 2007 21:28:59 Vincent Lefevre yazmıştı:
> On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote:
> > Distributed version systems like git or Mercurial have some advantages
> > over Subversion.
>
> It's surprising that you don't mention svk, which is based on top
> of Subversion[
On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote:
> Distributed version systems like git or Mercurial have some advantages
> over Subversion.
It's surprising that you don't mention svk, which is based on top
of Subversion[*]. Has anyone tried? Is there any problem with it?
[*] You have curren
On 2007/12/06, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Thu, 6 Dec 2007, Jeff King wrote:
> > >
> > > What is really disappointing is that we saved only about 20% of the
> > > time. I didn't sit around watching the stages, but my guess is
On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
> Git also does delta-chains, but it does them a lot more "loosely". There
> is no fixed entity. Delta's are generated against any random other version
> that git deems to be a good delta candidate (with various fairly
> successful heursitics),
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Thu, 6 Dec 2007, Jeff King wrote:
> > >
> > > What is really disappointing is that we saved only about 20% of the
> > > time. I didn't sit around watching the stages, but my guess is that we
On 2007/12/06, David Kastrup <[EMAIL PROTECTED]> wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> writes:
>
> > However, I think that --aggressive should be aggressive, and if you
> > decide to run it on a machine which lacks the muscle to be aggressive,
> > well, you should have known better.
>
>
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Jeff King wrote:
> >
> > What is really disappointing is that we saved only about 20% of the
> > time. I didn't sit around watching the stages, but my guess is that we
> > spent a long time in the single threaded "writi
On Thu, 6 Dec 2007, NightStrike wrote:
>
> No disrespect is meant by this reply. I am just curious (and I am
> probably misunderstanding something).. Why remove all of the
> documentation entirely? Wouldn't it be better to just document it
> more thoroughly?
Well, part of it is that I don't
On Thu, 6 Dec 2007, Jeff King wrote:
>
> What is really disappointing is that we saved only about 20% of the
> time. I didn't sit around watching the stages, but my guess is that we
> spent a long time in the single threaded "writing objects" stage with a
> thrashing delta cache.
I don't thi
On Thu, 6 Dec 2007, Daniel Berlin wrote:
>
> I worked on Monotone and other systems that use object stores. for a
> little while :) In particular, I believe GIT's original object store was
> based on Monotone, IIRC.
Yes and no.
Monotone does what git does for the blobs. But there is a big di
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb thing
> > to pack files sometimes regardless of whether you converted from an
> > SVN repo or not.
> I'll send a patch to Junio
NightStrike <[EMAIL PROTECTED]> writes:
> On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > As I said, maybe i'll look at git in another year or so.
> > But i'm certainly going to ignore all the "git is so great, we should
> > move gcc to it" people until it works better, while i am much m
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb thing
> > to pack files sometimes regardless of whether you converted from an
> > SVN repo or not.
>
> Absolutely. git --aggres
On Thu, 6 Dec 2007, Jeff King wrote:
> On Thu, Dec 06, 2007 at 09:18:39AM -0500, Nicolas Pitre wrote:
>
> > > The downside is that the threading partitions the object space, so the
> > > resulting size is not necessarily as small (but I don't know that
> > > anybody has done testing on large repo
On Thu, Dec 06, 2007 at 09:18:39AM -0500, Nicolas Pitre wrote:
> > The downside is that the threading partitions the object space, so the
> > resulting size is not necessarily as small (but I don't know that
> > anybody has done testing on large repos to find out how large the
> > difference is).
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> However, I think that --aggressive should be aggressive, and if you
> decide to run it on a machine which lacks the muscle to be aggressive,
> well, you should have known better.
That's a rather cheap shot. "you should have known better" than
exp
On Thu, 6 Dec 2007, Harvey Harrison wrote:
>
> 7:41:25elapsed 86%CPU
Heh. And this is why you want to do it exactly *once*, and then just
export the end result for others ;)
> -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26
> pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack
Bu
Hi,
On Thu, 6 Dec 2007, Harvey Harrison wrote:
> -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26
> pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack
Wow.
Ciao,
Dscho
Hi,
On Thu, 6 Dec 2007, Pierre Habouzit wrote:
> On Thu, Dec 06, 2007 at 12:03:38PM +, Johannes Schindelin wrote:
> >
> > The default was not to change the window or depth at all. As
> > suggested by Jon Smirl, Linus Torvalds and others, default to
> >
> > --window=250 --depth=250
>
Wow
/usr/bin/time git repack -a -d -f --window=250 --depth=250
23266.37user 581.04system 7:41:25elapsed 86%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (419835major+123275804minor)pagefaults 0swaps
-r--r--r-- 1 hharrison hharrison 29091872 2007-12-06 07:26
pack-1d46ca030c3d6d6b95ad31
On Thu, Dec 06, 2007 at 12:03:38PM +, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
well, this will explode on many quite reasonnably sized syst
On Thu, 6 Dec 2007, Jeff King wrote:
> On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
>
> > The key to converting repositories of this size is RAM. 4GB minimum,
> > more would be better. git-repack is not multi-threaded. There were a
> > few attempts at making it multi-threaded but no
On Thu, 6 Dec 2007, Theodore Tso wrote:
> Linus later pointed out that what we *really* should do is at some
> point was to change repack -f to potentially retry to find a better
> delta, but to reuse the existing delta if it was no worse. That
> automatically does the right thing in the case whe
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> > git repack -a -d --depth=250 --window=250
> >
>
> Since I have the whole gcc repo locally I'll give this a shot overnight
> just to see what can be done at the extreme end or things.
Don't forget to add -f as well.
Nicolas
On Thu, Dec 06, 2007 at 12:03:38PM +, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
I'd also suggest adding a comment in the man pages that this s
Zdenek Dvorak wrote:
Hello,
during a recent discussion, it was pointed to my attention that
update_stmt is performance critical. I wondered why; this is the number
of update_stmt calls for combine.i (all the other passes have less then
1000 calls):
<...>
I have a patch that decrease
On Thu, 2007-12-06 at 10:52 +0100, Andreas Schwab wrote:
> Harvey Harrison <[EMAIL PROTECTED]> writes:
>
> > git svn does accept a mailmap at import time with the same format as the
> > cvs importer I think. But for someone that just wants a repo to check
> > out this was easiest. I'd be willin
The default was not to change the window or depth at all. As suggested
by Jon Smirl, Linus Torvalds and others, default to
--window=250 --depth=250
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
On Wed, 5 Dec 2007, Linus Torvalds wrote:
> On Thu, 6 Dec 2007
Thursday 06 December 2007 13:57:06 Johannes Schindelin yazmıştı:
[...]
> So I fully expect an issue like Daniel's to be resolved in a matter of
> minutes on the git list, if the OP gives us a chance. If we are not even
> Cc'ed, you are completely right, she or he probably does not want the
> issue
Hi,
On Wed, 5 Dec 2007, David Miller wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> >
> > I am quite fine with a distributed workflow, I now use 8
Hello,
I am wondering how to define a blackbox data type in gcc. It can be too
wide and irregular to be represented by current data types. It needs to
be assigned to special register files. I don't care and don't want to
touch its content except using intrinsics (builtin) functions. An
example o
Daniel Berlin wrote:
> Patch manager will be dying for a week or two while i change hosting.
> of course, if nobody is still using it, i can just kill it permanently.
At least I use it almost always to make sure patches does not get
forgotten; thus I regularly check http://dberlin.org/patches/pat
Ben Elliston <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-05 at 18:35 -0500, Daniel Berlin wrote:
>
>> svn propedit --revision svn:log
>
> OK, well, it used to be a bit trickier in CVS .. :-)
In CVS it's just a cvs admin -m as well.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
Su
Harvey Harrison <[EMAIL PROTECTED]> writes:
> git svn does accept a mailmap at import time with the same format as the
> cvs importer I think. But for someone that just wants a repo to check
> out this was easiest. I'd be willing to spend the time to do a nicer
> job if there was any interest fr
Hi,
We are retargetting GCC to a VLIW chip, which runs as a coprocessor to a
general purpose processor. The coprocessor is responsible for
expediating some code sections which have good parallel characteristics
without any dependences. Its ISA enables it can only fetch data
sequentially rather than
On Wed, Dec 05, 2007 at 11:49:21PM -0800, Harvey Harrison wrote:
git repack -a -d --depth=250 --window=250
Since I have the whole gcc repo locally I'll give this a shot overnight
just to see what can be done at the extreme end or things.
When I tried this on a very large repo, at l
66 matches
Mail list logo
