STL on the GPU with Thrust | Hacker News Reader

STL on the GPU with Thrust

code.google.com

47 pointsBudVVeezer8 comments

Not to be "that guy" .. but the headline is a little misleading; the library has similarities in syntax with STL but it is not a replacement.

I've been waiting to see something like this for a while. Expect more of this sort of thing in the future. openCL seems a bit wordy to me. I won't be surprised if you lose a few % performance with this, but that's a decent tradeoff I think.

In the long term, expect the GPU to go away and be absorbed by the cpu. Just like the FPU used to be an add on chip, and was absorbed into the CPU, so will the GPU.

The real problem with combining the CPU and GPU really just comes down to memory issues. Paying for .5 to 1 GB of GDDR5 is no big deal, replacing 8-16GB of RAM with high speed GDDR5 costs more than most graphics cards without helping out the CPU. Adding a separate memory system seems like an easy solution, but CPU's are already pushing over 1000 pins to connect to a MB which are already fairly crowded etc.

PS: When CPU's can hold both a good GPU and enough cache to substitute for vram then Intel wins, until then having a separate GPU is a vary good idea. Because today the choice is either pay more or sacrifice 75% of the performance for about the same cost.

In addition to the problems mentioned by Retric, integrating the CPU and GPU into the same part prevents one from upgrading them independently.

Could be quite useful with Amazon's AWS Cluster GPU instances: http://aws.amazon.com/ec2/hpc-applications/

Quick question: why is transferring to the device done by assignment, while transferring back to the host done by a copy function?

Either form is permissible; I think the example is just meant to illustrate both options.

That's pretty nice. Does anyone know if it's smart enough to use the second GPU if you're using the primary one already, and if it'll use CPU as a last resort in case no GPUs are available?

Reply on news.ycombinator.com