Jerry, you may not have understood Vincent's concise response. No reasonably expressive PL on Earth will allow you to predict the performance of micro-benchmarks (not to speak of large programs) within reasonable bounds. When compiler optimizations fail -- what you call "pessimizing style" -- the compiler simply generates different code. In a non-trivial programs, the contexts vary too much to predict performance. In one context, in-lining may succeed, in another a similar looking one may fail.
We have known this for decades, and programmers have suffered from this problem for equally long. Vincent's dissertation does something about it. His "compiler coach" or "optimization coach" is NOT a profiler. It is a tool that explains the compiler's design decisions. In this particular case, it explains that the compiler can in-line a "directly apparent" call (as Matthew might call it) and will not in-line a "higher-order call" as I might refer to your choice of style. Take a look and experiment. It's NOT a profiler. I doesn't involve decompilation or looking at the expansion. It's pleasant to use. If you have feedback, please let us know -- Matthias On Apr 27, 2016, at 3:52 PM, Jerry Jackson <[email protected]> wrote: > I appreciate the responses; at this point, however, I'm trying to figure out > what to do with my intuition. If those two pieces of code don't compile to > the same thing, I'm not sure how I should approach code style. I tend to > favor ((if x y z) foo) over (if x (y foo) (z foo)) because it avoids > redundancy and localizes the choice. Apparently, that's a pessimising choice > and I now don't feel like I have much intuition at all about how things will > perform. Obviously, I can use profiling to track such things down but... > > I'd really be interested in how the two forms look when they've both been > reduced to some canonical internal format. > > Thanks, > --Jerry > > > > On Wed, Apr 27, 2016 at 8:49 AM, Vincent St-Amour > <[email protected]> wrote: > When you have a program that's surprisingly fast (or slow), you can use > the optimization coach in DrRacket (in the "view" menu) to see what > optimizations Racket applies to your code. > > For your program, the coach confirms Matthew's diagnosis that inlining > is what makes `fib2` faster. > > Vincent > > > On Wed, 27 Apr 2016 08:42:03 -0500, > Jerry Jackson wrote: > > > > Hello all, > > > > I was experimenting a bit yesterday and discovered something that surprised > > me. Here are two fibonacci functions: > > > > (define fib1 > > (letrec ([aux (lambda (i n) > > (if (< n 2) > > 1 > > (+ (fib1 i (- n 2)) (fib1 i (- n 1)))))]) > > (let ([funs (vector aux aux)]) > > (lambda (index num) > > ((if (= index 0) aux (vector-ref funs index)) index num))))) > > > > (define fib2 > > (letrec ([aux (lambda (i n) > > (if (< n 2) > > 1 > > (+ (fib2 i (- n 2)) (fib2 i (- n 1)))))]) > > (let ([funs (vector aux aux)]) > > (lambda (index num) > > (if (= index 0) > > (aux index num) > > ((vector-ref funs index) index num)))))) > > > > I expected them to behave basically identically (in fact, I thought they > > would probably generate the same code). However, that was not the case: > > > > > (time (fib1 0 40)) > > cpu time: 4490 real time: 4489 gc time: 0 > > 165580141 > > > (time (fib1 1 40)) > > cpu time: 5031 real time: 5027 gc time: 0 > > 165580141 > > > (time (fib2 0 40)) > > cpu time: 3042 real time: 3040 gc time: 0 > > 165580141 > > > (time (fib2 1 40)) > > cpu time: 5031 real time: 5027 gc time: 0 > > 165580141 > > > (time (fib1 0 40)) > > cpu time: 4535 real time: 4532 gc time: 0 > > 165580141 > > > (time (fib2 0 40)) > > cpu time: 3027 real time: 3025 gc time: 0 > > 165580141 > > > > > > > It looks like one of the functions is 1.5 times faster than the other (in > > the i == 0 case). Any ideas as to why? > > > > Thanks, > > --Jerry Jackson > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
