Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> On 24 Mar 2001, Kevin Buhr wrote:
> >
> > A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
> > though it obviously had a 10-fold effect on maps counts. On the
> > positive side, there was no performance *hit* either.
>
> I don
Jakob Østergaard wrote:
> But the bad case was a garbage collector in GCC. The mmap tricks seem like
> some you may be inclined to actually use in something like garbage collectors.
> Are we sure that the developers of all other garbage collectors out there
> foresaw this problem and didn't do mm
On 24 Mar 2001, Kevin Buhr wrote:
>
> A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
> though it obviously had a 10-fold effect on maps counts. On the
> positive side, there was no performance *hit* either.
I don't think the system time in 3.0 has anything to do the the
On Sat, Mar 24, 2001 at 01:54:39PM -0600, Kevin Buhr wrote:
> Jakob Østergaard <[EMAIL PROTECTED]> writes:
> >
> > It's important that you use at least -O3 to get inlining too.
> [ . . . ]
> > 25 MB doesn't count ;)
>
> Aggh! I feel like I'm in a comedy sketch. You tell me "do that".
> I do
Jakob Østergaard <[EMAIL PROTECTED]> writes:
>
> It's important that you use at least -O3 to get inlining too.
[ . . . ]
> 25 MB doesn't count ;)
Aggh! I feel like I'm in a comedy sketch. You tell me "do that".
I do that. You tell me, "you should try this instead", so I do this.
Then, you
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
>
> Let me inject some information about what gcc's doing in each version.
Thanks... very useful information.
> 2.95.3 allocates its memory via a bunch of 'obstacks' which,
> underneath, get memory from malloc, and therefore brk(2). I'm very
> surpr
Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
[ under kernel 2.4.2 ]
> >
> >CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
> >
> >real16m8.423s real8m2.417s real12m24.939s
> >user15m23.710suser7m22.200suser10m1
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> Times are fine. Local APIC timer interrupts are used.
Okay, thanks. That's good.
> Testing's easy, thanks for the fix.
This is where I'd submit the patch, but Alan evidently works 80 hours
a day. ;) The new patch is already in ac24.
Alan, FYI
On Fri, Mar 23, 2001 at 09:02:30PM -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Kevin Buhr <[EMAIL PROTECTED]> wrote:
> >
> >The results speak for themselves:
> >
> >CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
> >
> >real16m8.42
In article <[EMAIL PROTECTED]>,
Kevin Buhr <[EMAIL PROTECTED]> wrote:
>
>The results speak for themselves:
>
>CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
>
>real16m8.423s real8m2.417s real12m24.939s
>user15m23.710suser
Kevin Buhr wrote:
> Jakob Østergaard <[EMAIL PROTECTED]> writes:
> >
> > Try compiling something like Qt/KDE/gtk-- which are really heavy on
> > templates (with all the benefits and drawbacks of that).
>
> Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three
> versions of GCC (D
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> > Mike, would you like to try out the following (untested) patch against
> > vanilla ac20 to see if it does the trick?
>
> Yes, that fixed it.
Great! Can you test one more configuration, please? I can't test it
properly with my SMP motherboard.
On Thu, Mar 22, 2001 at 07:35:49PM +0100, Jakob Østergaard wrote:
> My code here is quite template heavy, and I suspect that's what's triggering
> it. In fact, I can't compile our development code with optimization, because
> GCC runs out of memory (it only allocates some 300-500 MB, but each pa
On 22 Mar 2001, Kevin Buhr wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
> >
> > 2.4.2.ac20.virgin 2.4.3-pre6
> > real11m0.708s 11m58.617s
> > user15m8.720s 7m29.970s
> > sys 1m31.410s 0m41.590s
> >
> > It looks like ac20 is doing some double accounting.
[snip]
> Mike,
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> 2.4.2.ac20.virgin 2.4.3-pre6
> real11m0.708s 11m58.617s
> user15m8.720s 7m29.970s
> sys 1m31.410s 0m41.590s
>
> It looks like ac20 is doing some double accounting.
Alan:
In "2.4.2-ac20", the check in "apic.c" in the "APIC_init_
On Thu, Mar 22, 2001 at 12:23:15PM -0600, Kevin Buhr wrote:
> [EMAIL PROTECTED] (Kevin Buhr) writes:
...
> I pulled the "gcc-3_0-branch" of GCC from CVS and compiled Mozilla
> under a 2.4.2 kernel. The numbers I saw were:
>
> real57m26.850s
> user96m57.490s
> sys 3m16.780
On 21 Mar 2001, Kevin Buhr wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
> >
> > Yes. I'm so used to UP numbers I didn't think. I saw user larger than
> > real on my UP box yesterday during some testing, and then seeing this
> > post... oops.
>
> Okay, so you see "user > real" on a UP box
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> Yes. I'm so used to UP numbers I didn't think. I saw user larger than
> real on my UP box yesterday during some testing, and then seeing this
> post... oops.
Okay, so you see "user > real" on a UP box running an SMP kernel.
First, I'm not really
On Wed, 21 Mar 2001, Kurt Garloff wrote:
> On Wed, Mar 21, 2001 at 07:41:55AM +0100, Mike Galbraith wrote:
> > On 20 Mar 2001, Kevin Buhr wrote:
> > > real60m4.574s
> > > user101m18.260s <-- impossible no?
> > > sys 3m23.520s
> >
> > Why do numbers like this show up? I n
On Wed, Mar 21, 2001 at 07:41:55AM +0100, Mike Galbraith wrote:
> On 20 Mar 2001, Kevin Buhr wrote:
> > real60m4.574s
> > user101m18.260s <-- impossible no?
> > sys 3m23.520s
>
> Why do numbers like this show up? I noticed some of this after having
> enabled SMP on my UP
> > I frequently build Mozilla from scratch on my (aging) dual Celeron
> > machine. [...]
> > real60m4.574s
> > user101m18.260s <-- impossible no?
> > sys 3m23.520s
>
> Why do numbers like this show up? I noticed some of this after having
> enabled SMP on my UP box.
>
On Wed, 21 Mar 2001, Matthias Urlichs wrote:
> > > I frequently build Mozilla from scratch on my (aging) dual Celeron
> > > machine. [...]
> > > real60m4.574s
> > > user101m18.260s <-- impossible no?
> > > sys 3m23.520s
> >
> > Why do numbers like this show up? I notice
On 20 Mar 2001, Kevin Buhr wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > Cool. Somebody actually found a real case.
> >
> > I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> > ever actually triggers. Something like g++ certainly counts as major.
>
> I frequent
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> Cool. Somebody actually found a real case.
>
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.
I do daily builds of the VTK CVS tree (The Visualization T
Kevin Buhr writes:
> If I recall correctly, RedHat's 2.96 was a modified development
> snapshot of GCC 3.0, not an official GCC release. If this is just a
> quirk in 2.96 that can be fixed before the official release of 3.0 by
> a trivial patch to libiberty, maybe your original hunch was rig
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> Cool. Somebody actually found a real case.
>
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.
I frequently build Mozilla from scratch on my (aging) dual
On Tue, Mar 20, 2001 at 10:43:33AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 20 Mar 2001, Serge Orlov wrote:
> >
> > I upgraded one of our computer happily running 2.2.13 kernel
> > to 2.4.2. Everything was OK, but compilation time of our C++
> > project greatly increased (1.4 times slower). I
On Tue, 20 Mar 2001, Serge Orlov wrote:
>
> I upgraded one of our computer happily running 2.2.13 kernel
> to 2.4.2. Everything was OK, but compilation time of our C++
> project greatly increased (1.4 times slower). I investigated the
> issue and found that g++ spends 7 times more time in kernel
On Tue, Mar 20, 2001 at 09:28:57PM +0300, Serge Orlov wrote:
> Hi,
> I upgraded one of our computer happily running 2.2.13 kernel
> to 2.4.2. Everything was OK, but compilation time of our C++
> project greatly increased (1.4 times slower). I investigated the
> issue and found that g++ spends 7 t
Hi,
I upgraded one of our computer happily running 2.2.13 kernel
to 2.4.2. Everything was OK, but compilation time of our C++
project greatly increased (1.4 times slower). I investigated the
issue and found that g++ spends 7 times more time in kernel.
The reason for this is big vm map:
cat /proc
30 matches
Mail list logo
