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
