My question is 1) is this true
No, this is complete and utter nonsense.
Automatic parallelization of code that wasn't explicitly written to be parallel has been (one of) the holy grail(s) of optimizers for decades, but it still doesn't work for anything but the most trivial cases. Even just figuring out whether a piece of code has side-effects at all, so that we know whether parallelizing it is even legal, is in the general case equivalent to solving the Halting Problem.
In languages like Haskell, where everything is trivially free of side-effects by definition, the opposite problem exists. There is so much potential parallelism, that we need to restrict it, and again, we haven't figured out how to do this.
Now, automatic parallelization of code that knows it is being automatically parallelized, that is a completely different scenario.
In the Fortress Programming Language, there is a construct that looks like a
for loop, but is actually a parallel generator. The language specification says that
for loops are executed in parallel, so the Fortress programmers specifically take that into account when writing their
In the Scala standard library, there are many parallel collections. These are collections which have their
span, etc. methods implemented to use parallelism. Again, if you use a parallel collection, you know that your
map is going to be executed in parallel.
Your example would look like this:
(1 to 100000000).par foreach doComplexCalculationWithNoSideEffects
[Note: I made the mistake of actually testing this. The good news is: it works as expected. The bad news is: I should've made the range smaller for testing, it's still running 10 minutes later :-D]
Note the call to the
par method on the
Range object, which returns a
In the .NET Task Parallel Library, there is a method called
Parallel.For you could use (untested):
Parallel.For(1, 100000000, doComplexCalculationWithNoSideEffects);
In Java, it would look something like this (untested):
Many other languages also have similar libraries available for parallel computation.