Thank you, Matthias. Thanks to Vincent and everyone else who answered as well. I'll experiment with the coach.
Best regards, --Jerry On Fri, Apr 29, 2016 at 9:16 AM, Matthias Felleisen <[email protected]> wrote: > > 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.
