It does sound like a pretty painful process, tho, to manually inline things. Also abstraction breaking.
Robby On Fri, Dec 7, 2012 at 7:30 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote: > On Fri, Dec 7, 2012 at 8:25 AM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> On Fri, Dec 7, 2012 at 7:08 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> >> wrote: >>> On Fri, Dec 7, 2012 at 7:12 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >>>> >>>> Tuning the inlining heuristics can easily make this kind of program go >>>> faster. Turning the inlining heuristics to make this program go faster >>>> while also not slowing down other programs --- well, that's much more >>>> difficult. Of all the ways that I've worked on the compiler, experiments >>>> with the inlining heuristics have felt particularly unrewarding. :) >>> >>> This is one reason why we created Optimization Coach in the first >>> place. Now that we know what's not inlined in this program, Pierpaolo >>> can manually inline the functions that the inliner skips by using >>> macros, and see if that improves performance. Without Optimization >>> Coach, it's hard to even ask the right questions in the first place. >> >> Does this suggest that maybe the inliner should be less "clever" and >> we should let programmers look at OC's output and then add directives >> or something to help help guide it? > > I think we still want the inliner to be as smart as possible -- using > Optimization Coach is still work for every programmer, not just the > inliner developer, but I do think it takes pressure off the inliner > (and Matthew) to be perfect for everyone. > > Sam ____________________ Racket Users list: http://lists.racket-lang.org/users
