Max-digits of digit summing As a challenge I decided to do the following problem:


  How many different numbers with n digits are there whose digits add up to k?


As this is an embarrassingly parallel problem I decided to use a bit of GPGPU programming (partly for learning purposes) using C++AMP and came up with the following solution:

#include &lt;iostream&gt;
#include &lt;vector&gt;
#include &lt;assert.h&gt;
#include &lt;amp.h&gt;
#include &lt;chrono&gt;
#include &lt;ctime&gt;
#include &lt;numeric&gt;

inline unsigned int AddDigits( unsigned int n ) restrict(amp, cpu)
{
        unsigned int sum = 0;
        while( n &gt; 0 )
        {
                sum += n % 10;
                n /= 10;
        }

        return sum;
}

int main()
{
        std::chrono::steady_clock clock;
        unsigned int iSize, iSumRequired;

        std::cout &lt;&lt; "Please enter the number of digits: ";
        std::cin &gt;&gt; iSize;
        std::cout &lt;&lt; std::endl &lt;&lt; "Please enter the sum required: ";
        std::cin &gt;&gt; iSumRequired;
        std::cout &lt;&lt; std::endl;

        unsigned long long iMaxNum = std::pow( 10, iSize );

        assert( vecData.max_size() &gt; iMaxNum );

        std::vector&lt;unsigned int&gt; vecData( iMaxNum );
        std::vector&lt;int&gt; vecNumValid( iMaxNum );

        auto tpBegin = clock.now();
        std::iota( vecData.begin(), vecData.end(), 1 );

        concurrency::array_view&lt;const unsigned int, 1&gt; arrayView( iMaxNum, vecData );
        concurrency::array_view&lt;int, 1&gt; numValid( iMaxNum, vecNumValid );

        concurrency::parallel_for_each( numValid.extent, [=]( concurrency::index&lt;1&gt; idx ) restrict( amp ) {
                numValid[idx] = (AddDigits( arrayView[idx] ) == iSumRequired ? 1 : 0);
        } );

        numValid.synchronize();

        int iNumValid = concurrency::parallel_reduce( vecNumValid.begin(), vecNumValid.end(), 0 );

        std::cout &lt;&lt; "The number of valid numbers are: " &lt;&lt; iNumValid &lt;&lt; std::endl;
        auto tpTimeTaken = clock.now() - tpBegin;

        std::cout &lt;&lt; "Time Taken: " &lt;&lt; std::chrono::duration_cast&lt;std::chrono::milliseconds&gt;(tpTimeTaken).count() &lt;&lt; std::endl;

        return 0;
}


This offers a significant improvement over parallel brute-forcing on the CPU (2x speedup versus 8 threads on an 8-core CPU), however out of curiosity I was wondering whether any further speedup could be gained, perhaps through somehow running the parallel_reduce on the GPU rather than on the CPU; removing the necessity to synchronize the array_view?

Moreover, this only allows for up to 8-digits (because of the restriction of the maximum value being less than 231-1) because the GPU only supports types of float, double, int, unsigned int and bool; is there a way to circumvent this and improve the maximum number of digits allowed?
I understand that you are asking from a parallel point of view, but I am unable to provide feedback on that, as I have never worked with this system before. But from my point of view, creating a parallel solution is has been done premature.

Prior to creating a parallel solution to speed up your solution, you should improve the efficiency of the algorithm. At present you consider all numbers in the range of [1, 10N), whereas you only need to evaluate numbers where the number of digits in the number is equal to N. In which case you only need to evaluate numbers in the range of [10N-1, 10N).

You could further improve this via considering permutations and combinations. This would allow you to calculate all the different combinations of the digits for the given range. Once you have these you can then check which of the combinations digits sum to the required total. 

If X combinations sum to a given total then you can quickly calculate how many numbers within the require range have N digits and sum to the goal. By computing X * (N Perm N) where N is the number of digits and where permutations are calculated without replacement. Representing just the N digits in the solution.

At this point you would be using a parallel solution to calculate the combination hits, but you may find the bottle neck of data transfer to a GPU causes the parallel solution to perform slower than the non-GPU enabled solution.