RE: [Help-glpk] GLPK re-endrant

[Rios, Joseph L. (ARC-AFO)]

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