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