This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
From: Nick Ing-Simmons <email@example.com>
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
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.