MultiCORE vs MultiThread – a little guide
When running your simulation on the cloud it’s common to be a bit confused about multiCORE multiThreads capabilities of the machines. Generally, the confusion becomes even bigger when thinking that not all the software available on the platform are able to use both these functionalities.
Before going furthere it’s worth a while remembering this post is not intended for IT professionals. It aims at giving a simplified version of the reality which may be useful to start dealing with these issues.
What are them?
Let’s start from scratch and explain what multiCORE and multiThread are. Without beeing too much specific in our replies, it is possible to say that multiCORE is a parallelization methodology. In this physical separated processors [CORE] work on physical separated resources. Saying we have a simulation to perform. To use a multiCORE approach we have to SPLIT the simulation into smaller parts and assign each of these parts to a single CORE available on our computer.
The whole scheme is here represented for the sake of clarification.
Beyoind multiCORE we have multiThread. In this approach processors are not physically separated but they actually share resources. It is not necessary anymore splitting our simulations into smaller parts, we just assign all the threads to exactly the same simulation and they will cooperate to get the final result.
Which of the two my software uses?
Having define the two possibilities, we have to understand that not all the software have multiCORE and/or multiThread capabilities. The implementation of these capabilities depends on the way the code has been developped and on the libraries used by the software. For that reason, we must check the capabilities of our software before choosing if our simulation is going to be multiCORE or multiThread or, why not, multiCORE and multiThread at the same time!
Among the software you find on cloudHPC, here you find a list of their capabilities.
Are vCPU in cloudHPC multiCORE or multiThread?
CloudHPC offer a solution for both the possibilities. You can in fact at any time select whether you want to use a multiCORE only approach or a multiCORE/multiThread one. What if you want a multiThread only approach? In such a case choose a multiCORE/multiThread approach that will do for you as well!
The selection between the two types of parallelizations is made through the “RAM” options. This selection in fact, beside giving you more RAM allocation per each vCPU, allows you to choose an allocation for multiCORE only instances (highcore).
These highcore instances must always be used with all the software which are not able to use a multithread approach (i.e. OpenFOAM). With software where multithread is possible, we can use highcore instances only if we are sure we are not using the multithread: i.e. if the number of mesh division is exactly equals to the number of vCPU we are assigning to highcore instances.
What happens if you choose incorrectly? The simulation is most likely to proceed in any case. So no worries about it. But in the hardware resources you are renting won’t work at their best.
In conclusion, it shouldn’t surprise you that the definition of vCPU in cloudHPC varies. For highcpu, standard and highmem instances each virtual CPU (vCPU) is implemented as a single hardware hyper-thread, on the other hand, in highcore instances each vCPU is implemented as a physical CPU/CORE.