3 ms·
This is a very bold statement. IO-bound means that the bottleneck is at IO. GPU has little benefit in IO. Also, mapreduce is not embarrassingly parallel. Out o
by nemonemo 13y ago
This is a very bold statement. IO-bound means that the bottleneck is at IO. GPU has little benefit in IO.
Also, mapreduce is not embarrassingly parallel. Out of mapreduce, map is the only embarrassingly parallel phase. It has input parsing, shuffle, reduction phases that are not embarrassingly parallel.
- Hydraulix989 13y agoI should clarify -- initially I/O bound, but with pipelining, we are able to "impedance match" the flow of data coming off the backing store with the GPU's computational progress. I suppose the better word is "I/O heavy," rather than "I/O bound." We're certainly not the first to describe mapreduce as "embarrassingly parallel," but I can defend myself nonetheless: A shuffle executes in parallel where each unit re-indexes into another unit. Reduction is parallelized over each key, and even finer granularity can be achieved by considering a tree-based approach: http://developer.download.nvidia.com/compute/cuda/1.1-Beta/x86_website/projects/reduction/doc/reduction.pdf http://developer.download.nvidia.com/compute/cuda/1.1-Beta/x... In fact, I used this tree reduction approach to merge non-disjoint clusters of friend groups in my social network clustering algorithm. Parallelizing the input parsing is problem-specific, but even that is possible in many cases.