> 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,
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
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" --
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
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
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
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
7 matches
Mail list logo