[racket] disable inlining for recursive functions

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 <samth at ccs.neu.edu> wrote:
> On Fri, Dec 7, 2012 at 8:25 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> On Fri, Dec 7, 2012 at 7:08 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>>> On Fri, Dec 7, 2012 at 7:12 AM, Matthew Flatt <mflatt at 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