thrust-users Google Group

thrust from github repository in nsight eclipse edition for linux?

ruscienc...@gmail.com (roman) — Thu, 23 May 2013 06:06:22 UT

Can somebody please explain me how to use different versions of thrust
from github repository on nsight eclipse edition for linux?

Re: [thrust-users] Sorting a 2d array of integers using Thrust

jaredhober...@gmail.com (Jared Hoberock) — Wed, 22 May 2013 21:56:18 UT

What precisely do you want to achieve? What do you mean by "sorting a
2d array of integers"?

It's difficult to give advice because it's not clear what you want.
You've given us an example of the input, but not an example of the
output.

Re: [thrust-users] sort_by_key memory requirement?

jaredhober...@gmail.com (Jared Hoberock) — Wed, 22 May 2013 21:44:36 UT

To accommodate zip_iterators, radix sort has to serialize into a
temporary. That's probably where the extra storage requirement is
coming from.

Merge sort's implementation has substantially improved recently and
doesn't have this overhead. My K20c wasn't able to successfully run
this example, but if you try the latest development version of Thrust

Re: [thrust-users] sort_by_key memory requirement?

crovel...@yahoo.com (Robert Crovella) — Wed, 22 May 2013 21:30:02 UT

Playing around with your code a bit, it does seem like thrust is actually needing about twice the originally allocated space as temporary storage. On a 6GB card, ECC on, with about 5.6GB available, things seem to work when the initial allocation is about 1.7GB but fail at about 1.8GB.

The actual number may be less than this due to fragmentation, but I don't think that's the biggest factor here.

dealing with bad_alloc

jaredhober...@gmail.com (Jared Hoberock) — Wed, 22 May 2013 21:07:42 UT

What do folks do when they encounter bad_alloc (besides emailing this list :) ?

Have people developed workaround schemes which try to gracefully forge
ahead (or fail), or is this generally a show-stopper?

If bad_alloc is usually a show-stopper, would folks object if
algorithms which would have failed before attempt to forge ahead at

Re: [thrust-users] sort_by_key memory requirement?

jaredhober...@gmail.com (Jared Hoberock) — Wed, 22 May 2013 21:03:10 UT

The system is reporting that there is not sufficient space. The sort
requires O(n) extra storage - the constant is unspecified. Moreover,
even if there is free space physically available, there's no guarantee
that the CUDA runtime can allocate a contiguous block large enough to
satisfy it.

As a workaround, you might try implementing a fallback allocator along

Re: [thrust-users] sort_by_key memory requirement?

fizban...@gmail.com (fizban007) — Wed, 22 May 2013 20:27:11 UT

Thanks for your explanation. The 2GB of memory used up is simply allocation
of the above mentioned array.
Still, with the array already allocated there is 3.6GB free space which
should be more than sufficient for the ~1.8GB O(n) temporary storage. But
thrust
does throw bad_alloc. ECC only makes the total available memory 5.6GB

Re: [thrust-users] Sorting a 2d array of integers using Thrust

kblues...@gmail.com (k1) — Wed, 22 May 2013 18:31:22 UT

I will try to send again my thoughts on this problem because it's very
important to me and I'm desperate for a solution.

I use a row store technique for my data, so if the user gives as an input
the array

1 2
2 3
4 3
3 3

I will store this data inside a host_vector<int> which after the 2d => 1d

Re: [thrust-users] Worning Global Memory

crovel...@yahoo.com (Robert Crovella) — Wed, 22 May 2013 16:49:47 UT

As a test, if you compile with -arch=sm_20 and the warning goes away, it can usually be safely ignored, even when your run your code compiled with the -arch=sm_13 switch.
This SO question may be of interest:
[link]

Worning Global Memory

teresa.pietrabi...@gmail.com (Teresa Pietrabissa) — Wed, 22 May 2013 10:03:10 UT

Hi Everyone,
I get a warning while compiling a code using thrust.
Warning: Cannot tell what pointer points to, assuming global memory space
I've looked around on the web to see if anyone could have had this kind of
wornings but couldn't understand the answears.
I'm using -arch=sm_13 architecture.
Does anyone knows why do I get this warning, and should I be concerned with

Re: [thrust-users] sort_by_key memory requirement?

crovel...@yahoo.com (Robert Crovella) — Tue, 21 May 2013 22:52:55 UT

sort by key may require up to O(n) temporary storage. In your case I count:
64M integers = 256MB
3x64M doubles = 1536MB
64M chars = 64MB or 256MB depending on how they get stored

Altogether you're at ~1.8GB and if you add the O(n) temporary storage you're at ~3.6GB which seems to exceed your 3.6GB available.

sort_by_key memory requirement?

fizban...@gmail.com (fizban007) — Tue, 21 May 2013 18:51:33 UT

I'm trying to run thrust::sort_by_key on some large key-value arrays.
Specifically my key array is 64M integers, while my values consist
of 3 arrays of 64M doubles and 1 array of 64M chars. I'm trying to put all
the values together into a zip_iterator and pass it to sort_by_key
but it throws thrust::bad_alloc on my Tesla C2075 which has 6GB memory. The

Re: [thrust-users] Setting Seed in Random Generator

crovel...@yahoo.com (Robert Crovella) — Tue, 21 May 2013 18:46:58 UT

When you were compiling the code below, a warning is thrown on this line:

rng.seed(m_seed);

The warning is:

...: warning: passing âfloatâ for argument 1 to âvoid thrust::random::linear_congrue ntial_engine<UIntType, a, c, m>::seed(UIntType) [with UIntType = unsigned int, UIntType a = 48271u, UIntType c = 0u, UIntType m = 2147483647u]â

Setting Seed in Random Generator

teresa.pietrabi...@gmail.com (Teresa Pietrabissa) — Tue, 21 May 2013 12:38:05 UT

Hi, I am dealing with random generators using thrust library.
When I run my program the variable m_seed changes value but the sampled
values for the variable u are always the same, as if the instruction for
setting the seed didn't work out.
Does anybody knows how this works or has ever had this kind of problems

Re: [thrust-users] change in handling of sequence?

jaredhober...@gmail.com (Jared Hoberock) — Mon, 20 May 2013 20:23:03 UT

The reason the compile fails is because
std::complex<double>::operator * [1] doesn't have an overload which
takes a long int as the scalar parameter.

This program tries to do the same thing and fails with a similar error:

int main()
{
std::complex<double> init, step;

long int i;