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?
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...