On Fri, Jul 31, 2015 at 5:40 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> At Fri, 31 Jul 2015 15:03:53 +0100, Laurent wrote:
> > I don't really understand why `in-range` makes such a difference. It
> looks
> > like the kind of sequence iterator is tested at each step, whereas I was
> > expecting it to be tested only at the beginning of the loop, since this
> > sequence iterator kind can't change from one iteration to the next,
> right?
> >
> > Hence, I was expecting the `in-range` (and actually all other `in-*`)
> issue
> > to appear only inside nested loops, where some loops are started many
> times
> > (thus requiring many iterator kind tests).
>
> Right: The `in-*` functions tell `for` what kind of step operations to
> inline into the loop (after an initial guard that confirms that it has
> a number, list, etc., to iterate through). Otherwise, there's a
> run-time dispatch to take each step, which is usually more significant
> than a run-time dispatch to set up the loop.
>
Apparently the optimizer is looking very specifically for `in-range`. This:
(define my-in-range in-range)
(time (for ([x (my-in-range 40000000)])
(+ x 3)))
is as slow as not using `in-range` at all, which I find rather strange.
By "run-time dispatch", do you mean that the check of which kind the
argument is is done at each iteration?
Isn't it possible to test this only on the very first iteration? Then the
rest of the loop should be as fast as with `in-range`.
I'm certainly missing something here (unless it's only a question of
spending the necessary time to implement this, rather than a question of
feasibility?).
> At Fri, 31 Jul 2015 16:41:51 +0100, Laurent wrote:
> > My question still holds though: Can I expect the JIT to optimize the
> cases
> > of my primary concern? (Or are these cases unlikely to be a bottleneck?)
> > I'm unsure about how to set up correct stress tests as the JIT does a
> good
> > job at optimizing a number of things and then I'm not sure what precisely
> > I'm measuring.
>
> I think you should expect optimization in cases like this, but you'll
> be disappointed sometimes. All optimizations are hueristics, and
> heuristics for inlining (the relevant optimization here) are especially
> tricky. I think the v6.2 difference is probably a result of Gustavo's
> refinements to the heuristics for inlining.
>
The Optimization Coach helps you with one reliable strategy for dealing
> with the optimizer, which is to compile some code and see what the
> optimizer does.
>
Thanks.
--
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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
