Kaveh R. Ghazi schrieb:
> I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs)
If you can demonstrate that say GCC-4.0 uses much more memory than 3.4
or 3.3 to compile some code, then file a PR with preprocessed source
and someone will eventually look at it.
I haven't thought about a regres
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Apr 02, 2005 at 01:10:42AM -0500, Andrew Pinski wrote:
| > >Memory bloat is a problem for embedded systems. Attitudes about just
| > >"buy
| > >another gigabyte" is why i use C for everything for speed, portability,
| > >compactness, and conciseness
> > childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long)
> > p->thread_info)) - 1;
> > *childregs = *regs;
> > ^^^
> > childregs->eax = 0;
> > childregs->esp = esp;
> >
> > # make arch/i386/kernel/process.s
> >
> > copy_thread:
>
On Saturday 02 April 2005 15:18, Denis Vlasenko wrote:
> -O2 compile does inline copying, however, suboptimally.
> Pushing/popping esi/edi on the stack is not needed.
> Also "mov $1,ecx; rep; movsl" is rather silly.
I think I am wrong about push/pop. Sorry.
However, other observation is still val
>> if gcc uses more memory than physically available it spends a
>> _very_ long time swapping
>
> Swapping, what's that? Here's $20, go buy a gigabyte.
You don't know whay swapping is? Shifting memory over from physical RAM
to the hard drive when not in use, and putting it back in RAM when in
>> if gcc uses more memory than physically available it spends a
>> _very_ long time swapping
>
> Swapping, what's that? Here's $20, go buy a gigabyte.
You don't know whay swapping is? Shifting memory over from physical RAM
to the hard drive when not in use, and putting it back in RAM when in
>> if gcc uses more memory than physically available it spends a
>> _very_ long time swapping
>
> Swapping, what's that? Here's $20, go buy a gigabyte.
You don't know whay swapping is? Shifting memory over from physical RAM
to the hard drive when not in use, and putting it back in RAM when in
> mem peak user sys
>
>
> gcc 3.4 -S -O0 476 MB1m39s 2s
> gcc 4.0 -S -O0 655 MB2m23s 3s
>
> icc -S -O0 264 MB 1m24s 15s
>
>
> the file makes quite heavy use of virtual inheritance so there are a
> lot of virtual tables involved. are there any known performance bugs
On 04/01/2005 11:23 AM, Daniel Jacobowitz wrote:
[snip]
There are other ways to solve this problem, including creating a
generational collector using our existing accurate GC. I've been
working on this on-and-off (mostly off at the moment, though).
I briefly looked at:
Type-Information.html
from
On Sat, Apr 02, 2005 at 10:40:35AM -0600, Larry Evans wrote:
> I briefly looked at:
>
> Type-Information.html
>
> from:
>
> http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz
>
> I was wondering why the method described here:
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_ty
Mike Stump wrote:
> Swapping, what's that? Here's $20, go buy a gigabyte.
I hope that was not meant to be taken literally, or perhaps memory
really is that cheap where you live.
Apple charge me 19x-33x that amount, depending on model. Plus shipping.
On topic: Even if memory were cheap (which it
Hi,
I am trying to compile MEDIABENCH (@UCLA) using the latest GCC CVS
checkout. I get
the following errors when I compile with "-O3 -fprofile-generate". I just
want to make sure
that this is not a silly mistake before I file a bug report. Can someone
help? Almost 9 out of 11
benchmarks throw
On Saturday 02 April 2005 20:22, Rajkishore Barik wrote:
> Hi,
> I am trying to compile MEDIABENCH (@UCLA) using the latest GCC CVS
> checkout. I get
> the following errors when I compile with "-O3 -fprofile-generate". I just
> want to make sure
> that this is not a silly mistake before I file a b
On Fri, 1 Apr 2005, Joe Buck wrote:
> Unfortunately, where there is a good argument for not using empty loops
> as busy-waits, at one time it was documented GCC behavior that it would
> work, so we can't really blame the users for trusting the doc.
However, it's really a looong time since we clari
On Sat, Apr 02, 2005 at 08:29:48PM +0200, Gerald Pfeifer wrote:
> On Fri, 1 Apr 2005, Joe Buck wrote:
> > Unfortunately, where there is a good argument for not using empty loops
> > as busy-waits, at one time it was documented GCC behavior that it would
> > work, so we can't really blame the users
Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a
switch in gcc-4.0?
Cheers,
Shaun
On Mar 22, 2005 12:29 PM, Andreas Jochens <[EMAIL PROTECTED]> wrote:
> Package: romeo
> Severity: normal
> Tags: patch
>
> When building 'romeo' on amd64 with gcc-4.0,
> I get the following erro
On Apr 2, 2005, at 4:53 PM, Shaun Jackman wrote:
Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a
switch in gcc-4.0?
No.
Cheers,
Shaun
On Mar 22, 2005 12:29 PM, Andreas Jochens <[EMAIL PROTECTED]> wrote:
Package: romeo
Severity: normal
Tags: patch
When building 'romeo' on amd64
On Apr 2, 2005, at 4:57 PM, Andrew Pinski wrote:
On Apr 2, 2005, at 4:53 PM, Shaun Jackman wrote:
Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a
switch in gcc-4.0?
No.
Note a better fix for the bug would be:
#definememUHeapSize(p,ver) \
*(ver>2 ? &
Shaun Jackman <[EMAIL PROTECTED]> writes:
| Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a
| switch in gcc-4.0?
It is gone forever.
-- Gaby
Kaveh R. Ghazi schrieb:
I'm curious what the 3.3 numbers are,
3.3 => 4.0 is a small improvement cpu-wise(not mem-wise).
3.4 is much better than both:
gcc-Version 3.3.5 (Debian 1:3.3.5-8)
mem 426 mb
user2m10.870s
sys 0m2.250s
gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
mem
On Apr 2, 2005, at 6:12 PM, Stefan Strasser wrote:
gcc-Version 4.0.0 20041218 (experimental)
this 4.0.0 is almost 4 months old.
That is not a far comparison as there was speedups after that
and other bug fixes.
-- Pinski
On Sat, Apr 02, 2005 at 06:10:29PM -0500, Andrew Pinski wrote:
>
> On Apr 2, 2005, at 6:12 PM, Stefan Strasser wrote:
>
> >gcc-Version 4.0.0 20041218 (experimental)
> >
>
> this 4.0.0 is almost 4 months old.
> That is not a far comparison as there was speedups after that
> and other bug fixes.
Snapshot gcc-4.0-20050402 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050402/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050402
You'll
tests:
gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
user0m57.250s
sys 0m1.050s
gcc-Version 4.0.0 20041218 (experimental)
user1m53.810s
sys 0m2.850s
gcc-Version 4.0.0 20050402 (prerelease)
user0m40.290s
sys 0m1.070s
impressing. thank you very much to whoever fixed
24 matches
Mail list logo
