Re: [racket-users] Compiler question

2016-04-30 Thread Gustavo Massaccesi
> 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. My recommendation is to write nice code,

Re: [racket-users] Compiler question

2016-04-29 Thread Jerry Jackson
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 wrote: > > Jerry, you may not have understood Vincent's concise response. > > No

Re: [racket-users] Compiler question

2016-04-29 Thread Matthias Felleisen
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" --

Re: [racket-users] Compiler question

2016-04-27 Thread 'William J. Bowman' via Racket Users
On Wed, Apr 27, 2016 at 01:52:24PM -0600, Jerry Jackson wrote: > I'd really be interested in how the two forms look when they've both been > reduced to some canonical internal format. You can use `raco expand` the result after macro expansion, and `raco decompile` to look at the result of

Re: [racket-users] Compiler question

2016-04-27 Thread Jerry Jackson
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

Re: [racket-users] Compiler question

2016-04-27 Thread Vincent St-Amour
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

Re: [racket-users] Compiler question

2016-04-27 Thread Matthew Flatt
The compiler inlines the call to `aux` in `fib2` because that call is readily apparent. It's not so apparent in the other cases that the function `aux` is always called. At Wed, 27 Apr 2016 06:42:03 -0700 (PDT), Jerry Jackson wrote: > Hello all, > > I was experimenting a bit yesterday and