Just to chime in again... >> >> One can run multiple processes on multi-cored CPUs. >> Shared memory isn't necessarily all that great a model, >> but is difficult to avoid with threads. >> Separate processes with explicit message-passing >> can be a lot easier to wrap one's brain around. >> The lack of a common address space makes it >> hard for them to tromp on each others data. > > Yes, you're right. But it is not as efficient as a re-entrant library: > message-passing syscalls comes at a computational cost, not even to mention > process setup. >
I'm completely with Giampaolo on this. Indeed, you can launch new processes for parallelization, but having the ability to multi-thread is quite important. The application for which I had to create the patch launches 1000's of concurrent threads accessing common GLPK data. That might be too brutal with processes (I didn't actually try that, nor would I want too). > Also, thinking of some functionality or method in GLPK which would greatly > benefit from an easy parallelization would be interesting at least. > Especially considering that implementing multithreading with commercial tools might cost you "per thread" (or process). I think GLPK could be a great tool for researching and working with parallel optimization methods. I guess I should say it could be a GREATER tool, as it already can do the job with a little elbow grease. Joey _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
