Re: [Help-glpk] GLPK re-endrant

[Michael Hennebry]

On Mon, 6 Jul 2009, Rios, Joseph L. (ARC-AFO) wrote:

> > > 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).

I'm not surprised the optimum would be larger than the number of cores.
That the optimum was so large was likely the result
of changing the problem with the number of threads.
It's not necessary to have a one-to-one relationship
between threads or processes and 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.

You seem to be assuming that process creation
is much more expensive than thread creation.
It ain't necessarily so.
IIRC linux does thread creation in roughly
the same way it does process creation.

> 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.

If the shared memory is primarily read-only, that would
go a long way to alleviating the brain-wrapping issues.

> 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.

True.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."