yeah this is a rather dunce question, but i just started wondering a little while back. Servers need to communicate with a LOT of people, which generally means lots of threads handling the instructions being sent out to the various people (especially in the case of online games or very complex sites)
I just wondered, considering the number of threads you can have using a CUDA program, would it not be possible to make a bloody powerful server using a cuda webserver software?
I’ve also been wondering if anyone would bother trying to build a linux distro based on CUDA, but i’ll ignore that for now. I highly doubt i could even get close to making a half decent webserver myself if this were feasable (at least for a long time, i’m not the most amazing of programmers >.> and i don’t know C… Either way i just wanted to know if such a thing would be worthwhile, if it is perhaps i’ll give it a go in a year or so if nobody else has :P
Either that or somebody can spend the next year or so translating the C code from apache into code which’d make the most of CUDA
I’m not an expert (yet), but I think Akg is right.
The GPU is meant to work up ‘simple’ instructions, i.e. permanently repeating calculations.
In contrast to the CPU the GPU has hardly (L1) cache, so if there come a lot of different instructions one by another,
there’s a high memory latency, what is not the case for the CPU (as the memory is cached).
You can expect that a webserver has to work on ‘chaotic’ code with many different instructions, so you
won’t get good performance by using a GPU.
thats explained a bit clearer for me thanks. I was basing the idea purely on the high thread count for something like web based games / high spec server requirements, especially when it gets to a point of 2000 + people all altering a database or something,
Not really what you’re thinking of…but I suppose you could set up a web-based system where users could upload datasets and kernels and remotely run them on a server that has some CUDA-based devices in it. The trick though, would be how to ensure that your users can’t see each others code. Also, the ‘bandwidth’ (client->server->cuda-device->server->client) would be pretty terrible, so this would only be useful for computationally-intense code.
this seems more like some kind of high level SVN running off an intranet. Although that’d also be an interesting concept. either way i’m focusing entirely on theory so this is all a learning process for me.
Many people handle this kind of usage pattern now with UNIX shell accounts and batch queue systems, like Sun Grid Engine. It’s a fairly standard way to share large compute farms among many users. (Or small compute farms: I use SGE for distributing jobs over my two quad-core computers.)
You cannot make system calls or library calls from your GPU code. It does NOT even have a strong concept of functions.
What you are thinking MIGHT be possible with Larrabee. I vaguely remember they saying that they will have a micro-kernel running inside their GPU that would actually help GPU code to make system calls, library calls etc… Not 100% sure if that made it to the final specification. Lazy to read it :)
There’s truth buried in those words, but there’s also a lot of things that are false.
As Sarnath pointed out, the main problem is making system calls (anything that needs to talk to the OS/drivers, like file access, networking, etc.). Larrabee may make this a lot easier (it’s almost impossible to do from CUDA), but it’ll still face the problem of sitting across from the CPU on a high-latency PCIe bus. Larrabee might also slow down less from divergence, and it has a data cache.