[Top][All Lists]

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

Re: [Help-glpk] Optimization and Multicore GLPK

From: Reginald Beardsley
Subject: Re: [Help-glpk] Optimization and Multicore GLPK
Date: Thu, 27 Dec 2012 17:03:57 -0800 (PST)

You can run multiple instances of glpsol or a custom program that calls GLPK as things are now.  The operating system guarantees that they don't interfere with each other.  There is no benefit to using threads to solve multiple problems unless they are very closely related.  In that case there are better options already.

There are compelling reasons for using threads to improve performance of single problem solutions.  In the case of simplex, this is pretty much limited to matrix arithmetic.  For MIP problems there is evidence that task level parallelism (e.g branch and bound) can be successfully implemented to produce a useful performance boost.

Parallel programming is difficult.  Concurrent shared memory programming is harder.  People get tenure for solving major problems.  As a practical matter I try to avoid attempting to solve problems for which you can be granted tenure.  I typically need to get something done by a deadline.

I watched everyone struggle to get symmetric multiprocessing (SMP) to work reliably.  You've not endured pain until your multimillion dollar computer kernel panics on a daily basis for months on end.

Have Fun!

--- On Thu, 12/27/12, Patrik Dufresne <address@hidden> wrote:

From: Patrik Dufresne <address@hidden>
Subject: Re: [Help-glpk] Optimization and Multicore GLPK
To: "Robbie Morrison" <address@hidden>
Cc: "GLPK help" <address@hidden>
Date: Thursday, December 27, 2012, 5:43 PM

Correct me if I'm wrong: With GLPK you may solve multiple problems at the same time using one thread for each problems. So, I don't understand why it's important to make GLPK thread safe. As long as you are manipulating the problem object with the same thread, you are OK. In case you need to manipulate the same problem object with multiple threads, I think it's up to the application code to properly handle the thread to synchronize the operation done to the problem object.

-----Inline Attachment Follows-----

Help-glpk mailing list

reply via email to

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