[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] GLPK re-endrant

From: Michael Hennebry
Subject: Re: [Help-glpk] GLPK re-endrant
Date: Mon, 6 Jul 2009 13:33:06 -0500 (CDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]