Re: The bloat sweepstakes...

Re: The bloat sweepstakes...

[dewar]

<<I don't have much sympathy with the attitude that memory, or even
address space, is free.  If nothing else, these huge buffers are
likely to be *slower* than more reasonably sized buffers because they
trash the memory caches.
>>

Ah, I think I see the point you were making. You are assuming that the
buffer will actually be used. Not at all, in practice only a very small
fraction will ever be used. It is there for unusual cases. Now your point
is that in these unusual cases, it might be better to have a circuit for
chopping things -- possibly -- but this still seems samll potatoes to me.

Re: The bloat sweepstakes...

[Richard Henderson]

On Mon, Oct 22, 2001 at 08:02:50AM -0600, law@redhat.com wrote:
> A short may work.  Then again it may not -- we've certainly seen
> costs overflow a short in the past on some ports.

Differentiate between the cost as used to accumulate from
the per-move cost.  The later is what we wish to store in
the arrays, not the former.


r~

Re: The bloat sweepstakes...

[law]

  In message < 20011022003928.E3425@codesourcery.com >you write:
  > On Wed, Oct 17, 2001 at 07:08:32PM -0600, law@redhat.com wrote:
  > >   In message < 20011010150953.U9432@codesourcery.com >you write:
  > >   > I think costs never get higher than 10 or so;
  > > They certainly do get higher than 10.  Also remember that costs accumulat
  > e
  > > across the uses of a register.  Making them an unsigned character probabl
  > y
  > > is not a wise idea.
  > 
  > The arrays that are taking up lots of space are the ones in regclass.c
  > (move_cost, may_move_in_cost, may_move_out_cost), and it looks to me
  > like they don't ever get very high.  In fact, 65536 is being used in
  > regclass as infinity, suggesting that it would at least be safe to
  > make them short.
A short may work.  Then again it may not -- we've certainly seen costs overflow
a short in the past on some ports.  When that's happened in the past we have
simply twiddled the costs for the port in question to make overflow less
likely -- certainly with a suitably ugly function we could still overflow.


jeff

Re: The bloat sweepstakes...

[Zack Weinberg]

On Wed, Oct 17, 2001 at 07:08:32PM -0600, law@redhat.com wrote:
>   In message < 20011010150953.U9432@codesourcery.com >you write:
>   > I think costs never get higher than 10 or so;
> They certainly do get higher than 10.  Also remember that costs accumulate
> across the uses of a register.  Making them an unsigned character probably
> is not a wise idea.

The arrays that are taking up lots of space are the ones in regclass.c
(move_cost, may_move_in_cost, may_move_out_cost), and it looks to me
like they don't ever get very high.  In fact, 65536 is being used in
regclass as infinity, suggesting that it would at least be safe to
make them short.

zw

Re: The bloat sweepstakes...

[law]

  In message < 20011010150953.U9432@codesourcery.com >you write:
  > I think costs never get higher than 10 or so;
They certainly do get higher than 10.  Also remember that costs accumulate
across the uses of a register.  Making them an unsigned character probably
is not a wise idea.

jeff

Re: The bloat sweepstakes...

[Zack Weinberg]

On Thu, Oct 11, 2001 at 04:03:09PM +1000, Fergus Henderson wrote:
[...]
> > I very much hope it doesn't scan rodata, because I
> > have Cunning Plans to reduce the text size considerably at the expense
> > of a somewhat larger rodata.  Note that much of rodata is strings.
> 
> What it scans is system-dependent.  It's determined by DATASTART and
> DATAEND in gcconfig.h.  On most systems, DATASTART seems to be defined
> as &_etext, and on the systems that I'm familiar with, &_etext generally
> precedes the rodata section.  (At least that is my understanding. 
> I could be wrong about that.  See below.)

Oh, I get it now.  I was thinking in terms of the way the operating
system maps the executable into memory, not the visible symbols
marking text/rodata/data boundaries.  It puts text and rodata in one
chunk mapped read-only, and data+bss+malloc heap in another chunk
mapped read-write.

One could in theory locate the lowest writable address by an algorithm
such as

   char *x = (char *) &symbol_known_to_be_in_data_segment;
   char c;
   x -= (x % PAGESIZE);
   do {
     x -= PAGESIZE;
     c = *x;
     *x = c;
   } while (!segmentation_fault);
   x += PAGESIZE;

