5 ms·
I liked the way the content is presented. I had Parallel Computing as one of my elective this semester, and the subject isn't kool any more when you dive into
by l0nwlf 16y ago
I liked the way the content is presented. I had Parallel Computing as one of my elective this semester, and the subject isn't kool any more when you dive into it. Parallel Computing is tough IMHO and it takes some brainstorming to solve even the basic problems like computing prime numbers or sparse matrix multiplication.
Also we use OpenCL, which itself is quite a complicated deal. ( TBB, OpenMP are simpler ). The tutorial makes the basics clear as well as the post have an aesthetic feel to it. All in all - a nice read.
- Untitled 16y agoStupid question (I know embarrassingly little about GPGPU programming). Is OpenCL mostly used with ATI cards? How common is OpenCL? It seems to me that almost everyone is using CUDA. Also, isn't copying everything to the GPGPU memory and then performing tasks there (and when it is completed copying it to main memory) a bit stupid? What happens in a cluster setup when two or more hosts work on the same dataset? Won't this result in a needless amount of copying? Double memory requirements?
- eliben 16y agoOpenCL is different from CUDA in two important points: 1) OpenCL is an industry standard supported by many vendors (although not all support it fully currently, since it's a relatively new standard). OTOH, CUDA is a proprietary system developed by NVIDIA for its GPUs. CUDA is much more mature since it has been in use for quite some time now. 2) While CUDA addresses GPUs, the aim of OpenCL is more general. It's a "heterogeneous" language/platform, aimed by design at various computing devices: CPUs, GPUs, special CPUs like Cell, accelerators (FPGA, etc.), DSPs and so on
- phamilton 16y agoCUDA actually is open, but ATI chooses not to implement CUDA support in their drivers.
- nivertech 16y agoAPIs sorted by complexity (from most hard to learn to easier to learn): * OpenCL / CUDA * Pthreads * MPI * TBB * OpenMP
- scott_s 16y agoI consider message passing programs harder to learn and develop scalable applications for than shared memory. While the errors in a shared memory program (this includes Pthreads, TBB, OpenMP - any programming model that uses multithreading in a shared address space) can be more subtle, you don't have to have as deep an understanding of the runtime behavior of your algorithms. It's easier to rely on shared memory in hardware than to use explicit send/receive on all of your data.
- nivertech 16y agoI disagree, in MPI you don't deal with locks and race conditions. It's like saying, that Erlang programming is harder than multi-threading in C/C++. I'll take Erlang over Pthreads any day. MPI applications can be a little bit harder algorithmically, but a concept of Collective Communications (i.e. send/recv/scatter/gather/bcast/reduce) is easier to understand than threading and locking. The whole concept of Shared/Distributed memory models doesn't mutter in this case.
- scott_s 16y agoThere's two issues: debugging and scaling. I agree that multithreading at the Pthread level is harder to debug. But I think it's easier to design a program that will scale using Pthreads than MPI because with one you rely on the hardware to distribute data, and with the other you have to do all of that yourself.
- nivertech 16y agoAccording to this logic MPI for Shared Memory will be easier to understand than OpenMP for clusters.