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
