This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster compilation speed

   From: Nick Ing-Simmons <>
   Date: Mon, 19 Aug 2002 13:15:27 +0100

   Yet another speed/space trade-off - most architecures are going to take
   significantly longer to inc/dec a bitfield than they will doing 
   an int. 
A dumb one too, I believed 24 bits were free but they certainly were
not.  It should indeed be an int.

   Which reminds me that one of the advantages of the "obstack" scheme 
   was it tended to act as a "slab allocator" with relatively few 
   chunks with lots of little things inside each chunk.
Actually one of the core things that Richard Henderson and others
continually ignore is that obstack put independent object types on
the same page.

This is the one of the huge (of many) problems with GC as it currently
is implemented.  Different tree and RTL types land on different pages
so when you walk a "SET" for example, the MEM and REG objects
contained within will be on different pages and this costs a lot
especially on modern processors.  Our page working set is huge as a
result of this.

In the obstack days, walking such a SET expression could very well
stay on the same page, even the same set of cachelines.

Tweaking GC stuff like making some new size classes as Richard has
done is going to solve none of these problems.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]