UIKit0 / thrust

Automatically exported from code.google.com/p/thrust
Apache License 2.0
0 stars 0 forks source link

Host copy broken with std::vector and gcc 4.3 / 4.4 ? #185

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Please post a short code sample which reproduces the problem:

    int n = 10;
    std::vector<double> y(n);
    double c[n];
    thrust::copy(c,c+n,y.begin());

What is the expected output? What do you see instead?

y gets filled with the values of c. Instead complier error

/thrust/thrust/detail/host/dispatch/copy.h(60): error: no suitable constructor 
exists to convert from "double *" to "__gnu_cxx::__normal_iterator<double *, 
std::vector<double, std::allocator<double>>>"

If you change the last line to &y[0] it works again. If y is a 
thrust::device_vector<double> instead then y.begin() does also work.

What version of Thrust are you using? Which version of nvcc?  Which host
compiler?  On what operating system?

I'm using the developing branch, problem does not exist with thrust 1.2.1. I'm 
running Linux nvcc 3.1 with gcc 4.3.4 / 4.4.3.

Please provide any additional information below.

I think this problem is related to revision 22bf391b56. I do also think that 
there are some more related problems (posted it on issue 174).

Original issue reported on code.google.com by janick.m...@gmail.com on 28 Jul 2010 at 9:35

GoogleCodeExporter commented 9 years ago
So the problem can be avoided by using thrust::host_vector instead of 
std::vector in most cases.

However, the related problem I posted in 174 does still remain, so I give an 
example for this problem related to "ordinary host pointers", so for example

thrust::scatter(mx.begin(), mx.end(), mapping_roi_local_globalD.begin(), ptr + 
offset);

with mx and mapping_roi_local_globalD beeing device_vectors and ptr a "raw" 
host vector does not compile with error 

thrust/thrust/iterator/detail/minimum_space.h(86): error: incomplete type is 
not allowed
          detected during:
            instantiation of class "thrust::detail::minimum_space_impl<false, false>::apply<T1, T2> [with T1=thrust::host_space_tag, T2=thrust::detail::cuda_device_space_tag]"

So in this case I don't have the data structure ptr is pointing to and I don't 
know how to wrap it in a way that the scatter works. This code compiles and 
works with thrust 1.2.1, however...

Original comment by janick.m...@gmail.com on 28 Jul 2010 at 12:17

GoogleCodeExporter commented 9 years ago
Thanks for reporting this bug in copy, I can reproduce it.

The issues with scatter & gather are not bugs.  We recently made scatter & 
gather more strict: they require their arguments to reside in the same space.  
To fix the issue in your code, copy mx & mapping_roi_local_globalD to temporary 
host_vectors and then perform the scatter entirely on the host.  This is what 
the old implementation would have done, so you shouldn't give up any 
performance.

Original comment by jaredhoberock on 29 Jul 2010 at 3:16

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 0c5880df84.

Original comment by jaredhoberock on 29 Jul 2010 at 3:24

GoogleCodeExporter commented 9 years ago
Thank you very much for resolving that bug, now everything works fine again.
What was the reason for making gather/scatter more restrictive? It now works on 
my side again but now I need to switch on different implementations depending 
on which memory space the iterators are pointing on, this wasn't necessary 
before. Perhaps I will then just write my own adaptions, or are there some 
sewer performance drawbacks despite required additional memory allocations? 

Original comment by janick.m...@gmail.com on 29 Jul 2010 at 1:37

GoogleCodeExporter commented 9 years ago
The reason scatter & gather were changed was because they were the only 
algorithms besides copy that work across space, and there was no justification 
for allowing the exception.  Furthermore, there's no optimization we could 
perform to accelerate cross-space scatters & gathers, and the functionality 
complicated their implementations.  Now, both algorithms have a simple 
implementation which is a single to call copy plus a permutation_iterator.

Original comment by jaredhoberock on 30 Jul 2010 at 1:19

GoogleCodeExporter commented 9 years ago

Original comment by wnbell on 6 Feb 2011 at 6:45