I know that Bohem's GC is used in the Java runtime for GCC. However, the
compiler proper itself can _really_ cramp people's avalible RAM (for those who
don't belive me and have Windows w/ DJGPP, change all the memory controls
from `auto' to the highest value and just try to compile libiberty/re
Sam Lauber writes:
> I know that Bohem's GC is used in the Java runtime for GCC.
> However, the compiler proper itself can _really_ cramp people's
> avalible RAM (for those who don't belive me and have Windows w/
> DJGPP, change all the memory controls from `auto' to the highest
> value and ju
On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
> Sam Lauber writes:
> > I know that Bohem's GC is used in the Java runtime for GCC.
> > However, the compiler proper itself can _really_ cramp people's
> > avalible RAM (for those who don't belive me and have Windows w/
> > DJGPP, change a
Daniel Berlin writes:
> On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
> > Sam Lauber writes:
> > > I know that Bohem's GC is used in the Java runtime for GCC.
> > > However, the compiler proper itself can _really_ cramp people's
> > > avalible RAM (for those who don't belive me and
Perhaps then a scheme in which the compiler
1) compresses all tree structures (this would be a good project)
2) after each pass, all internal structures are freed unless doing so would
create a dead pointer (maybe an -Om option like -Os but saves compilation
memory?)
3) dosen't use memory in
On 04/01/2005 07:35 AM, Andrew Haley wrote:
[snip]
To be fair to the Boehm gc, though: it isn't inherently a conservative
collector, but will also do precise gc.
Wouldn't this require a GC_descr as defined here:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt
for each data st
On 04/01/2005 08:21 AM, Larry Evans wrote:
On 04/01/2005 07:35 AM, Andrew Haley wrote:
[snip]
To be fair to the Boehm gc, though: it isn't inherently a conservative
collector, but will also do precise gc.
Wouldn't this require a GC_descr as defined here:
http://www.hpl.hp.com/personal/Hans_Boehm
Andrew Haley schrieb:
Sam Lauber writes:
> I know that Bohem's GC is used in the Java runtime for GCC.
> However, the compiler proper itself can _really_ cramp people's
> avalible RAM (for those who don't belive me and have Windows w/
> DJGPP, change all the memory controls from `auto' to the h
On Fri, Apr 01, 2005 at 06:48:56PM +0200, Stefan Strasser wrote:
> Andrew Haley schrieb:
> >Sam Lauber writes:
> > > I know that Bohem's GC is used in the Java runtime for GCC.
> > > However, the compiler proper itself can _really_ cramp people's
> > > avalible RAM (for those who don't belive me an
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
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.
Now, having said that, we do believe that it would make for interesting
research to try le
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
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.
expect memory to become a problem again with the advent of multicore a
Stefan Strasser wrote:
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
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.
expect memory to become a problem again with the
> 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.
Don't compare current GCC to 3.2 since the collection
On Apr 1, 2005, at 10:11 PM, Russell Shaw wrote:
Stefan Strasser wrote:
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
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.
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 of design.
>
> But you are not compiling on the
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
>> 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
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.
Andrew Pinski schrieb:
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.
you're right, I wasn't prepared to do performance tests:
gcc-Vers
Russell Shaw 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 of design.
For all those hoping to do gcc compilations on their wrist watches :-)
Gabriel Dos Reis wrote:
countries with obscure machines that escaped from Middle Age.
While I know a bit of third-wrld, I have also been working in some western
European countries for a sufficiant time to say that, well, far many real
machines used there for work in univeristies and research labs
Sam Lauber wrote:
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 w
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| countries with obscure machines that escaped from Middle Age.
| > While I know a bit of third-wrld, I have also been working in some
| > western
| > European countries for a sufficiant time to say that, well, far many real
| >
Robert Dewar <[EMAIL PROTECTED]> writes:
> But I doubt that projects to buy small linear gains in memory usage
> are mainstream very worthwhile in the long run (non-linear gains are
> *always* worth going after by contrast).
Last year CodeSourcery had a contract to speed up the C++ front end at
-
> | But I doubt that projects to buy small linear gains in memory usage
> | are mainstream very worthwhile in the long run (non-linear gains are
> | *always* worth going after by contrast).
>
> I wasn't aware that people were exclusively concentrating on small
> linear gains.
although don't know
[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 02.04.05 in <[EMAIL PROTECTED]>:
> While I know a bit of third-wrld, I have also been working in some western
> European countries for a sufficiant time to say that, well, far many real
> machines used there for work in univeristies and research labs
[EMAIL PROTECTED] (Mike Stump) wrote on 01.04.05 in <[EMAIL PROTECTED]>:
> On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
> > 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.
$2
Zack Weinberg wrote:
Last year CodeSourcery had a contract to speed up the C++ front end at
-O0, and we found that small linear reductions in memory usage
corresponded directly to small linear reductions in time usage, at
about a 2:1 ratio (so 1% less memory -> 0.5% less time). That
wouldn't be wo
Gabriel Dos Reis wrote:
I wasn't aware that people were exclusively concentrating on small
linear gains.
Since no one said they were, and since they aren't, it is not surprising
that you would be unaware of this non-fact :-) I didn't say people were
exclusively concentrating on such gains by any m
Robert Dewar <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> Last year CodeSourcery had a contract to speed up the C++ front end at
>> -O0, and we found that small linear reductions in memory usage
>> corresponded directly to small linear reductions in time usage, at
>> about a 2:1 ratio (so
Zack Weinberg wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
Zack Weinberg wrote:
Last year CodeSourcery had a contract to speed up the C++ front end at
-O0, and we found that small linear reductions in memory usage
corresponded directly to small linear reductions in time usage, at
about a 2:1 rat
On Sun, Apr 03, 2005 at 07:36:00PM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Mike Stump) wrote on 01.04.05 in <[EMAIL PROTECTED]>:
>
> > On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
> > > if gcc uses more memory than physically available it spends a _very_
> > > long ti
On Apr 3, 2005, at 3:58 PM, Robert Dewar wrote:
so the question
is do similar opportunities still exist?
GCC wiki has a laundry list @ http://gcc.gnu.org/wiki/Speedup%20areas
-
Devang
Joe Buck wrote:
$20? That does not seem to correspond to current prices:
Yes, Mike's off by a factor of roughly 5.
or n months for a not very large value of n :-)
43 matches
Mail list logo
