Batch Fitness Evaluation in the UDAs

[scudelari]

Hello everyone,

I have been introducing myself to pagmo2 in the last week and I have a question related to the batch/multithreading mechanism. The question in simple terms is how to know if the algorithm supports multithreaded evaluation of the fitness function?

I noticed that some algorithms expose the void set_bfe(const bfe &b) function, but some do not.

• Is that what I should be looking for to know if the algorithm supports batch/multithreading mechanism?
• Does that mean that, if the algorithm exposes this function, I must then set the bfe using this function so that the algorithm becomes batch/multithreaded?
• Are there algorithms that only support one type of bfe (multithreaded or member) or if they expose this function they support both types?
• Or, if an algorithm does not expose the void set_bfe(const bfe &b) function, does that mean that it will use the default bfe in any case?

Another more specific question. Effectively, for an algorithm to evaluate the fitness in parallel, what is the required thread_safety (constant?)? Does the basic level mean that the evolution of different islands would be in parallel (but singlethreaded in each island)?

Below some clarification on my doubts and what I am doing.

For the problems I have to solve, parallel/multithreaded evaluations of the fitness function are extremely important due to performance reasons. My UDP has no problem to evaluate the fitness function in parallel, thus I implemented the following function in its class:
thread_safety get_thread_safety() const { return thread_safety::constant; };

So far, so good. Then I read the BFEs available. I would like to use the multithreaded so I use the set_bfe function of the algorithm I created:
alg.set_bfe(bfe{ default_bfe() });

From what I gather, this suffices in my case. The algorithm will use the default bfe, which will see that the problem supports the thread_safety::constant and thus it will delegate the batch evaluations to the multithreaded bfe which will evaluate the fitness in
parallel in several threads. Does this sound about right?

Thank you so much for the effort and the amazing work you all have put in Pagmo2. It is really amazing.

And thank you for the reply :)

Rafael

[darioizzo]

Keep in mind that pagmo is mainly a framework for parallel execution of optimization tasks. The various algorithms (UDAs) offered are a huge asset, but they are only examples of possible UDAs. Specific needs in terms of UDAs performances can be coded by the user. With this in mind, you can understand how we try to keep a certain homogeneity in the various APIs we offer across the UDAs we ship, but they are all somehow different. So it is not surprising that some have a set_bfe and some not. The same non uniform behavior can be found in logging or the memory argument.

Maybe we can add the bfe support info here: https://esa.github.io/pagmo2/overview.html

Now, with this in mind, here is my take on your questions, @bluescarni may want to correct/add something.

Q: Is that what I should be looking for to know if the algorithm supports batch/multithreading mechanism?
A: Yes. The UDAs shipped with pagmo are not consistently supporting a batch fitness evaluator. When they do that method will be present.

Q: Does that mean that, if the algorithm exposes this function, I must then set the bfe using this function so that the algorithm becomes batch/multithreaded?
A: I would say that multithreaded execution of optimization tastks is supported via the island model as well. But if the user wants a fine grained parallelization mode then the batch fitness evaluator must be indeed set.

Q: Are there algorithms that only support one type of bfe (multithreaded or member) or if they expose this function they support both types?
A: The algorithm does not care on the type of bfe.

Q: Or, if an algorithm does not expose the void set_bfe(const bfe &b) function, does that mean that it will use the default bfe in any case?
A: If an algorithm does not have a set_bfe, then the batch fitness evaluation of the fitness is not supported.

[kals0222]

Hi Rafael,

Thank you for sharing your experience with pagmo2 and your questions regarding multithreading and batch evaluation mechanisms.

To answer your first question, if an algorithm exposes the void set_bfe(const bfe &b) function, it indicates that the algorithm supports batch/multithreaded evaluation of the fitness function. However, the availability of this function alone does not necessarily mean that the algorithm is multithreaded by default. You would need to set the batch function evaluator (BFE) explicitly using this function to enable batch/multithreaded evaluations.

Some algorithms may only support a specific type of BFE (multithreaded or member), while others may support both types. It is best to refer to the documentation of the specific algorithm you are using to determine its capabilities and requirements.

Regarding your second question, if an algorithm does not expose the void set_bfe(const bfe &b) function, it will likely use the default BFE unless specified otherwise. However, it is always best to refer to the documentation or consult the developers to confirm this.

To answer your specific question about the required thread safety for parallel evaluation of the fitness function, thread_safety::constant is the minimum level required for an algorithm to evaluate fitness in parallel. If an algorithm has this level of thread safety, it means that it is safe to call the operator() on different instances of the same problem in parallel, but it does not necessarily mean that different islands of the same algorithm can be run in parallel.

Based on the information you provided about setting the BFE, it seems like you have taken the correct steps to enable batch/multithreaded evaluation of the fitness function in your case. However, I would recommend referring to the documentation or consulting with the developers to confirm that you have correctly set up the algorithm to use the multithreaded BFE.

I hope this helps, and good luck with your work on pagmo2!