What operations can be done in-place?

[HueHue44]

Hello! I was just wondering which available operations can be done in-place (using the same iterator as input and output)? Specifically for DeviceScanand DeviceSelect. It is not clear in the documentation whether this is never allowed, always allowed or sometimes allowed. So does anyone know if there is some strict ruling on everything? Otherwise, I would like to know how it works specifically for DeviceScanand DeviceSelect.

[alliepiper]

DeviceScan can be run in-place, since each block will only read/write the portion of the input it is assigned.

I'm not sure about DeviceSelect -- from looking at the implementation it appears that there may be race conditions if run in-place, though I'd need to dig in a bit more to be absolutely sure. For now, I'd avoid running DeviceSelect in place.

We should check this for each algorithm and update the documentation at some point.

[HueHue44]

Alrighty, good to know that the scan can be run in palace. I'll be on the safe with DeviceSelect for now then. Thanks for the info!

[benbarsdell]

I'm also interested in this (specifically for DeviceRadixSort). In addition to documentation, a runtime error check (at least an assertion) in cases where it's not supported would be valuable.

[alliepiper]

@senior-zero since this came up in our call today, can you add this information while you're going through the CUB device algorithms?

[gevtushenko]

Hello @HueHue44, @benbarsdell! I've created a series of PR that addresses in-place guarantees for various algorithms. Please, take a look at:

• partition PR
• sort PR
• reduce PR
• rle PR
• select PR
• histogram PR
• adjacent difference PR
• scan PR

[gevtushenko]

All of the mentioned PRs were merged, closing the issue. Let us know if there is any algorithm without document its in-place guarantees.