help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] Multithreading/parallelization


From: Robbie Morrison
Subject: Re: [Help-glpk] Multithreading/parallelization
Date: Sun, 16 Dec 2012 05:57:44 +1300
User-agent: SquirrelMail/1.4.22

Hi Harley, all

A couple of minor thoughts on the topic.

------------------------------------------------------------
To:           address@hidden
Subject:      Re: [Help-glpk] Multithreading/parallelization
From:         Harley Mackenzie <address@hidden>
Date:         Sat, 15 Dec 2012 12:45:14 +1100
------------------------------------------------------------

> From my investigation the two main libraries for
> the implementation of multi-threaded support for
> GLPK are the pthread library for linux systems
> and the pthread library for Windows that has
> been released under LPGL and is therefore
> compatible with the license of GLPK and could be
> included as part of the source with the
> appropriate inclusion of the license.

The new C standard, C11, supports multithreading
natively:

  http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

It would be worth considering coding to this
standard.

The downside is compiler support: wikipedia
reports incomplete support support by:

  - GCC starting with version 4.6
  - Clang starting with version 3.1
  - IBM XL C starting with version 12.1

It would be possible to code GLPK to two
standards, C11 for the threadsafe version and C99
for the default version using conditional
compilation.  But some well designed test suites
would be advisable!

> I certainly would like to do this within the
> existing project management of GLPK, but a
> possible way of coordinating the development of
> this relatively major change to the GLPK code
> would be to temporarily fork the project and
> host on GitHub where multiple participants could
> contribute to the project with a view to merging
> the changes back into the main GLPK source code
> at a later time.

Another long sentence!  Are full stops scarce or
expensive in Australia?

I would endorse the use of 'git' and 'GitHub'.

Indeed, the unstated question is really whether
the entire project should migrate to 'GitHub' (or
similar).  That would solve the reintegration
problem too (though this is not a major issue).

Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Institute for Energy Engineering (IET)
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from Webmail client]





reply via email to

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