patch: allow construction of uninitialized vectors

[GoogleCodeExporter]

Problem: it's so common to have device_vector<>s filled in by kernels that it's 
a waste of time to initialize the vector with default values and send them to 
the device. Even if the initialization were done on the device it is still a 
waste of bandwidth.

This patch creates an additional constructor, where you pass in a 
device_vector<>::uninit argument; the vector elements will not be initialized, 
so you are supposed to either use it with POD types, or use the placement new 
construction.

host_vector<> gets the same constructor just for consistency reasons, although 
on the host you could just reserve+push_back to achieve the same thing.

Apply with `patch -p1 < uninit.patch'.

Original issue reported on code.google.com by dkosmari on 20 Jul 2010 at 9:36

• Merged into: #216

Attachments:

• uninit.patch

[GoogleCodeExporter]

Thanks for submitting this patch.  We've decided not to implement the proposed 
functionality because it is non-standard and there exist alternatives such as 
bare calls to device_malloc [1] and cusp::array1d [2] which is uninitialized.  
Moreover, in a future version of the library it will become more convenient to 
use wrapped device_ptrs from device_malloc with a vector-like interface [3].

[1] 
http://thrust.googlecode.com/svn/tags/1.2.0/doc/html/group__allocation__function
s.html#g53081c2b134f091a080c976a1cbaf8cd
[2] 
http://cusp-library.googlecode.com/svn/tags/0.1.0/doc/html/array1d_8h-source.htm
l
[3] 
http://code.google.com/r/jaredhoberock-thrust-range/source/browse/thrust/range/i
terator_range.h

Original comment by jaredhoberock on 31 Aug 2010 at 6:48

• Changed state: WontFix

[GoogleCodeExporter]

On the non-standard argument, I think it's bogus. thrust should be familiar for 
programmers experienced with the STL, but it already diverges a lot in many 
ways.

This is a basic functionality that most thrust programs can benefit from. 
Making it available in the simplest form possible seems logical. Would the 
propose vector-like interface provide automatic memory management? How would 
the code using iterator_range look like?

Original comment by dkosmari on 31 Aug 2010 at 8:23

[GoogleCodeExporter]

Original comment by jaredhoberock on 7 Oct 2010 at 4:37

• Changed state: Duplicate