

STL on the GPU with Thrust - BudVVeezer
http://code.google.com/p/thrust/

======
sehugg
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.

------
spitfire
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.

~~~
Retric
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.

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

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

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

------
wccrawford
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?

