This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed: cache behavior
- From: Matt Austern <austern at apple dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 20 Aug 2002 15:47:31 -0700
- Subject: Re: Faster compilation speed: cache behavior
On Tuesday, August 20, 2002, at 03:21 PM, Neil Booth wrote:
Matt Austern wrote:-
As these numbers suggest, using cc1plus takes much longer than
using cc1.
The fact that list_length and ht_lookup and cp_tree_node_structure
are so high suggests that we've got poor locality in tree node
allocation. The fact that cp_tree_node_structure is so high
suggests that we're probably getting a lot of cache misses
during garbage collection.
ht_lookup will be fixed when identifiers stop being trees. Being
a tree means a lot of unnecessary baggage in the struct, and
unpredictable allocation like you say.
However, making identifiers not be trees requires de-obfuscation
of various derived tree structures, which I don't hold out much
hope for in the near term...
I agree that making identifiers not be trees would be (a) valuable;
and (b) difficult.
However, I wonder if there might be some useful intermediate
steps. It looks to me as if a lot of tree nodes might be larger
than necessary, and that it might be possible to squeeze out
some useless information case by case. If we allocate fewer
and smaller nodes, and if we aren't gratuitously stupid, then
we're pretty much guaranteed to improve locality.
One thing we've noticed at Apple---I don't know whether or
not this is conventional wisdom---is that the distribution of
node types is very uneven. The top five tree node types
account for 50% of the storage! I think there are some big
gains to be made in the ways we deal with IDENTIFIER_NODE
and INTEGER_CST, for example. (Especially if we're willing to
use "clever" tricks.)
--Matt