3 ms·
All points touched in the article are valid. However, calculating sine of 100M numbers is simple but not very representative case for GPGPU programs. Leaving da
by mynegation 15y ago
All points touched in the article are valid. However, calculating sine of 100M numbers is simple but not very representative case for GPGPU programs. Leaving data in GPU memory as long as possible between kernel invocations and avoiding transfers is one of the first optimizations that must be considered.
- profquail 15y agoHis points may be valid (that some people cut corners to get the best numbers for their papers); however, as someone who spends a lot of time writing GPGPU code[1], I'll point out that MATLAB isn't the best way to benchmark GPU-based code. I'm not knocking MATLAB here, but simply pointing out that MATLAB is going to have overhead compared to, say, CUDA. Given that most GPGPU kernels run pretty quickly (less than a second, and probably under 100ms) even a little bit of overhead is going to severely affect your results. [1] See my profile.
- daeken 15y ago> Leaving data in GPU memory as long as possible between kernel invocations and avoiding transfers is one of the first optimizations that must be considered. The absolute biggest bottleneck when doing anything with the GPU is the cost of transferring between the CPU and GPU. Thus, the more you do on the GPU at a time, the better off you are. Obviously, there are many things to optimize on the GPU side (e.g. taking advantage of locality), but if you just keep in mind that the more you do, the faster things are, you're going to be in a good place.