This is obviously not necessary in a context where you know that
DATASTART really is the beginning of the writable data segment.  For
paranoia's sake it would be a good idea to distinguish between read
faults on "c = *x;" and write faults on "x = *c;"; the former mean
you've hit unmapped memory and therefore something has gone off the
rails (or the OS puts an unmapped guard page between text and data).

zw

Re: The bloat sweepstakes...

[Fergus Henderson]

On 10-Oct-2001, Zack Weinberg <zack@codesourcery.com> wrote:
> On Wed, Oct 10, 2001 at 04:24:03PM +1000, Fergus Henderson wrote:
> > Note that the rodata and bss sizes are both problematic for the Mercury
> > front-end.  The reason is that the Mercury front-end uses the Boehm
> > conservative collector, which scans the bss section and
> > (on most systems) the rodata section. [...]
> That seems strange to me: it does scan rodata and it doesn't scan
> text?

It doesn't scan text on any of the supported systems, AFAIK.
But it does scan rodata on most of them, I think.

> On most systems I am familar with, the boundary between
> (text+rodata) and (data+bss) is obvious, but the boundary between text
> and rodata is not.

That's not the case for most of the systems I'm familiar with.

> I very much hope it doesn't scan rodata, because I
> have Cunning Plans to reduce the text size considerably at the expense
> of a somewhat larger rodata.  Note that much of rodata is strings.

What it scans is system-dependent.  It's determined by DATASTART and
DATAEND in gcconfig.h.  On most systems, DATASTART seems to be defined
as &_etext, and on the systems that I'm familiar with, &_etext generally
precedes the rodata section.  (At least that is my understanding. 
I could be wrong about that.  See below.)

However, on x86 Linux, it does look like the Boehm collector has now
been optimized to not scan rodata, by setting DATASTART to &__data_start
rather than &_etext.

Since your expectation obviously differed from mine here, I tested a few
systems, namely i686-pc-linux-gnu (binutils 2.9.1), alpha-dec-osf3.2,
and i386-pc-solaris2.7.  For the first two, &_etext precedes rodata,
but for the last one, it is the other way around.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: The bloat sweepstakes...

[Zack Weinberg]

On Wed, Oct 10, 2001 at 04:24:03PM +1000, Fergus Henderson wrote:
> On 07-Oct-2001, Zack Weinberg <zack@codesourcery.com> wrote:
> > Largely for amusement, here's some statistics on the sizes of the
> > compiler binaries.  All figures are in kilobytes, for the final stage
> > of an i386 native bootstrap.  First, the back end:
> > 
> > text    rodata  data    bss     total   file
> > 2360.3  457.2   17.2    494.5   3329.3  libbackend.a
> 
> Note that the rodata and bss sizes are both problematic for the Mercury
> front-end.  The reason is that the Mercury front-end uses the Boehm
> conservative collector, which scans the bss section and
> (on most systems) the rodata section.  (There's actually no need for
> the conservative collector to scan the rodata section, since that can't
> contain pointers to the heap, but unfortunately it's hard to tell where
> the rodata section starts and ends.)

That seems strange to me: it does scan rodata and it doesn't scan
text?  On most systems I am familar with, the boundary between
(text+rodata) and (data+bss) is obvious, but the boundary between text
and rodata is not.  I very much hope it doesn't scan rodata, because I
have Cunning Plans to reduce the text size considerably at the expense
of a somewhat larger rodata.  Note that much of rodata is strings.

These are the largest single items in cc1's bss segment (sizes in KB):

141.6   move_cost
141.6   may_move_out_cost
141.6   may_move_in_cost
26.3    floattab
26.3    fixtrunctab
26.3    fixtab
26.3    extendtab
12.0    reg_save_code
12.0    ssa_rename_to_hard
12.0    reg_restore_code

None of these contain any pointers.  Perhaps what is needed is some
sort of annotation visible to the Boehm collector, that certain data
or bss items do not contain pointers.

I think costs never get higher than 10 or so; we could cut the size of
the cost arrays by a factor of four by using unsigned char instead of
int.  Or am I mistaken about this?

zw

Re: The bloat sweepstakes...

[Fergus Henderson]

On 07-Oct-2001, Zack Weinberg <zack@codesourcery.com> wrote:
> Largely for amusement, here's some statistics on the sizes of the
> compiler binaries.  All figures are in kilobytes, for the final stage
> of an i386 native bootstrap.  First, the back end:
> 
> text    rodata  data    bss     total   file
> 2360.3  457.2   17.2    494.5   3329.3  libbackend.a

