[racket] Futures and shared data structure

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 as the serial
version. Any more rabbits out of that hat? :)

Thanks for the attention.

I'll remember about collect-garbage.

On 12/20/2010 05:16 PM, Robby Findler wrote:
> 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.
>>>
>>


-- 
Eduardo Bellani

omnia mutantur, nihil interit.