[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
- Re: [Help-glpk] Optimization and Multicore GLPK,
Reginald Beardsley <=