Skip to main content
Computational Science

Return to Question

fixed typo and link formatting, added cuda tag
Source Link
edit approved Apr 30, 2017 at 20:08
Jakub Klinkovský
edit approved Apr 30, 2017 at 20:08
Jakub Klinkovský
  • 442
  • 3
  • 22

I'm very new to GPGPU programming so please forgive me if the question is not particularly appropriate. From what I understand GPU programming is a very intricate piece of engineering work when compared to usual CUPCPU programming. One has to be very careful about divergence issues, tiling, pinned memory allocation, and host-device communication/device computation overlapping.

After doing a little bit of research I found the thrust library (https://code.google.com/p/thrust/ library) which seems to try to mimic C++ STL. This is quite nice. However, based on my very limited experience and having seen all the micro-managing required to get good performance, I'm a little bit skeptical about the performance. Can thrust efficiently handle all the intricate programming part internally? Some very well-known libraries, such as PETSc, seem to use this package which makes me believe it somehow should.

I was wondering if people with more experience on CUDA and thrust could say a word or two about the performance of the package when compared to the low level CUDA programming. When can I use thrust and when should I switch back to CUDA?

I'm very new to GPGPU programming so please forgive me if the question is not particularly appropriate. From what I understand GPU programming is a very intricate piece of engineering work when compared to usual CUP programming. One has be very careful about divergence issues, tiling, pinned memory allocation, and host-device communication/device computation overlapping.

After doing a little bit of research I found the thrust library (https://code.google.com/p/thrust/) which seems to try to mimic C++ STL. This is quite nice. However, based on my very limited experience and having seen all the micro-managing required to get good performance, I'm a little bit skeptical about the performance. Can thrust efficiently handle all the intricate programming part internally? Some very well-known libraries, such as PETSc, seem to use this package which makes me believe it somehow should.

I was wondering if people with more experience on CUDA and thrust could say a word or two about the performance of the package when compared to the low level CUDA programming. When can I use thrust and when should I switch back to CUDA?

I'm very new to GPGPU programming so please forgive me if the question is not particularly appropriate. From what I understand GPU programming is a very intricate piece of engineering work when compared to usual CPU programming. One has to be very careful about divergence issues, tiling, pinned memory allocation, and host-device communication/device computation overlapping.

After doing a little bit of research I found the thrust library which seems to try to mimic C++ STL. This is quite nice. However, based on my very limited experience and having seen all the micro-managing required to get good performance, I'm a little bit skeptical about the performance. Can thrust efficiently handle all the intricate programming part internally? Some very well-known libraries, such as PETSc, seem to use this package which makes me believe it somehow should.

I was wondering if people with more experience on CUDA and thrust could say a word or two about the performance of the package when compared to the low level CUDA programming. When can I use thrust and when should I switch back to CUDA?

Tweeted twitter.com/#!/StackSciComp/status/224271273675599872
Source Link
mmirzadeh
mmirzadeh
  • 1.4k
  • 1
  • 10
  • 17

Thrust for GPU programming

I'm very new to GPGPU programming so please forgive me if the question is not particularly appropriate. From what I understand GPU programming is a very intricate piece of engineering work when compared to usual CUP programming. One has be very careful about divergence issues, tiling, pinned memory allocation, and host-device communication/device computation overlapping.

After doing a little bit of research I found the thrust library (https://code.google.com/p/thrust/) which seems to try to mimic C++ STL. This is quite nice. However, based on my very limited experience and having seen all the micro-managing required to get good performance, I'm a little bit skeptical about the performance. Can thrust efficiently handle all the intricate programming part internally? Some very well-known libraries, such as PETSc, seem to use this package which makes me believe it somehow should.

I was wondering if people with more experience on CUDA and thrust could say a word or two about the performance of the package when compared to the low level CUDA programming. When can I use thrust and when should I switch back to CUDA?