I see, thanks for the explanations, Matthew. So that's the kind of things
that are "simple in principle, but more complicated than one would like in
practice" then. Good luck with your experiments!
On Fri, Jul 31, 2015 at 10:02 PM, Matthew Flatt wrote:
> At Fri, 31 Jul 2015 18:56:15 +0100, Laure
At Fri, 31 Jul 2015 18:56:15 +0100, Laurent wrote:
> On Fri, Jul 31, 2015 at 5:40 PM, Matthew Flatt 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 test
On Fri, Jul 31, 2015 at 5:40 PM, Matthew Flatt 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 on
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 ki
Yes indeed (and thanks all).
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
FWIW, the optimization coach reports these kinds of issues, and
recommends that solution.
Vincent
On Fri, 31 Jul 2015 09:03:53 -0500,
Laurent wrote:
>
> Oh wow, this makes a huge difference indeed! (both in-range and v6.2)
> Congrats for the efforts put in the new version!
>
> I don't really
Oh wow, this makes a huge difference indeed! (both in-range and v6.2)
Congrats for the efforts put in the new version!
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
Laurent wrote on 07/31/2015 09:05 AM:
That's a simplified version of some cases of mine where several
complex procedures that look very much alike, so I'd really like to
avoid copy/paste/maintain, but these procedures are also inside
intensive loops, so I'd really like to not sacrifice speed.
Also, which version of Racket are you using? With v6.1.1 and
`in-range`, I get
cpu time: 745 real time: 744 gc time: 0
cpu time: 205 real time: 205 gc time: 0
cpu time: 782 real time: 782 gc time: 0
cpu time: 205 real time: 206 gc time: 0
but with v6.2 and `in-range`, I get
cpu time: 209 re
I think you want to use `in-range`. On my machine, adding `in-range`
makes each loop run 20 times faster --- which means that the original
loops are just testing the performance of the generic sequence case of
`for`.
(Probably we should make `for` recognize and specialize literal
integers, and I t
Hi,
A little stress test seems to suggest that the JIT is currently not able to
optimize closures with static arguments:
https://gist.github.com/Metaxal/4beb286cacc0966b433a
That's a simplified version of some cases of mine where several complex
procedures that look very much alike, so I'd really
11 matches
Mail list logo
