Acceleo standalone and multi-threading
One of the main features of the standalone Acceleo engine is to provide multi-thread support. This allows us to divide the code generation time according to the count of available processors, effectively cutting the generation in half on some machines. To share the work between threads, the input model is divided into groups of objects; each group is then queued till a thread can process it.
There are two parameters to tweak the multi-threaded generation. The first one is the number of threads to run simultaneously, the default value being the number of available processors plus one. This allows us to use all available processors, the one supplementary thread used to cover synchronization waiting time. While some threads are waiting for another one, one processor is free to run the thread which was waiting for an idle processor.
The second parameter is the number of objects per group, the default being 20 objects per group. This parameter is very important since its allows you to find the optimum between load sharing and thread management overhead. Your objects groups will not be processed using the same amount of time. So Imaging you divided your model into two groups by setting number of objects in the model divided by 2. The group which runs faster will have to wait for the slower group at the end of the generation. In this case you are losing time. On the oposite you can put a single object per group. This way you minimize the loss of time at the genretation end. But threads will spend more time peeking groups in the queue since there are much more groups.
To set thoses parameters have a look at :
- Extension.setThreadsNumber(int)
- Extension.setEObjectsPerThread(int)
There are two parameters to tweak the multi-threaded generation. The first one is the number of threads to run simultaneously, the default value being the number of available processors plus one. This allows us to use all available processors, the one supplementary thread used to cover synchronization waiting time. While some threads are waiting for another one, one processor is free to run the thread which was waiting for an idle processor.
The second parameter is the number of objects per group, the default being 20 objects per group. This parameter is very important since its allows you to find the optimum between load sharing and thread management overhead. Your objects groups will not be processed using the same amount of time. So Imaging you divided your model into two groups by setting number of objects in the model divided by 2. The group which runs faster will have to wait for the slower group at the end of the generation. In this case you are losing time. On the oposite you can put a single object per group. This way you minimize the loss of time at the genretation end. But threads will spend more time peeking groups in the queue since there are much more groups.
To set thoses parameters have a look at :
- Extension.setThreadsNumber(int)
- Extension.setEObjectsPerThread(int)
Auteur d'origine: yvan