help-glpk
[Top][All Lists]
Advanced

[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: Tue, 1 Jan 2013 05:48:59 -0800 (PST)


--- On Mon, 12/31/12, Harley <address@hidden> wrote:



> For those questioning the need for the requirement of
> re-entrant code for GLPK, I asked the same 
> question and Xypron sent this answer to me by email:
> 
> "you are right that multiple processes may run GLPK at the
> same time. But many
> applications like Apache or Tomcat are multi threaded. So
> maybe you would
> like to create a webservice offering route optimization by
> solving a TSP. You
> wouldn't be able to do so with the current GLPK because
> Apache has multiple
> threads per worker process, and you definitely do not want
> to shut down
> Apache if one of the TSPs has a problem because a user of
> your webservice
> came up with some strange input."

Putting the GLPK based solver in its own address space by calling fork(2) takes 
care of the issue w/o the need to modify GLPK at all.

The justification for threads is avoiding the overhead of spawning a separate 
process.  In the context presented above that's negligible and almost 
undetectable in the presence of network latency.

Threads are useful if you're trying to speed up single problem solution times 
by parallelizing matrix operations across multiple cores.  However, if you're 
running multiple problems concurrently, doing that will slow things down by 
increasing the number of cache conflicts.

TANSTAFL!  

Have Fun!
Reg

NB: w/ & w/o are far less cryptic than things like TSP, SAT, etc. randomly 
tossed about as is widely done in OR papers.

cf. "The Moon is a Harsh Mistress", R. Heinlein





reply via email to

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