General- What is Thrust?
- Thrust is a C++ template library for CUDA. Thrust allows you to program GPUs using an interface similar the C++ Standard Template Library (STL).
- What is a C++ template library?
- C++ templates are a way to write generic algorithms and data structures. A template library is simply a cohesive collection of such algorithms and data structures in a single package.
- How can I contribute to Thrust?
- There are many ways! Please refer to Contributing for some ideas.
- How do I cite Thrust in papers and other publications?
- Please refer to the page on Citing.
- Do I need to build Thrust?
- No. Since Thrust is a template library you just #include the appropriate header files into your .cu file and compile with nvcc.
- What data structures does Thrust provide?
- Currently Thrust provides thrust::host_vector and thrust::device_vector, which are analogous to std::vector in the STL and reside in the host/device memory. These vector data structures simplify memory management and transferring data between the host and device.
- What algorithms does Thrust provide?
- sorting: thrust::sort and thrust::sort_by_key
- tranformations: thrust::transform
- reductions: thrust::reduce and thrust::transform_reduce
- scans: thrust::inclusive_scan, thrust::exclusive_scan, thrust::transform_inclusive_scan, etc.
- Refer to Documentation for a complete listing
- What version of CUDA do I need to develop applications with Thrust?
- What platforms does Thrust support?
- Thrust has been tested extensively on the following platforms
- Ubuntu Linux 8.10 and 9.04 (32-bit/64-bit) with GCC 4.2 and 4.3
- Windows Vista (32-bit) with Visual Studio 2008 Express
- Windows XP with Visual Studio 2005
- Mac OSX 10.6 (Snow Leopard) with GCC 4.2
- When will Thrust support OpenCL?
- The primary barrier to OpenCL support is the lack of an OpenCL compiler and runtime with support for C++ templates (e.g. something similar to nvcc and the CUDA Runtime). These features are necessary to achieve close coupling of the host and device codes.
- Does Thrust depend on any other libraries?
- No, Thrust is self-contained and requires no additional libraries.
- Can I distribute Thrust with my application?
- Yes! Thrust is open-source software released under liberal licensing terms.
- What open-source license does Thrust use?
- How is Thrust different from Komrade?
- Komrade was the initial release of this library. All new development will proceed under this new title & project.
- How do I run the unit tests and performance tests for Thrust?
Functionality- How do I find the array index of the element with the maximum/minumum value?
- Use thrust::max_element() or thrust::min_element(), which are found in the file <thrust/extrema.h> [more info].
- How do I obtain a raw pointer (e.g. int * ptr) from a device_vector?
- Use thrust::raw_pointer_cast(&my_vector[0]) [example].
Troubleshooting- Make sure you are using CUDA 2.2 or greater:
- Make sure you're compiling files that #include Thrust with nvcc.
- Make sure that files that #include Thrust have a .cu extension. Other extensions (e.g..cpp) will cause nvcc to treat the file incorrectly and produce an error message.
- If all else fails, send a message to thrust-users and we'll do our best to assist you.
|
Sign in to add a comment
How is thrust different from komrade?
Thrust is version 1.0 of Komrade. All new development will proceed under this new title & project. Please check the CHANGELOG for a comprehensive list of changes.
Will we see a version of Thrust on OpenCL?
how about mentioning some of the practical uses for this thing, and maybe why you'd want to use it
if the hardware that supports CUDA isn't on a computer, can the thrust library fall back to normal processing through the cpu?
I would like to build the built-in correctness and performance tests in thrust. Could someone provide instructions on how to do this?
@ gregory
We've added a FAQ entry and a DeveloperInfo page.
How about OpenGL interoperability?
Are there any plans to offer pinned memory in the host vector?
@ eric
Yes, we've considered allocating pinned memory for host_vector. It's a possibility. However, the argument against it is that pinned memory wouldn't necessarily be portable to other backends (e.g., OpenMP, OpenCL, etc.).
Is it possible that we could have the ability to choose more than the default device 0?
I have two Teslas, and I would like to use Thrust, but I need to be able to distribute the workload.
@ jaredkeithwhite
If you call cudaSetDevice() before calling any Thrust functions or creating any device_vectors you should be able to change the target device. I haven't tested multigpu setups with Thrust yet, but it should act like any other program that uses the CUDA runtime-api.
@wnbell,
Perhaps I'll write a few additional components for thrust that provides device iteration capabilities, along with the ability to set the current device.
I'll submit whatever I come up with back to the group. One potential pitfall I can see with just calling "cudaSetDevice" is that occasionally some of the functions use thrust::device::arch::max_threads_per_block(), etc, which are only correct for device 0. On a homogenous device setup, that works fine -- but in multi-card setups that are heterogeneous, those are incorrect assumptions. So I think that thrust::device::arch will have to be modified at some point.
-Jared
@jaredhoberock,
Perhaps we could modify the vectors to accept an allocator? The user could then typedef their own vectors that use it. I'm seeing in my head:
typedef device_vector<cuda_host_pinned_memory_allocator> pinned_device_vector;
etc.
@jaredkeithwhite
Re: pinned memory Yes, a pinned allocator would probably do it. More generally I've thought we should provide host_malloc & host_new as duals to device_malloc/device_new.
Re: cudaSetDevice My understanding is that the current functionality of cudaSetDevice is not quite suited to our needs, because we can't call it arbitrarily. It must be the first cuda API entry point a thread calls, or it will fail. And yes, the stuff in the arch namespace is experimental & needs work.
Another issue with providing multi-device versions of device_vector is that it's not clear we can provide multi-device implementations of all of thrust's entry points. In particular, gather & scatter might be impossible.
If you'd like to continue discussions on these or any other proposals, please join us on the thrust-users mailing list.
What is the most efficient way to convert a Thrust::device_vector to a std::list?
@xb.ning
I think the most efficient way to convert to a list from a device_vector would be to use host_vector (or std::vector) as intermediate storage:
thrust::device_vector<T> d_vec; ... // do a single device to host copy thrust::host_vector<T> h_vec = d_vec; // construct std::list from a range on the host std::list<T> list(h_vec.begin(), h_vec.end());
hello everyone,I am very interested in using thrust to improve performance, but it seemed that i have trouble in integrating thrust with visual studio 2008 (64bit vista). I compile thrust as the instruction told me, but there always pop up many error information, some are grammatial others linking problem. Can any one please told me how to use it(in vs2008 64bit os)? thanks alot!
@yingdq
If you post the compiler output to thrust-users(1) we can provide some additional assistance.
(1)http://groups.google.com/group/thrust-users