Back to (Parallel) Basics: Do you really want to do that? or Why doesn't the new Parallel.For support BigInteger? April 21, '10 Comments [17] Posted in Back to Basics | Programming | VS2010 Sponsored By Got an interesting question on Twitter, and got a fabulous answer in email from Stephen Toub, who happens to be my most favorite multi-threaded person. Here's the question. "why doesn't the new parallel.for support BigInteger?" It's an interesting question for a few reasons. First, it's interesting because it's a question about the new parallel stuff in .NET 4 and Visual Studio 2010 that lets the developer take parallel problems that would be very hard and makes them extremely easy. For example, you can basically take a straight for loop and often make it run in parallel on multiple-cores. This is huge. Second, speaking of huge things, BigInteger is huge. Extremely. How big? Unbounded. Like, arbitrarily large. I'd have preferred BigAssInteger, but that's offensive, so stop asking for it. ;) Here's Stephen's emailed answer with my added commentary. "I know of no real scenarios that require such a large, dense iteration space and that could stay running for long enough on a single box. Parallel.For does provide built-in support for Int64, which affords up to 2^64 iterations. If you were able to run such a loop where each iteration of the loop took a nanosecond to process (i.e. a billion iterations per second), it would take something like 500 years to complete on a single core. Even with a hundred cores in a single box this would take five years to complete." He is extremely kind. Notice how he says "why the hell would you want to do that" without making me feel bad? The man's a teacher. Not only that, he offers an alternative that would run for a half-millennium without any judgment that my problem space might be wrong. He should be a college professor. Second, if you really do need this support, it’s achievable with Parallel.ForEach and either iterators or a custom Partitioner<T>. For example, with iterators, you can write a handy method: static IEnumerable<BigInteger> Range(BigInteger fromInclusive, BigInteger toExclusive){ for(BigIntegeri=fromInclusive; i<toExclusive; i++) yield return i;} What? After telling me it's not desirable and I don't really want to do it, he actually DOES it. That's hot. and then consume it in a method like: public static void ParallelFor(BigInteger fromInclusive, BigInteger toExclusive, Action<BigInteger> body){ Parallel.ForEach(Range(fromInclusive,toExclusive), body);} which you can then use like: ParallelFor(new BigInteger(from), new BigInteger(to), i=>{ // ... loop body here ...}); Finally, I’d love to understand if lack of BigInteger support is actually causing this customer issues, or if they’re just curious. And if it’s actually problematic, what’s the scenario? Then, after all this he asks if there's a scenario for this that he might not have thought of. You can't know everything, so he wants to double check to make sure the library he worked on does everything the customer wants. My man-crush on this dude couldn't be any bigger. Now if Stephen would just return my calls. The bromance continues. ;) Hope you enjoyed this sample, and big thanks to @amarciniec for the great question. « Towards a Smaller .NET 4 - Details on th... | Blog Home | A Diabetic Product Review for Non-Diabet... » About Scott Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author. About Newsletter Sponsored By Hosting By