help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] GLPK re-endrant


From: Andrew Makhorin
Subject: Re: [Help-glpk] GLPK re-endrant
Date: Fri, 3 Jul 2009 16:55:14 +0300

> I see two fields of applications for threading in GLPK.

> ILOG describes that many MIPs can be solved >= 1.7 times
> faster using multiple threads and shared memory.
> http://www.ilog.com/optimization/the-right-hand-side/1/TA_Parallel_CPLEX_Dong.html
> http://www.ilog.com/optimization/the-right-hand-side/1/TA_Parallel_CPLEX_Dong.html

Probably if a machine has more than one cpu. However, it is a brute
force approach. (It would help if the machine has 2^n processors, where
n is the number of binary variables :) Try to solve gesa2 or gesa3
from miplib without and with mir cuts. That what's I mean.

> In case of column generation (like in the CLSP) multiple
> subproblems could be solved at the same time on separate
> cores.

> My understanding is that a major group of functions that
> has a problem with threading is the memory allocation
> (xfree, ...).
> See
> http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html
> http://lists.gnu.org/archive/html/help-glpk/2007-08/msg00040.html 

Yes, because different threads would use the same memory pool
implemented by xmalloc/xfree. This might be resolved by storing
the 'tls' pointer (defined in glplib02.c) in the thread local
storage.






reply via email to

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