[Top][All Lists]
[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.
- RE: [Help-glpk] GLPK re-endrant, (continued)
- Re: [Help-glpk] GLPK re-endrant, Rios, Joseph L. (ARC-AFO), 2009/07/02
- RE: [Help-glpk] GLPK re-endrant, D'Agostino, Larry - TX, 2009/07/02
- Re: [Help-glpk] GLPK re-endrant, Rios, Joseph L. (ARC-AFO), 2009/07/02
RE: [Help-glpk] GLPK re-endrant, Giampaolo Tomassoni, 2009/07/02
Re: [Help-glpk] GLPK re-endrant,
Andrew Makhorin <=
Re: [Help-glpk] GLPK re-endrant, Francois Galea, 2009/07/04
Re: [Help-glpk] GLPK re-endrant, Robbie Morrison, 2009/07/08