I'm sure other approaches can be much more effective, my research was almost 8 years ago and was framed around trying to parallelise one of the algorithms.
So my focus was half on the theory behind these solution search algorithms and half on parallelism and the associated theory.
I've a gut feeling that a superior algorithm often gets you better ROI than parallelising an existing solution.
The TLDR of my findings was that for the algorithm in question, it wasn't greatly suited to parallelism. Performance didn't scale linearly with cores due to too much shared state, and the best you could hope for was seeding each parallel run of the algorithm with different randomisation seeds and it's own state and bank on certain runs not getting caught in local optimum.
So it got you better performance, but not so much that you'd jump right in to doing work to parallelise. Probably better to use algorithms that are built to be embarrassingly parallel from the ground up.
So my focus was half on the theory behind these solution search algorithms and half on parallelism and the associated theory.
I've a gut feeling that a superior algorithm often gets you better ROI than parallelising an existing solution.
The TLDR of my findings was that for the algorithm in question, it wasn't greatly suited to parallelism. Performance didn't scale linearly with cores due to too much shared state, and the best you could hope for was seeding each parallel run of the algorithm with different randomisation seeds and it's own state and bank on certain runs not getting caught in local optimum.
So it got you better performance, but not so much that you'd jump right in to doing work to parallelise. Probably better to use algorithms that are built to be embarrassingly parallel from the ground up.