Note that the rodata and bss sizes are both problematic for the Mercury
front-end.  The reason is that the Mercury front-end uses the Boehm
conservative collector, which scans the bss section and
(on most systems) the rodata section.  (There's actually no need for
the conservative collector to scan the rodata section, since that can't
contain pointers to the heap, but unfortunately it's hard to tell where
the rodata section starts and ends.)

This means that if the GCC back-end is linked in with the Mercury
compiler, it will slow down compilation, due to the need for the Boehm GC
to scan those areas.  And this slow-down will occur even if GCC back-end
is not being used, e.g. when compiling via C.

This is a significant disincentive to including the GCC-based
native-code back-end in the standard Mercury distribution.

So it would certainly be nice if those rodata and bss sizes could be
reduced...

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: The bloat sweepstakes...

[Zack Weinberg]

On Mon, Oct 08, 2001 at 01:07:03PM -0400, dewar@gnat.com wrote:
> by the way, in our experience with GNAT, it is the backend that is the
> huge consumer of (real) memory, the front end almost always has smaller
> memory requirements by a significant factor.

Oh yes.  I've got a list of things to do to the back end to cut down
its memory usage, in fact.

I may have overstated things; I didn't mean to imply that this one
buffer was that much of a memory consumption problem in real life.
Laurent seemed interested, is all.

zw

Re: The bloat sweepstakes...

[dewar]

by the way, in our experience with GNAT, it is the backend that is the
huge consumer of (real) memory, the front end almost always has smaller
memory requirements by a significant factor. In fact we started out with
an aggressive viewpoint of saving memory, and minimizing nodes (see the
irregulatiries of the handling of string literals for example). Only
to discover that front end memory use was pretty much irrelevant. At
the same time I agree that buffer may as well be a bit smaller, why not.

Re: The bloat sweepstakes...

[dewar]

<<I don't have much sympathy with the attitude that memory, or even
address space, is free.  If nothing else, these huge buffers are
likely to be *slower* than more reasonably sized buffers because they
trash the memory caches.
>>

Sorry, I don't see this at all, how can a megabyte of unused virtual
memory possibly affect the memory caches.

And we are talking just about address space here.

Re: The bloat sweepstakes...

[Zack Weinberg]

On Sun, Oct 07, 2001 at 06:16:15PM -0400, dewar@gnat.com wrote:
> Probably the string buffer in lib.utils could be smaller, but really in 
> these days when typical development machines have at least 256M of real
> memory, this is hardly a significant issue.

Didn't we just have a thread where 17MB of total memory consumption by
cc1 was enough to get "virtual memory exhausted"?

I don't have much sympathy with the attitude that memory, or even
address space, is free.  If nothing else, these huge buffers are
likely to be *slower* than more reasonably sized buffers because they
trash the memory caches.

zw

Re: The bloat sweepstakes...

[dewar]

<<There's room for constant tuning here, but I assume there may be a
reason why a 2MB buffer size was choosen here, anyone?
>>

Basically on the systems we are compiling GNAT on, large buffers like
this are close to free, but if there are systems where this is not true,
it should be rethought, the buffer could certainly be much smaller.

Re: The bloat sweepstakes...

[dewar]

<<Surely there's some form of dynamic allocation you could use for this,
though.  Or just not buffering the file in such huge chunks?  C stdio
tends to use buffers on the order of a memory page...
>>

Would this really gain? Are there really systems so messed up that large
unused buffers like this cost real disk space or real memory?

Re: The bloat sweepstakes...

[dewar]

Probably the string buffer in lib.utils could be smaller, but really in 
these days when typical development machines have at least 256M of real
memory, this is hardly a significant issue. Indeed on most systems with
allocate on use, this is not real memory that is used at all, just
unused virtual memory space. Declaring large buffers like this should
be close to free.

Re: The bloat sweepstakes...

[guerby]

Ooops got the wrong constant :).

There's room for constant tuning here, but I assume there may be a
reason why a 2MB buffer size was choosen here, anyone?

-- 
Laurent Guerby <guerby@acm.org>

Re: The bloat sweepstakes...

[Zack Weinberg]

