Oh, probably you can recover that by judicious use of the unsafe
primitives (unsafe-fx+ and unsafe-fx= for example). The for macro is
not doing anything you can't do yourself, fwiw. (Also, fwiw, unless
you have a simple loop body, it probably won't matter too much
anyways.)
Robby
On Mon, Dec 20,
Thanks for all the attention Robby, and I am glad that I could help find
some improvement space.
The sad part is that for the new loop there is an increase of about 100%
in the processing time, I guess it is because of the efficiency provided
by the in-vector inside the for.
Cool list, as usual.
At Mon, 20 Dec 2010 16:17:38 -0600, Robby Findler wrote:
> I don't think your changes had anything to do with the "doens't look
> very good". But since you asked, if you look at the fully expanded
> version of
>
> (λ (v) (for ([x (in-vector v)]) x))
>
> you'll see it begins like this:
>
>
On Mon, Dec 20, 2010 at 3:56 PM, Noel Welsh wrote:
> On Mon, Dec 20, 2010 at 9:51 PM, Robby Findler
> wrote:
>> The expanded code doens't look very good, imo, tho, so perhaps whoever
>> recently was working on this can clean this part up too.
>
> I have a name ;-P Perhaps you could elaborate on
On Mon, Dec 20, 2010 at 9:51 PM, Robby Findler
wrote:
> The expanded code doens't look very good, imo, tho, so perhaps whoever
> recently was working on this can clean this part up too.
I have a name ;-P Perhaps you could elaborate on "doesn't look very
good". I spent a little bit of time optimi
On Mon, Dec 20, 2010 at 3:48 PM, Robby Findler
wrote:
> and, sure enough, looking at the expansion of the loop:
>
> (for ([i (in-vector some-data)]) i)
>
> I see that it uses multiple values which, I believe are not safe for futures.
>
> I believe that this is a recent change and hopefully whoeve
On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani wrote:
> My output to your suggested approach is
>
> GC [minor] at 1514740 bytes; 818464 collected in 4 msec
> GC [minor] at 2142928 bytes; 678980 collected in 4 msec
> GC [minor] at 4424700 bytes; 1509104 collected in 12 msec
> GC [minor] at 499930
Changing the suite to
(test-suite "with futures"
(check-equal?
(time (let ([f (future (λ _ (read-data DATA)))])
(read-data DATA)
(touch f)))
(void)))
Did no help it very much, I still get the same results a
And as a general rule of thumb, you should call collect-garbage
(perhaps a few times) before running anything you wish to time in
order to be sure that the gc time is being correctly attributed.
Robby
On Mon, Dec 20, 2010 at 1:12 PM, Robby Findler
wrote:
> Oh. You have the touch first. Try putti
Oh. You have the touch first. Try putting it second.
Robby
On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani wrote:
> Thanks for the prompt reply.
>
> Disregard the noncollectable thing, that was a confusion on my side.
> Still, my doubt remains about why my futures version is slower and not
> pa
Thanks for the prompt reply.
Disregard the noncollectable thing, that was a confusion on my side.
Still, my doubt remains about why my futures version is slower and not
parallel. I did read about the futures, but alas, I'm still in the dark
as to why it is behaving like it is.
My output to your s
I'm not sure about the uncollectable issue, but for the rest, try
running in racket, enabling the debug log. Eg, if you save the file in
x.rkt and do this:
racket -W debug x.rkt
then you should see some messages telling you what is causing your
future to get stuck.
Also, do be sure to read thi
12 matches
Mail list logo
