On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
GCC has also been getting improved functionality, better optimizations, and better language support. Some of these improvements are going to cost us at compile time, because better optimizations can require more time, and today's languages require more work to compile and optimize than yesterday's. No, I don't want my compiler to be 5% slower, but I'll give up 5% for better standards conformance and improved code generation.
Of course, the problem is not 5%, but the yet again 5%, on top of, I don't know, 200% since GCC 2.95.3?? Also, it is "better optimizations" for some purposes, but not for others. For example, many of the >140 passes are redundant for typical C code.
It's not all bad news, either. Canonical types got us 3-5% speedup in the C++ front end (more on template-heavy code), so I figure I have at least a 3% speedup credit I can apply against the 9-bit code patch. That brings this patch under 2% net slow-down, so we should just put it in now :)
But only for C++. I'm still in favor of the 9-bit code patch. But I think the slowdown should not be taken so lightly as you appear to do ;-) Gr. Steven
