On Thu, Dec 09, 2010 at 02:34:27AM +0000, Dave Korn wrote: > On 08/12/2010 18:40, Andi Kleen wrote: > > > Fat LTO is just too slow. I suspect with that kind of performance > > penalty most people simply would not use it at all. > > How slow is "too" slow? How many people out of a hundred won't use it? Got > numbers, or just a gut feeling?
I didn't do a survey if that's what you're asking. It depends on what tree you use. Before Honza's rebalancing fixes it was really bad, especially with the tendency to run out of memory on a 3-4GB system and swap a lot (or generate too many temporary files and when you use tmpfs in ram that amounts to the same) There were also some problems that I had to limit parallelism below what my machine could do to run out of memory, but that also got better in mainline. Anyways with a recent 4.6 saw slowdowns in compilation of ~2.5x which is imho too slow. If it was < 1.5x or so things would be more acceptable I think, especially if the resulting code is significantly better. I believe Honza's gcc summit paper has more numbers: There seem to be also some other bottlenecks currently, like too much redundant information in the LTO files, which causes too much IO time. I haven't done detailed numbers again, but I expect slim LTO and when the other problems are fixed to be significantly faster and have a chance to be below 1.5. There's still some work to be done in all of these areas. The memory consumption issue probably also still needs some work, right now it's still too easy to start swapping. With slim LTO there's also some other avenues of speeding up available, for example it would be pretty simple to not call the assembler for the LTO generating stages but just write object files directly. I'm not fully sure how much this would buy. -Andi -- a...@linux.intel.com -- Speaking for myself only.
