So there are these things called "futures" and "places", of which I gather the former are easier to use, but the latter, by being more constrained, take better advantage of parallel hardware. I haven't tried working with either of them yet, but I wanted to ask how feasible the following is.
The "map-image" and "build-image" functions in the picturing-programs collection both construct an image pixel by pixel, using a "for" loop of which each iteration determines the color of a different pixel. It's a perfect application for parallelism, as the iterations neither depend on one another nor mutate the same memory location. If only there were a really easy way to parallelize it... My ideal interface would be a "for/parallel" form that executes the "for" body conceptually in parallel for each possible values of the loop variables. Even friendlier would be for the existing "for" forms to do that automatically until something order-dependent happens... but that seems very difficult to detect. By using "for/parallel", I would be promising the compiler that (a) no iteration of the for-loop depends on results computed by any other iteration of the for-loop, and (b) different iterations of the for-loop either don't mutate any of the same memory locations, or if they do, I don't care which one gets there first. A related question: has anybody written a Racket interface to make use of CUDA GPU's? Stephen Bloch [email protected] _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