On Sun, Oct 07, 2001 at 08:44:50PM +0200, guerby@acm.org wrote:
> The String buffer in Lib.Utils should be around 580KB, not sure why it is
> showing up at 2MB? 

 -- from lib-util.adb:

   Max_Line   : constant Natural := 2 * Hostparm.Max_Name_Length + 64;
   Max_Buffer : constant Natural := 1000 * Max_Line;

   Info_Buffer : String (1 .. Max_Buffer);

 -- from hostparm.ads:

   Max_Name_Length : constant := 1024;

so, (2 * 1024 + 64) * 1000 = 2112000 bytes = 2062.5K.

Sure enough,

$ nm lib-util.o | grep info_buffer
00203a00 C lib__util__info_buffer

and hex 203a00 = decimal 2112000.

> All GNAT compiler IO is done by fast and low level routines, dependancies over
> Ada.Text_IO would bring piles of complicated runtime stuff into the
> compiler, and we don't want that (plus it would probably be slower :).

Makes sense.

Surely there's some form of dynamic allocation you could use for this,
though.  Or just not buffering the file in such huge chunks?  C stdio
tends to use buffers on the order of a memory page...

zw

Re: The bloat sweepstakes...

[guerby]

The String buffer in Lib.Utils should be around 580KB, not sure why it is
showing up at 2MB? 

All GNAT compiler IO is done by fast and low level routines, dependancies over
Ada.Text_IO would bring piles of complicated runtime stuff into the
compiler, and we don't want that (plus it would probably be slower :).

--
Laurent Guerby <guerby@acm.org>

Re: The bloat sweepstakes...

[Zack Weinberg]

On Sun, Oct 07, 2001 at 07:44:03PM +0200, guerby@acm.org wrote:
> > 1857.3  264.9   13.2   2321.9   4457.2  gnat1
> 
> I'm curious as from where this big BSS is coming from and I'm
> surprised BSS size is adding up into the final executable size, do I
> miss something (BSS does not need to be present in the executable
> since it's for unitialized data, right)?

BSS does not take up space in the on-disk file, but it does contribute
to the in-memory footprint of the compiler, so it seemed relevant.

Hmm... nm --size-sort suggests that most of it is lib__util__info_buffer,
weighing in at just over 2MB.  I think this is for dumping .ali files;
it's not clear to me why it is not using Text_IO.

zw

Re: The bloat sweepstakes...

[guerby]

> 1857.3  264.9   13.2   2321.9   4457.2  gnat1

I'm curious as from where this big BSS is coming from and I'm
surprised BSS size is adding up into the final executable size, do I
miss something (BSS does not need to be present in the executable
since it's for unitialized data, right)?

--
Laurent Guerby <guerby@acm.org>

The bloat sweepstakes...

[Zack Weinberg]

Largely for amusement, here's some statistics on the sizes of the
compiler binaries.  All figures are in kilobytes, for the final stage
of an i386 native bootstrap.  First, the back end:

text    rodata  data    bss     total   file
2360.3  457.2   17.2    494.5   3329.3  libbackend.a
 525.8  259.7    1.1      0.0    786.6  (insn-*.o)

The biggest (in terms of text size) object modules are all insn-*.o
files, which is why they get their own entry.  i386.o is also hefty,
at just over 100K.  The top three language-independent modules are
expr.o, fold-const.o, and dwarf2out.o, at 130K, 100K, and 94K respectively.

It is amusing to note that the huge language-independent modules are
all rather old.  The biggest recently-added module is gcse.o at 43K.

Now the front ends.  For these I subtracted the total size of
libbackend.a from all the columns.

 313.6  110.6    0.9    137.4    562.5  cc1
 391.4  130.7    1.1    138.1    661.3  cc1obj
1053.2  247.9    2.1    147.2   1450.5  cc1plus
 550.7  169.9   25.7    156.5    902.7  f771
1857.3  264.9   13.2   2321.9   4457.2  gnat1
 431.1   88.4   17.8    141.9    679.3  jc1

There's a few more static libraries in the mix, but they're all less
than 100K, and unlike libbackend it is possible that large chunks have
been left out of the final executables.

  74.3   14.8    0.3      0.7     90.1  libiberty.a
  27.5    1.4    0.1      0.0     29.0  libgcc.a
  56.4   20.6    0.0      0.0     77.1  libcpp.a	(cc1, cc1plus, cc1obj)
  28.4    5.4    4.5      0.0     38.3  libz.a		(jc1)

zw