public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom St Denis <tstdenis@ellipticsemi.com>
To: Andrew Haley <aph@redhat.com>
Cc: Tony Wetmore <tony.wetmore@solipsys.com>,
	  Alejandro Pulver <alepulver@FreeBSD.org>,
	 gcc-help@gcc.gnu.org
Subject: Re: Reducing compilation memory usage
Date: Sun, 20 Jan 2008 19:08:00 -0000	[thread overview]
Message-ID: <4790F8F1.40805@ellipticsemi.com> (raw)
In-Reply-To: <4790F090.3080606@redhat.com>

Andrew Haley wrote:
> Tony Wetmore wrote:
>> Alejandro Pulver wrote:
>>  >> RAM!  Of course we could make gcc more economical, and
>>  >> we could somewhat reduce memory usage, but you're asking
>>  >> for something really hard.
>>  >
>>  > I wasn't asking to change the program, I was just asking
>>  > if there is an already existing option.
>>
>> I think Andrew may have meant that you are asking GCC to do something 
>> really hard, to optimize a single function that is so large.  And 
>> asking the compiler to do something that hard has a price -- it 
>> requires lots of memory, as you have discovered.
>
> I was saying exactly that, thank you for clarifying.
>
> The thing to realize is that it is really hard to do a great job of 
> optimizing
> huge functions.  So, it's quite likely that gcc will do a better job of
> optimizing a bunch of small functions, with well-contained locality of 
> variables,
> than one huge function.
>
> OK, so you will have the overhead of a function call.  But on most 
> architectures
> that isn't enormous.

Dropping some Friday afternoon pair of cents ...

You shouldn't really have large functions unless their machine made 
anyways.  And even then it's best to try and factor them as much as 
possible.  In one of my math libraries I have huge unrolled multipliers, 
for things like 1024x1024 bit multiplications (on a 32-bit platform that 
means 1024 MULADD macros).  Originally, I had all of the multipliers 
[different functions] in a single .C file which was machine generated.  
Later I found GCC performs much better on the same code if I left it one 
huge function per file.

Anyways ... on code that's human-written, you should never really run 
into any of these sorts of limits.  Otherwise, you're not thinking about 
your design properly.

Tom

  reply	other threads:[~2008-01-18 19:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-17 19:10 Alejandro Pulver
2008-01-18  6:20 ` John (Eljay) Love-Jensen
2008-01-18  6:27   ` Alejandro Pulver
2008-01-18  8:22     ` John (Eljay) Love-Jensen
2008-01-18 10:56       ` Alejandro Pulver
2008-01-18 14:12         ` Tony Wetmore
2008-01-18 16:00           ` Alejandro Pulver
2008-01-19  3:49             ` Andrew Haley
2008-01-20 11:44               ` Alejandro Pulver
2008-01-20 13:19                 ` Tony Wetmore
2008-01-20 18:35                   ` Andrew Haley
2008-01-20 19:08                     ` Tom St Denis [this message]
2008-01-21  1:25                       ` Alejandro Pulver
2008-01-18 14:40         ` John (Eljay) Love-Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4790F8F1.40805@ellipticsemi.com \
    --to=tstdenis@ellipticsemi.com \
    --cc=alepulver@FreeBSD.org \
    --cc=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=tony.wetmore@solipsys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).