From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Miller" To: nick.ing-simmons@elixent.com Cc: gcc@gcc.gnu.org, dalej@apple.com Subject: Re: Faster compilation speed Date: Mon, 19 Aug 2002 07:06:00 -0000 Message-id: <20020819.065139.68998339.davem@redhat.com> References: <20020814.104244.64882664.davem@redhat.com> <20020819121527.1337.18@bactrian.elixent.com> X-SW-Source: 2002-08/msg01094.html 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.