Steven Bosscher wrote: > On 3/22/07, Joe Buck <[EMAIL PROTECTED]> wrote: >> But these numbers show that subcodes don't cost *ANY* time, or the >> cost is in the noise, unless enable-checking is on. The difference >> in real-time seems to be an artifact, since the user and sys times >> are basically the same. > > The subcodes cost complexity. And the cost with checking enabled is > IMHO unacceptable.
Doug, thanks for doing all the experiments! OK, we've got to pick our poison. 1. We can go to 9-bit codes. They're slower, independent of checking. Maybe we can make bitfields go faster, and get some of that back. Of course, if we can make bitfields go faster, GCC would probably still go even faster with 8-bit codes than it will with 9-bit codes, since all the other bitfield accesses in GCC will go faster. The good news is that this is simple, from a coding perspective, and probably uses no more memory. 2. We can go to 16-bit codes. They're slower than 8-bit codes, perhaps because they use more memory, but not much -- and certainly seem less slower than 9-bit codes. This is just as simple, from a coding perspective as (1). 3. We can go to subcodes. These are no slower and use no less memory for production compilers, but they make checking compilers unbelievably slow. (Frankly, I already find checking painful. I run tests that way, of course, but I'm always amazed how much faster release-branch compilers go.) They're complex. I think I'm inclined to agree with Mike: I'm starting to prefer (2). It's a simple solution, and pretty efficient. Anyone want to champion (1) or (3)? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
