[Top][All Lists]

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

RE: [Help-glpk] GLPK re-endrant

From: Rios, Joseph L. (ARC-AFO)
Subject: RE: [Help-glpk] GLPK re-endrant
Date: Thu, 2 Jul 2009 19:48:37 -0500

Just to chime in again...

>> 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. 

I'm completely with Giampaolo on this.  Indeed, you can launch new processes
for parallelization, but having the ability to multi-thread is quite
important.  The application for which I had to create the patch launches
1000's of concurrent threads accessing common GLPK data.  That might be too
brutal with processes (I didn't actually try that, nor would I want too).

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

Especially considering that implementing multithreading with commercial
tools might cost you "per thread" (or process).  I think GLPK could be a
great tool for researching and working with parallel optimization methods.
I guess I should say it could be a GREATER tool, as it already can do the
job with a little elbow grease.


reply via email to

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