Oh, probably you can recover that by judicious use of the unsafe primitives (unsafe-fx+ and unsafe-fx= for example). The for macro is not doing anything you can't do yourself, fwiw. (Also, fwiw, unless you have a simple loop body, it probably won't matter too much anyways.)
Robby On Mon, Dec 20, 2010 at 7:23 PM, Eduardo Bellani <[email protected]> wrote: > Thanks for all the attention Robby, and I am glad that I could help find > some improvement space. > > The sad part is that for the new loop there is an increase of about 100% > in the processing time, I guess it is because of the efficiency provided > by the in-vector inside the for. > > Cool list, as usual. > > On 12/20/2010 07:48 PM, Robby Findler wrote: >> On Mon, Dec 20, 2010 at 1:02 PM, Eduardo Bellani <[email protected]> wrote: >>> 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? >> >> I get the following line of output (in the development version): >> >> future: 0 waiting for runtime at 1292881244093.291016: values >> >> and, sure enough, looking at the expansion of the loop: >> >> (for ([i (in-vector some-data)]) i) >> >> I see that it uses multiple values which, I believe are not safe for futures. >> >> I believe that this is a recent change and hopefully whoever did it >> will fix it (I'll post separately about this). But in the meantime, >> the program below produces these two 'time' lines for me: >> >> cpu time: 1586 real time: 845 gc time: 0 >> cpu time: 1596 real time: 1595 gc time: 0 >> >> which indicates that the two loops happened in parallel in the first >> case and not in the second. >> >> Robby >> >> #lang racket >> >> (require racket/future >> rackunit >> rackunit/text-ui >> racket/fixnum) >> >> (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)))]) >> (read-data DATA) >> (touch f))) >> (void))) >> >> (test-suite "no futures" >> (check-equal? >> (time (read-data DATA) >> (read-data DATA)) >> (void)))) >> >> (define (read-data some-data) >> (let ([end (vector-length some-data)]) >> (let loop ([i 0]) >> (unless (fx= i end) >> (vector-ref some-data i) >> (loop (fx+ i 1)))))) >> >> (collect-garbage) (collect-garbage) >> (run-tests read-from-shared) > > > -- > Eduardo Bellani > > omnia mutantur, nihil interit. > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
