Re: [Help-glpk] GLPK re-endrant

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

> 
> On a problem that would benefit from threads,
> I'd expect process setup to be a small part of the processing time.
> Similarly with subproblems that separate well,
> I'd expect message-passing to be a small cost.
> There would be messages to feed threads problems
> and messages to give the master results.
> Problems that don't separate well and would require lots of
> communication are the ones that might benefit from shared memory.
> For those kinds of problems it might be worth
> it to wrap ones brain around shared memory.
> Beforing going that route, I'd at least look for a new algortihm first.
> 
>> 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).
> 
> 1000's?  Why?
> Unless you had at least 100's of cores, and maybe even then,
> I'd expect a smaller number to run faster.

Expectations can be funny.  Like you, I expected on my 8-core machine for 8
threads to be ideal.  I tried 16 just for fun and it ran faster.  I then
tried 32, 64, 128 and 246... Each ran faster than the previous.  Turned out
that the overhead of maintaining threads was lower than the overhead of
solving the larger subproblems (less subproblems -> larger subproblems).
And now my problem will scale nicely with any future increase in cores.  I
maxed out my subproblems over 5000+, all running concurrently and found that
the runtime and solution quality both improved.

As you suggest, my problems separate well and don't pass large amounts of
data.  But that doesn't mean I want 5000+ processes launched.  Also in my
case, having the master problem readable by the subproblems is beneficial
and a good reason for shared memory.

The moral of the story is that being able to run GLPK in a multi-threaded
manner opens up options.  Nothing would stop anyone from running it in
multiple processes and passing messages instead of using threads and shared
memory if they wanted to.  Making GLPK thread-safe strictly enhances the
tool.

Joey