----- Original Message ----- > From: "David Chisnall" <david.chisn...@cl.cam.ac.uk> > To: "Xinliang David Li" <xinlian...@gmail.com> > Cc: "Xinliang David Li" <davi...@google.com>, cfe-commits@cs.uiuc.edu, "List" > <llvm...@cs.uiuc.edu> > Sent: Thursday, July 9, 2015 3:09:30 AM > Subject: Re: [LLVMdev] Inline hint for methods defined in-class > > On 9 Jul 2015, at 08:00, Xinliang David Li <xinlian...@gmail.com> > wrote: > > > > You need to be more specific on why the regression is problematic > > (and more so than missed opportunities). Text size increase > > (shared and much smaller than heap) is usually not a big issue > > except for tiny devices which is likely to use Os/Oz in the build. > > For servers, there are are simple rules to compare cpu vs ram > > resource cost. > > Text size increase also means more TLB and i-cache misses.
This is not necessarily true, and may not even generally be true. It certainly could be true under realistic circumstances, but if the inlining is effective, even if the number of cache lines or pages of all potentially-hot regions increases, that does not necessarily imply that the number of number of cache lines or TLB entries demanded in a generic small time window increases. In fact, in should decrease, because the code in any given hot region is more localized. There are, of course, many factors here, and I agree that the trade-offs can be subtle, but I don't think we can try to do any kind of whole-system-workload optimization here without substantially more information. We don't have any idea what the cost function is, and in fact, it may be so different on different systems that we can't, as a community, really account for any of them. -Hal > We’ve > observed that single-program benchmarks show this quite poorly, but > the aggregate increase in i-cache and TLB pressure across the entire > system can degrade performance overall on a typical desktop workload > (not so relevant for single-application servers, but very relevant > for server VMs). > > I believe some folks at Apple did a more systematic analysis of this, > but I don’t know if their detailed results are public. > > David > > > > _______________________________________________ > LLVM Developers mailing list > llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
