> 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. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
