Parallelizing very large array base conversion

Question

I have a method that converts value to a newBase number of length length.

The logic in english is:

If we calculated every possible combination of numbers from 0 to (c-1)
with a length of x
what set would occur at point i

While the method below does work perfectly, because very large numbers are used, it can take a long time to complete:

For example, value=(((65536^480000)-1)/2), newbase=(65536), length=(480000) takes about an hour to complete on a 64 bit architecture, quad core PC).

private int[] GetValues(BigInteger value, int newBase, int length)
{
    Stack<int> result = new Stack<int>();

    while (value > 0)
    {
        result.Push((int)(value % newBase));

        if (value < newBase)
            value = 0;
        else
            value = value / newBase;
    }

    for (var i = result.Count; i < length; i++)
    {
        result.Push(0);
    }

    return result.ToArray();
}

My question is, how can I change this method into something that will allow multiple threads to work out part of the number?

I am working C#, but if you're not familiar with that then pseudocode is fine too.

Note: The method is from this question: Cartesian product subset returning set of mostly 0

Answer 1

If that GetValues method is really the bottleneck, there are several things you can do to speed it up.

First, you're dividing by newBase every time through the loop. Since newBase is an int, and the BigInteger divide method divides by a BigInteger, you're potentially incurring the cost of an int-to-BigInteger conversion on every iteration. You might consider:

BigInteger bigNewBase = newBase;

Also, you can cut the number of divides in half by calling DivRem:

while (value > 0)
{
    BigInteger rem;
    value = BigInteger.DivRem(value, bigNewBase, out rem);
    result.Push((int)rem);
}

One other optimization, as somebody mentioned in comments, would be to store the digits in a pre-allocated array. You'll have to call Array.Reverse to get them in the proper order, but that takes approximately no time.

That method, by the way, doesn't lend itself to parallelizing because computing each digit depends on the computation of the previous digit.