This is almost certainly nuts. The latency to and from GPUs is awful. I've been hacking GPGPU since before CUDA existed (worked with an early beta of CUDA and

This is almost certainly nuts. The latency to and from GPUs is awful. I've been hacking GPGPU since before CUDA existed (worked with an early beta of CUDA and the GTX 8800). You can do some great throughput-oriented stuff there, but the latency issues meant that GPUs were useless for small-to-medium tasks. It's partly an issue of latency and also an issue of getting 'enough data to make parallelism useful' - we had a pattern matching task that hit peak throughput at about 16K threads which required, of course, a big pile of data. Things may have improved in terms of latency since then, but we're talking multiple orders of magnitude off (back then) for network processing tasks, much less kernel tasks. And the issue of needing 'big piles of data' to work over isn't going away. This is algorithm-dependent, of course, but lots of data is the easy way to find data-parallelism. :-) Most of the papers published about GPGPU are either larger data sizes (where GPGPU is a legitimate tactic) or do some really serious handwaving concerning latency (e.g. the GPU routing stuff, 'packetshader'). Just because there are a bunch of people who can get interesting papers out of it doesn't mean it's a good idea.