# Are more cores at lower GHz always faster for parallel processing?

Web searches have not yielded a definitive answer to this question: I am doing Monte Carlo simulations in Mathematica using ParallelTable, etc. to speed up the computation. I have an Enterprise license which comes with 16 core support. The iMac Pro has processor options for 8 cores at 3.2GHz, or 10 cores at 3.0GHz, or 14 cores at 2.5GHz, or 18 cores at 2.3GHz. Which option will give the shortest computation time?

• I think this is impossible to answer without trying it. May 7, 2018 at 15:42
• That will depend on the applications and on what difficulties you are willing to take in order to write code that scales well. Usually, Monte Carlo simulations can be done with a low amount of communications between the computing cores. So there is a veritable chance that this will scale very well. In that case, the 18 core setup would perform best. But without testing, this is indeed hard to tell. May 7, 2018 at 15:47
• One thing to keep in mind is how many kernels your license allows you to use for parallel computations. May 7, 2018 at 15:47
• Before investing such a bunch if money into something that at worst might be an expensive heating sytem, you should write an example code typical for your problems and try to make it scale on 1 to 8 cores. May 7, 2018 at 15:50
• Another variable is thermal management limiting the workload if the processor chip gets too hot. May 7, 2018 at 16:09

Since no one dares an answer, let me give at least some advice. My main question is, why don't you test to which degree your algorithm is parallelizable? I'm sure, your current system has at least 4 cores, so you can run the same simulation with 1, 2, 3, and 4 cores and time it.

Mathematica using ParallelTable, etc.

This "etc." is important. There two principal ways of parallelizing algorithms in Mathematica. The first is using functions like ParallelTable which all work by starting several sub-kernels and use them as workers. This might, depending on your simulation, have a large overhead because data needs to be sent back and forth between the workers and the main kernel.

Using compiled functions and parallelized them is a more light-weight option since these functions work directly on the data that is already in memory. However, it is not always possible to pack an algorithm into a compiled function. Nevertheless, I have written many methods that do some computation on the main kernel and only the core part is done in parallel in a compiled function.

One of these approaches is my, soon to be published, ColorDeconvolution package. Here, I had exactly the mix of doing some parts in parallel, other using optimized Mathematica matrix functions, and others with non-parallelized code. For this package, I did exactly these measurements to give the user an idea about what speed he can expect on very large images.

The following shows the run-time on a 3000 x 3000 image, where I gradually increased the number of cores that are used. I'm running here a Mac OS X with 2,7 GHz 12-Core Intel Xeon E5 and 64GB RAM.

As you can see, an estimate with only 4 cores would still lead to a good approximation how your algorithm behaves when the number of cores goes up.

If your graph looks anything close to what I posted above, you should probably go for the 10 core with 3.0 GHz. More than 10 cores give in my situation only a small advantage in overall running time and having 0.7 GHz more per core (compared to the 18 cores) will give the better speed. But as always, it all depends...