[cryptophile]

Enlisting more cores in order to get something done faster, you know, by splitting the work is indeed a serious pain.

I recently wanted to get lpsolve to split an integer branch-and-bound programming problem across multiple cores and then get a large on-demand AWS instance to deal with.

The branch-and-bound algorithm is eminently parallellizable. So, it should have been possible.

I came to the conclusion, however, that I would have to rewrite lpsolve for that. That program sticks to one process and there is no way to get it to fork other processes and read back the results.

[skj]

The tendency is for things like lpsolve to be written single-process, because typically when you need to do it once, you need to do it one thousand times, and then your distribution is using each core available to you for a single lpsolve instance.

1000 iterations of an lpsolve invocation running on a single core, is going to run faster than the same number of lpsolve invocations each running on 10 cores.

[robmccoll]

Using multiple processes for this is a big leap since you have to plan your data sharing scheme. Assuming the program is currently only single threaded, dropping some OpenMP on it in the right places would be an easier path to using all of your cores.