[racket] Futures and shared data structure

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Dec 20 14:16:36 EST 2010

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
<robby at eecs.northwestern.edu> wrote:
> Oh. You have the touch first. Try putting it second.
>
> Robby
>
> On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani <ebellani at gmail.com> 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
>> 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 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 4999304 bytes; 614508 collected in 16 msec
>> GC [minor] at 8337384 bytes; 1957728 collected in 20 msec
>> GC [minor] at 10529324 bytes; 1709172 collected in 24 msec
>> GC [minor] at 14245196 bytes; 2815768 collected in 28 msec
>> GC [minor] at 19109972 bytes; 4515808 collected in 48 msec
>> GC [minor] at 20287336 bytes; 4153060 collected in 32 msec
>> GC [minor] at 416134292 bytes; -27108 collected in 1652 msec
>> cpu time: 2660 real time: 2657 gc time: 1652
>> cpu time: 1000 real time: 1001 gc time: 0
>> 2 success(es) 0 failure(s) 0 error(s) 2 test(s) run
>> 0
>>
>> Which for me is not helpful. Any more suggestions?
>>
>>
>> On 12/20/2010 04:54 PM, Robby Findler wrote:
>>> 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 this if you haven't yet:
>>>
>>>   http://docs.racket-lang.org/guide/performance.html#%28part._effective-futures%29
>>>
>>> Robby
>>>
>>> On Mon, Dec 20, 2010 at 12:47 PM, Eduardo Bellani <ebellani at gmail.com> wrote:
>>>> Hello all
>>>>
>>>> I am trying to understand futures, and I have generated to following
>>>> code to see how I would create reader futures. Unfortunately my futures
>>>> are not running in parallel and are taking more time that the serial
>>>> version. Besides that it seems to capture the vector in a way that it
>>>> becomes noncollectable by the GC.
>>>>
>>>> Could anyone give some hints as to why? (my version is "5.0.2" on Linux)
>>>>
>>>> #lang racket
>>>>
>>>> (require racket/future rackunit rackunit/text-ui)
>>>>
>>>> (define DATA (make-vector 99999999 'datum))
>>>>
>>>> (define-test-suite read-from-shared
>>>>  (test-suite "with futures"
>>>>              (check-equal?
>>>>               (time (let ([f (future (λ _ (read-data DATA)))])
>>>>                       (touch f)
>>>>                       (read-data DATA)))
>>>>               (void)))
>>>>
>>>>  (test-suite "no futures"
>>>>              (check-equal?
>>>>               (time (read-data DATA)
>>>>                     (read-data DATA))
>>>>               (void))))
>>>>
>>>> (define (read-data some-data)
>>>>  (for ([i (in-vector some-data)]) i))
>>>>
>>>> (run-tests read-from-shared)
>>>>
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> Eduardo Bellani
>>>>
>>>> omnia mutantur, nihil interit.
>>>> _________________________________________________
>>>>  For list-related administrative tasks:
>>>>  http://lists.racket-lang.org/listinfo/users
>>
>>
>> --
>> Eduardo Bellani
>>
>> omnia mutantur, nihil interit.
>>
>


Posted on the users mailing list.