Python doesn't do any parallel computation. Go does it very well. I honestly don't know how to do parallel computation in C or C++, but I doubt it's very easy. Slower code can run faster overall if you have multiple processors, so pure processing speed has the potential to matter less.

 You can do parallel computations in Python e.g., many numpy functions can utilize more than one CPU:`````` import numpy as np N = 5000 # create a couple NxN matrices with random elements a = np.random.rand(N, N) b = np.random.rand(N, N) # perform matrix multiplication c = np.dot(a, b) `````` Cython makes it easy to write C extensions for Python if necessary.You can also do a compute-intensive work in parallel using multiple processes:`````` import random from multiprocessing import Pool def fire(nshots, rand=random.random): return sum(1 for _ in range(nshots) if (rand()**2 + rand()**2) < 1) def main(): pool = Pool() # use all available CPUs nshots, nslices = 10**6, 10 nhits = sum(pool.imap(fire, [nshots // nslices] * nslices)) print("pi = {pi:.5}".format(pi=4.0 * nhits / nshots)) if __name__ == '__main__': main() `````` The code calculates Pi using Monte Carlo method http://demonstrations.wolfram.com/MonteCarloEstimateForPi/
 I honestly don't know how to do parallel computation in C or C++, but I doubt it's very easy.Actually, with OpenMP parellelization is often easy in C and C++. In embarrassingly parellel problems, it is often a matter of adding an OpenMP pragma before the for-loop. To give one example, in some machine learning code I wrote, it was simply a matter of replacing`````` for (int i = 0; i < static_cast(contexts.size()); ++i) `````` by:`````` #pragma omp parallel for for (int i = 0; i < static_cast(contexts.size()); ++i) `````` Obviously, you have to ensure that shared mutable variables are properly protected. But, in many cases it's fairly simple. I have tried to emulate some of OpenMP's functionality in the par package:http://github.com/danieldk/parI think the more convincing argument is that many Python programmers will feel far more comfortable writing Go than C or C++. It offers good performance and some control over memory layout, while being substantially higher level than C and not the enormous language C++ has become.
 > In embarrassingly parellel problemsTo be fair, it is trivial to parallelize embarrassingly parallel problems in most languages. Including Python (with `multiprocessing`).Go separates itself from C/C++ by making concurrent programming much easier. Namely, channels are the predominant form of both communication and synchronization between concurrent processes. This removes much of the need for locks to protect state, which is a source of common bugs.Go goes an extra step with M:N scheduling, but that is orthogonal to concurrent programming.Also, you might be interested in my type parametric version of `ParMap` [1]. It loses compile time type safety, but performance still seems to remain roughly the same.
 > To be fair, it is trivial to parallelize embarrassingly parallel problems in most languages. Including Python (with `multiprocessing`).Of course, but usually you are switching to C because the code that is being parallelized needs to be faster.Go separates itself from C/C++ by making concurrent programming much easier.Right. I was reacting to the grandparent, who mentioned parallel computation, not concurrency.Also, you might be interested in my type parametric version of `ParMap` [1].Nice :). Though my Haskell heart cries when people use interface{} plus reflection as a replacement for parametric polymorphism. Before we know it the library stack will effectively turn Go into a dynamically typed language.
 > Right. I was reacting to the grandparent, who mentioned parallel computation, not concurrency.Ah! I missed that. Mea culpa.> Nice :). Though my Haskell heart cries when people use interface{} plus reflection as a replacement for parametric polymorphism.As does mine :P But it was a fun exercise nonetheless. If you have a Haskell heart, you might be interested in my write up [1] on writing type parametric functions (using new Go 1.1 features). You will do some bleeding, but presumably you like types, so you might find it interesting. :-)> Before we know it the library stack will effectively turn Go into a dynamically typed language.Fortunately, the performance cost of reflection makes practical usage of it very limited. `ParMap` is in the minority here (where the overhead of concurrency shadows the overhead of reflection).

Search: