3 ms·
Our experience with GPU cloud computing at Graphistry should be pretty representative. We spend a lot of effort getting subsecond interactivity in funny C diale
by lmeyerov 12y ago
Our experience with GPU cloud computing at Graphistry should be pretty representative. We spend a lot of effort getting subsecond interactivity in funny C dialects (OpenCL/CUDA). To get those down further, we can put together a few GPUs and reuse most of the code. Eventually, however, data communication costs get too high, so FPGAs would be the next step. That is certainly doable: OpenCL -> FPGA compilers are a thing!
So the question is who has already been going down that pathway, and I'll leave that as an exercise to the reader :) My guess: that'll stay in private hands for awhile, and after a few years, as FPGAs get put into public clouds and everyone goes down the same pathway, a lot of people will be using FPGAs, even if indirectly.
- aprdm 12y agoWith OpenCL + FPGA what you do is basically instantiate a GPU architecture inside an FPGA and then execute the OpenCL algorithm into that. I think that's cool but you aren't getting a better throughput than what you would get with a GPU. The better solution would be to do your custom optimised control/data path for the FPGA architecture you are currently using (VHDL/Verilog).
- DrHoppenheimer 12y agoThat's not how it works, actually. The compiler generates the dataflow directly in hardware.
- frozenport 12y ago>>Eventually, however, data communication costs get too high Looks like the program is spending too much time in 'MPI_RECV'? Clearly the same time would be spent by any other hardware device, and raw compute power wont fix this. You need a faster interconnect. Indeed, among the few fixes for this problem are complicated changes to the algorithm, such a maintaining some kind of network routing scheme, which often involves complicated logic difficult to implement on anything but a CPU.