help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] Multi-thread questions


From: Reginald Beardsley
Subject: Re: [Help-glpk] Multi-thread questions
Date: Sat, 12 Oct 2013 06:18:39 -0700 (PDT)

I'm a bit baffled by "serialization and deserialization".   What's meant by 
that? What is being serialized?

As I understand things the goal is to run a set of independent problems in 
parallel and then pick the optimal answer from among the results.  That's quite 
easy just using glpsol and the standard *nix shell programs which are readily 
available on any system including Windows.  It's so simple that it's less work 
than the discussion about multi-threading alone without doing any programming.

Is there more to it? It seems to me that a clear statement of the problem is 
the first step to a solution.

--------------------------------------------
On Sat, 10/12/13, Paolo Bolzoni <address@hidden> wrote:

 Subject: Re: [Help-glpk] Multi-thread questions
 To: 
 Cc: "address@hidden" <address@hidden>
 Date: Saturday, October 12, 2013, 6:06 AM
 
 On Sat, Oct 12, 2013 at 7:11 AM, Joey
 Rios <address@hidden>
 wrote:
 >> In my scenario, I have many linear problems and I
 have to find the one
 >> with
 >> the maximum solution. Parallelism is easy for this
 scenario since there is
 >> nothing to share, just find the best.
 >
 > If there is nothing to share between your problems, you
 probably should take
 > the advice of Marc and just use scripted calls to
 glpsol.  Your concern of
 > serialization and deserialization does not really
 explain why calling glpsol
 > this way would be a problem.
 To create the problems we just need to loop over few data
 structures.
 It might be uncommon in general, but to serialize and
 deserialize
 would be much more code. It is definitely an option, but if
 possible we
 like the paths of less resistance.
 But I am getting the point maybe the best is indeed this
 choice and await
 that C11 implemented by compilers. (I expect no more
 portability problems
 after... isnt it?)
 
 > The main thing you should do is replace all of the
 calls to glpk's custom
 > memory allocation routines with a basic malloc
 call.  Likewise, replace the
 > glpk custom free calls with regular 'free' calls. 
 There is one more place
 > that you have to do something, but I forget where it is
 (somewhere in the
 > TLS stuff like you mention). The code has changed since
 4.44, but here is a
 > patch that I used on that version of the code to create
 a threaded version
 > of the glpk library:
 >
 > http://sourceforge.net/p/dwsolver/code/ci/master/tree/glpk-4.44.ThreadReady.patch
 Thanks!
 
 _______________________________________________
 Help-glpk mailing list
 address@hidden
 https://lists.gnu.org/mailman/listinfo/help-glpk




reply via email to

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