[Top][All Lists]

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

RE: [Help-glpk] GLPK re-endrant

From: Giampaolo Tomassoni
Subject: RE: [Help-glpk] GLPK re-endrant
Date: Fri, 3 Jul 2009 03:41:40 +0300

> -----Original Message-----
> From: Michael Hennebry [mailto:address@hidden
> Sent: Thursday, July 02, 2009 9:17 PM
> To: Giampaolo Tomassoni
> Cc: address@hidden
> Subject: RE: [Help-glpk] GLPK re-endrant
> On Thu, 2 Jul 2009, Giampaolo Tomassoni wrote:
> >> ...omissis...
> >
> > Nevertheless, most of the software around nowadays is meant to be run
> by
> > multi-cored CPUs. So, reentrancy actually seems to me something very
> close
> > to a requisite. The GLPK team will surely have to face it ASAP.
> One can run multiple processes on multi-cored CPUs.
> Shared memory isn't necessarily all that great a model,
> but is difficult to avoid with threads.
> Separate processes with explicit message-passing
> can be a lot easier to wrap one's brain around.
> The lack of a common address space makes it
> hard for them to tromp on each others data.

Yes, you're right. But it is not as efficient as a re-entrant library:
message-passing syscalls comes at a computational cost, not even to mention
process setup. On the contrary, the cost of a fully-reentrant GLPK version
would probably be much less, while broadening the spectrum of implementation
frameworks in which the GLPK itself would fit.

When I say "ASAP", of course I don't mean reentrancy must be available
tomorrow. But I believe it should be at least planned.

Also, thinking of some functionality or method in GLPK which would greatly
benefit from an easy parallelization would be interesting at least.


> --
> Michael   address@hidden
> "Pessimist: The glass is half empty.
> Optimist:   The glass is half full.
> Engineer:   The glass is twice as big as it needs to be."

reply via email to

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