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
> <ro...@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 <ebell...@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 <ebell...@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.
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
