On Fri, Dec 7, 2012 at 5:54 PM, Vincent St-Amour wrote:
> The upcoming version of Optimization Coach tries to do a better job at
> explaining inlining failures. Specifically, I'm working on function
> size-related heuristics that look like they may help here.
Cool!
> Could you send me some repr
At Fri, 7 Dec 2012 11:20:12 +0100,
Pierpaolo Bernardi wrote:
>
> Naively, I thought this was a no brainer for the inliner: small
> functions, used only once, no complex control flow. Why does it gives
> up?
>
> BTW, doing the inlines manually does actually make a difference in the
> total running
At Fri, 7 Dec 2012 07:38:11 -0600,
Robby Findler wrote:
>
> It does sound like a pretty painful process, tho, to manually inline
> things. Also abstraction breaking.
Macros make it a lot less painful. In a lot of cases, `define-syntax-rule'
is all you need.
Sam wrote a `define-inline' macro that
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 wrote:
> On Fri, Dec 7, 2012 at 8:25 AM, Robby Findler
> wrote:
>> On Fri, Dec 7, 2012 at 7:08 AM, Sam Tobin-Hochstadt
>> wrote:
>>
On Fri, Dec 7, 2012 at 8:25 AM, Robby Findler
wrote:
> On Fri, Dec 7, 2012 at 7:08 AM, Sam Tobin-Hochstadt wrote:
>> On Fri, Dec 7, 2012 at 7:12 AM, Matthew Flatt wrote:
>>>
>>> Tuning the inlining heuristics can easily make this kind of program go
>>> faster. Turning the inlining heuristics to
On Fri, Dec 7, 2012 at 7:08 AM, Sam Tobin-Hochstadt wrote:
> On Fri, Dec 7, 2012 at 7:12 AM, Matthew Flatt 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 o
On Fri, Dec 7, 2012 at 1:12 PM, Matthew Flatt wrote:
> From the inliner's perspective `sistemabile?' isn't all that small,
> because `for/or' expands to a significant pile of code. More
> importantly, it turns out that the loop inside `positione-accettabile?'
> is unrolled a little (i.e., a recurs
On Fri, Dec 7, 2012 at 7:12 AM, Matthew Flatt 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 w
>From the inliner's perspective `sistemabile?' isn't all that small,
because `for/or' expands to a significant pile of code. More
importantly, it turns out that the loop inside `positione-accettabile?'
is unrolled a little (i.e., a recursive call or two is inlined), so
after the unrolling, `sistema
I too have a curiosity about inlining.
In the following fragment of code, all the functions defined are used
in only one place. Optimization coach says the first and the fourth
are inlined, but not the others:
(define (posizione-accettabile? tabella pezzi)
(and (for/or ((posizione (in-list le-p
In addition to what Sam mentioned, if you use state in your function,
then the optimizer tends to give up early, so you can often stick a
set! that isn't doing anything to make it give up.
Robby
On Thu, Dec 6, 2012 at 12:27 AM, Denys Rtveliashvili wrote:
> Hello,
>
> Is there a way of disabling
See
On Wed, Dec 5, 2012 at 10:27 PM, Denys Rtveliashvili wrote:
> Hello,
>
> Is there a way of disabling the inlining for recursive functions?
See the `--disable-inline` flag to `raco make`.
Sam
Racket Users list:
http://lists.racket-lang.org/users
Hello,
Is there a way of disabling the inlining for recursive functions?
This code:
(define (do_loop i)
(when (< i 100)
(do_loop (add1 i
Is compiled into this:
(begin
(module test3
(require (lib "racket/main.rkt"))
(define-values
(_do_loop)
(lambda
13 matches
Mail list logo
