An FAQ and the next release
Bill Hart
to get things moving again after a short hiatus, I propose four things:
************ AN FAQ **************
I'd like to have accessible on our website a shiny new FAQ. As MPIR
is a library, i.e. primarily aimed at other developers, I'd like to
have the FAQ focus on MPIR development and how people can contribute.
In particular I'd like to answer a lot of questions which people have
asked on and off list about the direction MPIR is heading, and some of
the key benefits of the MPIR package (we are developing support for
parallelism, we support Windows MSVC, we test on OSX (64 bit for now)
and Solaris).
I'd also like to aim to answer the many questions prospective
developers have about how to contribute. So far two ways have become
popular. The core developers have been happily using svn. Numerous
others have offered code on the google group files upload section. We
should officially recognise both. But we also have a GIT repository,
and I'd like to encourage people to contribute via that, who feel more
comfortable with distributed revision control.
Do people have questions they'd like answered? Let's make a start here
at this post. I'm willing to put in some hours to begin writing this.
Who'd like to help?
************* SKIP MPIR 1.2.2 : LET'S START ON MPIR 1.3!! ***************
(Because major releases are more fun. :-) )
I propose we ditch the 1.2.2 release, which was slated to contain
Robert Gerbicz's fast root test code. It still remains a priority to
get this in, and I have rewritten most of what he submitted in mpn
format. But we need numerous other functions implemented at the mpn
level before this code will work. So let's not hold up development on
account of some artificial requirement that this be done before the
very next release.
Instead we should go straight to version 1.3. I think it is actually
possible to include crude parallel support in this version with a
configure option --enable-mt, though some things like tuning code may
be broken for now. The test code will have to be fixed though.
Alternatively we can refocus on further core development, such as
writing mulmid_basecase in assembly and getting David Harvey's superb
new middle product code in, on improving Toom 3 further, and faster
extended GCD and GCD.
I also think we should include better development documentation. There
is already documentation about how to add files to MPIR and have them
build. But a nice pdf file accessible from the webpage called MPIR
Development would be really nice, explaining the nuts and bolts to
potential developers, particularly with respect to mpn level coding.
But let's put in version 1.3 whatever is ready.
************** NEW BENCHMARK UTILITY ****************
We should also release a new benchmark utility, which Brian has been
working away on furiously. I would like to float the idea of not
having an overall score, but merely scores for each section,
Multiplication, Division, GCD, Real World Benchmarks. That way
deciding on weighting factors is not important. To some developers 1
and 2 limb stuff is the most important thing, to others it is extended
GCD, to others real world performance, to others, multiplication is
the only thing which really matters. Actually a survey was done of the
number of calls to mathematical operations in code and multiplication
far and above accounted for the majority of such calls. Fast
multiplication must remain the priority (though we should not fall
behind in development in other areas either).
Ultimately our benchmarks will have to measure per core performance.
Multicore support is clearly the only way to beat Moore's law that is
on the horizon. We must embrace it.
************** PUT THE GIT REPO ON THE WEBPAGE *********************
As mentioned, let's get the GIT repo updated on the main website and
start encouraging people to check it out. I'd also like to have an
html commit log, similar to what the GMP project gets from its HG. It
doesn't matter if that comes from svn or GIT, either way it is useful.
I propose that the core devs (and anyone else interested) also get all
commit messages emailed to them by default so that we can begin
scrutinising each other's code more easily.
************** FORTNIGHTLY MPIR DIGEST ****************
At least once a fortnight or ever three weeks we should have an MPIR
digest which summarises what development has taken place, and what
projects people can be involved in, also proposed improvements which
others might like to volunteer to work on. This Digest would include a
short Most Wanted list, of most wanted features. I volunteer to write
the digest, though I'd be happy to share the responsibility with
anyone. It will be posted to mpir-devel.
Comments? Questions? Suggestions?
Bill.
Bill Hart
worth of FAQ, based on what people have actually asked me (or I'd
secretly like them to ask) about development:
MPIR (Multiple Precision Integers and Rationals)
Frequently Asked Questions
-----------------------------------------
Q. What is MPIR?
A. MPIR is a library for multiple precision integer arithmetic based
on the GMP (GNU Multi Precision) Library.
Q. What is MPIR all about?
A. MPIR has the following special features:
- Support for building under MSVC
- We test regularly on Solaris and OSX 64 bit
- Developer friendly community
- Developers retain copyright of code they submit
- LGPL v2+
- Used by the extremely popular Sage open source mathematical project,
PHP, gmpy and other significant projects
- We aim to provide support for parallel processing
Q. What is this about the license of MPIR being LGPL v2+
A. The LGPL version 2 specifically allows a commercial project (of
which most of the big mathematical software products are) to link
statically against MPIR and make a written offer to make a dynamically
linked version available. This specific provision is removed from LGPL
version 3. Most of the major mathematical software companies which
have need of open source integer libraries are commercial companies
which want to distribute statically linked versions of the software
for usability and performance reasons and do not want the extra hassle
the LGPL v3+ entails for their users.
Specific clauses in the LGPL version 3 are aimed specifically at
eroding the patent protection agreements of Microsoft and similar
companies. They are unable legally to become contractual parties to
such a license by supporting it. Thus their employees may not
distribute software bound by those terms.
Microsoft Research have on the other hand been ardent supporters of
Sage, Open Source mathematical software, contributing algorithms and
the like and are well respected in the mathematical community.
Sage and a number of other major open source mathematical projects
have remained LGPL v2+.
Continuing to remain with LGPL v2+ is a strategic step for MPIR, and
we will revisit the issue should it become a hindrance to the project.
Q. How can I contribute code?
A. There are three ways currently supported.
1. Download the source tarball from the website, make your
modifications and put the modified version on the files upload section
of our mpir-devel group.
2. Using svn, check out our repository, make your changes, then
either commit to the repository if we give you write access, or send
us a diff.
3. Using git, check out the repository, make your changes, then
either send us a patch bundle or share your changes with other
developers (git is distributed revision control, so you do not need to
check in through a central repository to share your patches with other
developers).
Gotta go. More later....
Bill.
2009/7/1 Bill Hart <goodwi...@googlemail.com>:
Bill Hart
Q. What does it mean that MPIR is developer friendly?
A. We have a zero tolerance policy with respect to being rude to
potential developers and users. We do all we can to answer questions
and to do so publicly in a polite manner. Sometimes some users just
shouldn't be writing software, but sometimes such people end up being
your most supportive fans or your most valuable contributors. Making
it easy for people to contribute is the number one priority.
Q. What is this on the GMP website about MPIR being an "angry fork"
and a bunch of "frustrated developers" with "anti-GMP sentiments".
A. Ask them. Come on, if we were anti-GMP would we have bothered to
use their code as a base for MPIR?
Q. How does MPIR compare to GMP performance wise.
A. We may from time to time publish benchmarks. How we fare depends on
what day you do the comparison and in some cases on what system. Look,
we aren't trying to avoid the question, at the time of writing our
multiplication code is as far as we know faster on virtually x86_64
platforms, in some cases quite noticeably so. But it is such a vague
question. Do you want Windows support? Then if you have a 64 bit
machine, you are in luck. MPIR works with MSVC and gives you excellent
performance. If you want to build GMP on 64 bit Windows then likely
you'll find Brian Gladman's page, and you'll discover that he offers
the MSVC build projects for MPIR. So on 64 bit Windows we are
obviously ahead. But at the time of writing, we are behind on Itanium
(though this is very likely to change - one developer has started
work). Again if you look to the future, it is obvious that parallelism
is the way of the future. We are working on that. So the likelihood is
MPIR will outperform single core GMP at least for larger operations.
Bill Hart
incidental discussion I happened to have with people by email. There's
no point in putting too much into an initial FAQ. The idea here is to
get one started, and as questions get regularly asked, fill the
answers in. But here's a little more:
MPIR (Multiple Precision Integers and Rationals)
Frequently Asked Questions
-----------------------------------------
Q. What is MPIR?
A. MPIR is a library for multiple precision integer arithmetic based
on the GMP (GNU Multi Precision) Library.
Q. What distinguishes MPIR?
A. MPIR has the following special features:
- Support for building under MSVC on Windows (32 and 64 bit)
- We test regularly on Solaris and OSX 64 bit
- Developer friendly community
- Developers retain copyright of code they submit
- LGPL v2+
- Used by the extremely popular Sage open source mathematical project,
PHP, gmpy and other significant projects
- We aim to provide support for parallel processing
- Full support for the documented GMP interface both at the mpn and mpz levels
Q. Do I have to change my code to use MPIR?
A. No. If you do, that is a bug, please report it. MPIR aims to be
fully compatible with the published GMP interface. You can choose to
build MPIR as a library called libmpir and have the build system issue
an mpir.h, or with a single option to configure when building MPIR you
can build it in 100% GMP compatible mode. It is then a drop in
replacement for your GMP library, assuming your code complies with the
documented interface of GMP.
Q. But when a new GMP is released, won't MPIR have to spend years
catching up so it has all the same functions?
A. Details are available regarding what is being put into GMP, because
they document it and their repository is publicly accessible. Actually
in some cases we are able to have certain functions even before they
do. We don't envisage any great difficulties. So in short, no, MPIR
will not have to spend years or even months catching up with the GMP
interface. If something specific does cause you an issue, report it to
us and most likely it will be fixed before you can blink.
Q. What is this about the license of MPIR being LGPL v2+
A. The LGPL version 2 specifically allows a commercial project (which
most of the big mathematical software products are) to link statically
against MPIR and then make a written offer to make a dynamically
linked version available upon request. This specific provision is
removed from LGPL version 3. Most of the major mathematical software
companies which have need of open source integer libraries are
commercial companies which want to distribute statically linked
versions of their software for usability and performance reasons and
do not want the extra hassle the LGPL v3+ entails for their users.
Note we do not support commercial companies abusing the LGPL and
expect them to make good on their written offer to provide a
dynamically linked version if requested and to abide by all other
conditions of the LGPL version 2 scrupulously.
Specific clauses in the LGPL version 3 are aimed specifically at
eroding the patent protection agreements of Microsoft and similar
companies. They are unable legally to become contractual parties to
such a license by supporting it. Thus their employees may not
distribute software bound by those terms. It is our position that a
license agreement is not the right place for such a political campaign
against proprietary software companies.
Microsoft Research have been ardent supporters of Open Source
mathematical software, including Sage and have even provided financial
support for open source developers to further develop open source
mathematical software. Their employees have also been instrumental in
contributing algorithms and the like to the mathematical community and
are well respected as researchers in that community.
Sage, FLINT, Pari, NTL, Givaro, Gap, Singular, M4RI and numerous other
major open source mathematical projects have remained LGPL v2+.
Continuing to remain with LGPL v2+ is a strategic step for MPIR, and
we will revisit the issue should it become a hindrance to the project.
Q. Doesn't that mean you can't use code from GMP in MPIR?
A. Yes, this is an unfortunate difficulty that results from the
license incompatibility as of GMP version 4.2.2 onwards. However GMP
is a GNU project and contributors assign copyright to the Free
Software Foundation, so it would be unusual for it to not change to
the latest FSF license. It was disappointing indeed to find that LGPL
version 3 was incompatible with version 2. Were it less restrictive
than version 2 it would have been possible to use any code licensed
under version 3 in a version 2 project and any software licensed
"version 2 (or at the users discretion any later version)" in a
version 3 project. However LGPL v3 was simultaneously more and less
restrictive than LGPL v2, meaning code cannot be transferred in either
direction!
We get around this by licensing our code "version 2 (or at the user's
option any later version)", meaning that an LGPL version 3 project can
take code from MPIR, change the license at their option to version 3,
then use it in their project. As we do believe in Free Open Source
Software and we want to see use of our code hindered as little as
possible in the Open Source community, we believe this is the best
overall licensing option.
Q. Does that mean I have to license my code LGPL version 2 to get it into MPIR?
A. No, certainly not. You may use any license which is LGPL version 2
compatible. There is no problem for example if you license your code
using a BSD style license. You can even give up your copyright
altogether and place it in the public domain and we can use it. Beware
though that this means anyone can do anything they like with your
code, and perhaps there are things you do not want them to do with it.
But public domain code is definitely LGPL compatible.
Q. Do I have to sign my code over to the Free Software Foundation?
A. No absolutely not. We are not a GNU project. You can keep your own
copyright. No need to sign it over. We do not encourage this practice
because the license is then up to the Free Software Foundation and
will likely be version 3 or above, meaning we can't use it.
Q. How can I contribute code?
A. There are three ways currently supported.
1. Download the source tarball from the website, make your
modifications and put the modified version on the files upload section
of our mpir-devel group.
2. Using svn, check out our repository, make your changes, then
either commit to the repository if we give you write access, or send
us a diff.
3. Using git, check out the repository, make your changes, then
either send us a patch bundle or share your changes with other
developers (git is distributed revision control, so you do not need to
check in through a central repository to share your patches with other
developers).
Some developers have expressed an interest in HG. If you are a
potential developer and would prefer to see us use HG then PLEASE let
us know. We are not tied to a particular system, we've just been using
whatever is convenient and whatever current developers want to use.
Q. What does it mean that MPIR is developer friendly?
A. We have a zero tolerance policy with respect to being rude to
developers and users, especially new or potential ones. We do all we
can to answer questions and to do so publicly in a polite manner.
Sometimes some users just shouldn't be writing software, but don't
discount the possibility that such people could become our most
supportive fans or our most valuable contributors. Making it easy for
people to contribute is the number one priority.
Q. What is this on the GMP website about MPIR being an "angry fork"
and a bunch of "frustrated developers" with "anti-GMP sentiments".
A. Ask them. Come on, if we were anti-GMP would we have bothered to
use their code as a base for MPIR? As for being "frustrated
developers", comments like that just make me frustrated. And as for
being an "angry fork", that comment just makes me see red! Argggh!!!
Q. Why did MPIR fork GMP?
A. The right to fork is one of the protected freedoms of open source
software! Obviously we think a lot of the GMP project to bother
forking it in the first place. So, technically we forked GMP because
the code is good code and we wanted to take it in a different
direction. There were also serious differences of opinion over certain
issues. We believe parallelism is important, that full Windows support
is important, we believe proprietary operating systems should be
supported, including Apple and Solaris. One significant issue we had
with the GMP project at the time of the fork was the fact that their
repository was not publicly accessible. We applaud them in making
their repository open since that time. Obviously the licensing and
copyright assignment issues played a significant role in the final
decision to fork.
Q. Do we share ideas with the GMP developers?
A. Indirectly, yes. Anyone discussing development ideas on our lists
is doing so publicly. Similarly when ideas are discussed on the GMP
lists, that is public. Licenses control copyrighted material, i.e.
code, the expression of ideas, but not ideas themselves. Some
developers post to both GMP and MPIR lists. We support the sharing of
ideas with the GMP developers.
Q. Will MPIR ever merge again with GMP?
A. This is perhaps impractical. Firstly the licensing and copyright
assignment issues would have to be resolved. That's not impossible.
The Free Software Foundation may issue a version 4 of the LGPL at some
future date which is more widely accepted. But the real issues would
be technical, as the code is diverging at an ever increasing pace.
Maintaining compatibility with GMP at an interface level is a firm
goal of the MPIR project, but for example all our x86_64 assembly code
is in yasm format, not gas format. Features like parallelism affect
the whole library and are not just a series of files added to the
project. GMP/MPIR has an exceedingly complicated build system. It may
be months of work to reconcile them after diverging for some time.
Having said all that, anything is possible and nothing should be ruled
out.
Q. How does MPIR compare to GMP performance wise.
A. We may from time to time publish benchmarks. How we fare depends on
what day you do the comparison and in some cases on what system. Look,
we aren't trying to avoid the question. At the time of writing our
multiplication code is as far as we know faster on virtually all
x86_64 platforms, in some cases quite noticeably so. But it is a vague
question. Do you want Windows support? Then if you have a 64 bit
machine, you are in luck. MPIR works with MSVC and gives you excellent
performance. If you want to build GMP on 64 bit Windows then likely
you'll find Brian Gladman's page, and you'll discover that he offers
the MSVC build projects for MPIR. So on 64 bit Windows you better use
MPIR. But at the time of writing, we are behind on Itanium (though
this is very likely to change - one developer has started work). Again
if you look to the future, it is obvious that parallelism is the way
of the future. We are working on that. So the likelihood is MPIR will
outperform single core GMP at least for larger operations by a
considerable margin in the very near future. I can certainly confirm
the core devs are addicted to speed.
Q. How can I make my code more suitable for inclusion in MPIR.
A. That depends on the developer. We value ALL contributions and we'll
give each piece of code serious consideration. Sometimes code can be
merged as is, other times it needs significant rewriting.
We prefer code written in the style of existing MPIR functions. In
particular use the MPIR memory allocation functions, not malloc and
free, if you are skilled at writing code at the mpn level then it can
help, though an mpz level contribution is better than none at all. Do
make use of the various macros available for development. Use the mpir
types rather than C types, e.g. use mp_limb_t instead of unsigned
long, mp_size_t for counts of limbs instead of int or long. Don't use
C99 code. Use yasm for x86 assembly code rather than gas. Do write
test functions for the test suite if you know how. Follow the advice
in developer documentation in doc/devel with regard to adding files to
mpir. Make sure your code will work on 32 and 64 bit machines. Do test
your code exceptionally thoroughly. There is much advice that could be
given, and again, a beginning contribution is always better than none
at all. As we do not tolerate rudeness to new developers, you will
always be given friendly advice and largely positive constructive
feedback.
Above all, discuss with us what you are writing. That way we can give
specific advice along the way which is more likely to result in code
that gets included.
Q. Does MPIR practice code review.
A. The core developers look over each other's code, but there is no
process of formal code review. If it becomes difficult to keep track
of all code contributions to MPIR due to the large number of
developers, we will certainly implement formal procedures for this. At
this time it is done informally. Code is extensively tested in MPIR
for both performance and correctness, so it is difficult for bad code
to pass muster. But usually someone will help out if your code is not
up to snuff.
Q. How else can I contribute other than write code?
A. Ideas are probably even more important. Discuss them on our
mpir-devel list. Financial contributions are also welcome. There are
MPIR developers who could do more if they were able to be paid for it.
If you work at a company interested in MPIR, donations of financial
resources and hardware are gratefully accepted. If you have exotic
machines on which you can regularly test MPIR, that is a significant
way of contributing. Promoting and using MPIR are also significant
ways of helping.
Q. Why two development lists, mpir-devel and mpir-dev?
A. Essentially some people like to keep track of mpir development,
specifically high level ideas and algorithmic improvements, but don't
care about every little piece of too'ing and fro'ing that goes into
implementation. So mpir-devel is for high level ideas and algorithms,
announcements, calls for testing and the like. But once a discussion
gets into the real nitty gritty of actual implementation details it
should migrate to mpir-dev.
Important: there are no hard and fast rules. Post where you like. But
just remember that people subscribed to mpir-devel do not expect
threads that have 10 posts a day unless it is a discussion about a
really important new algorithm or idea. It's intended to be a much
lower volume list with a much higher signal to noise ratio! On the
other hand, if it isn't about the nitty gritty of implementation
detail, probably it *should* be on mpir-devel.
Currently announcements and user support is also done on mpir-devel.
That is likely to change with the introduction of mpir-announce and
mpir-support, but as of the time of writing these do not exist yet. In
the mean time please feel free to post user questions on mpir-devel.
Comments? Questions? Corrections? Additions?
Jeff Gilchrist
> ************ AN FAQ **************
The FAQ is a great idea and you are off to a good start.
> ************** FORTNIGHTLY MPIR DIGEST ****************
I think this is a really good idea, makes it easy for people not doing
active development to still keep on top of things and changes
happening.
I had a question about the parallel support, I think I remember seeing
that OpenMP would be supported, what about pthreads, will that be
supported as well?
Jeff.
Bill Hart
much older compilers. But the issue is, it is very hard to code.
Essentially OpenMP does all the hard work for you, keeping threads
alive when they are not in use, managing all the pointers to your
data, etc.
I'd be interested in supporting pthreads if there was some performance
benefit from doing so, but I actually think OpenMP is pretty good.
I recall when parallelising using pthreads problems with about 500x500
= 250000 bits of data, or perhaps a little less, could be effectively
parallelised. We are currently parallelising stuff effectively with
128000 bits of data.
In other words, there doesn't seem to be any immediately obvious
performance reason to consider pthreads.
What do you think?
Bill.
2009/7/2 Jeff Gilchrist <jeff.gi...@gmail.com>:
Jeff Gilchrist
> That is an interesting question. pthreads is certainly available on
> much older compilers. But the issue is, it is very hard to code.
I guess it is the only thing I know, so maybe I should move to OpenMP. ;-)
> I'd be interested in supporting pthreads if there was some performance
> benefit from doing so, but I actually think OpenMP is pretty good.
>
> I recall when parallelising using pthreads problems with about 500x500
> = 250000 bits of data, or perhaps a little less, could be effectively
> parallelised. We are currently parallelising stuff effectively with
> 128000 bits of data.
>
> In other words, there doesn't seem to be any immediately obvious
> performance reason to consider pthreads.
From a performance perspective, I have no idea. I was thinking more
from a support perspective. Pthreads is available on every system
under the sun (except MSVC natively). I haven't looked lately but do
any compilers come with OpenMP support built-in? I'm not sure how
easy it will be to get OpenMP working in MSVC (which doesn't really
support pthreads either so might have to make a Windows threads
version anyways). If OpenMP is widely supported now then it would
probably make more sense just to support one, the one that is easier.
Jeff.
Bill Hart
because ultimately there is no point writing parallel code for very
old machines and newer machines will have newer compilers. If you are
really serious about performance and using multi core machines, you
are probably going to own a modern machine with the latest compiler.
Of course it will always be possible to build MPIR in single core
mode, which will be the default, so it is not like we are making a
recent gcc a prerequisite to build MPIR.
In particular gcc 4.2.4 and following have OpenMP support built in.
That means all the compilers which are derivatives of gcc will fairly
shortly have OpenMP support if they don't already. Certainly the Intel
compiler supports OpenMP and has for quite some time.
As you say, the main issue is MSVC, which doesn't even have pthreads.
Perhaps Brian knows whether VS 2010 will have OpenMP support?
Jeff Gilchrist
> In particular gcc 4.2.4 and following have OpenMP support built in.
> That means all the compilers which are derivatives of gcc will fairly
> shortly have OpenMP support if they don't already. Certainly the Intel
> compiler supports OpenMP and has for quite some time.
Certainly if modern gcc has support for OpenMP built-in that would
make it very wide spread for modern hardware.
Jeff.
Cactus
On Jul 2, 3:49 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> Support for parallel processing can make demands on people's compiler,
> because ultimately there is no point writing parallel code for very
> old machines and newer machines will have newer compilers. If you are
> really serious about performance and using multi core machines, you
> are probably going to own a modern machine with the latest compiler.
> Of course it will always be possible to build MPIR in single core
> mode, which will be the default, so it is not like we are making a
> recent gcc a prerequisite to build MPIR.
>
> In particular gcc 4.2.4 and following have OpenMP support built in.
> That means all the compilers which are derivatives of gcc will fairly
> shortly have OpenMP support if they don't already. Certainly the Intel
> compiler supports OpenMP and has for quite some time.
>
> As you say, the main issue is MSVC, which doesn't even have pthreads.
> Perhaps Brian knows whether VS 2010 will have OpenMP support?
>
> Bill.
>
>
>
> > On Thu, Jul 2, 2009 at 10:22 AM, Bill Hart<goodwillh...@googlemail.com> wrote:
>
> >> That is an interesting question. pthreads is certainly available on
> >> much older compilers. But the issue is, it is very hard to code.
>
> > I guess it is the only thing I know, so maybe I should move to OpenMP. ;-)
>
> >> I'd be interested in supporting pthreads if there was some performance
> >> benefit from doing so, but I actually think OpenMP is pretty good.
>
> >> I recall when parallelising using pthreads problems with about 500x500
> >> = 250000 bits of data, or perhaps a little less, could be effectively
> >> parallelised. We are currently parallelising stuff effectively with
> >> 128000 bits of data.
>
> >> In other words, there doesn't seem to be any immediately obvious
> >> performance reason to consider pthreads.
>
> > From a performance perspective, I have no idea. I was thinking more
> > from a support perspective. Pthreads is available on every system
> > under the sun (except MSVC natively). I haven't looked lately but do
> > any compilers come with OpenMP support built-in? I'm not sure how
> > easy it will be to get OpenMP working in MSVC (which doesn't really
> > support pthreads either so might have to make a Windows threads
> > version anyways). If OpenMP is widely supported now then it would
> > probably make more sense just to support one, the one that is easier.
>
> > Jeff.
Visual Studio 2008 supports OpenMP 2.0; Visual Studio 2010 supports
OpenMP 3.0
I have used pthreads on MSVC in the past but given the native support
for OpenMP, I dropped support for pthreads about two years ago.
Brian
Jeff Gilchrist
> MSVC has had OpenMP support for some time now.
>
> Visual Studio 2008 supports OpenMP 2.0; Visual Studio 2010 supports
> OpenMP 3.0
Nice! I learned two new things today, built-in support for OpenMP in
both gcc and MSVC. If only that was available when I was doing my
Masters...
Jeff.
Bill Hart
on the GMP website about MPIR, and also to address Jeff's questions
about parallel support in MPIR:
Frequently Asked Questions
-----------------------------------------
Q. What is MPIR?
Q. What distinguishes MPIR?
Q. What is this on the GMP website about MPIR users having to deal
with FUD against GMP.
A. This is about the fourth version of negative comments made on their
website about our project. You can see the others in google's cache or
probably on the internet archive, though the first version probably wasn't
there long enough. The word FUD is an abbreviation for Fear, Uncertainty,
Doubt. It is used by marketing people to describe a method of alarming
potential customers about aspects of a competitor's product instead of
pointing out positive benefits of their own product. I've carefully reviewed
the MPIR website and this FAQ and I do not see any FUD against GMP.
In fact on the website we only say, "MPIR is an open source multiprecision
integer library derived from version 4.2.1 of the GMP (GNU Multi Precision)
project (which was licensed LGPL v2+)." Oh well, better luck fifth time
around....
C99 code (in particular all variable declarations must be done at the
beginning of a block, including counters used in for loops). Use yasm
Q. What parallel support will be available in MPIR?
A. At this stage we plan to support the following - (a) OpenMP support
for at least large multiplications. All recent gcc versions have built in
support for OpenMP, as does the Intel compiler and MSVC. (b) Cell
support. This processor is used in the Playstation 3 and has SPE cores
which can be used in parallel. (c) CUDA and OpenCL support. Snow
Leopard will have OpenCL support and NVIDIA's CUDA seems to have
gained considerable support. We'll probably eventually have higher level
stuff in OpenCL and lower level assembly routines in NVIDIA and ATI's
graphics card assembly code. (d) Although not that different from the
other graphics assembly code, Intel's Larrabee instruction set looks
interesting. We will of course support that at the earliest opportunity.
Q. When will parallel support be shipped with MPIR?
A. The next version of MPIR will contain parallel routines implemented
with OpenMP. It will give significant performance benefits across the
library for operands of about 2000 limbs and above with relatively
efficient use of compute resources on machines with at least three cores.
As we get better at parallel support we hope to support machines with
more cores. For extremely large operands (10's of thousands of limbs)
there will be a significant speedup on two core machines in the next
version.
Bill
2009/7/2 Bill Hart <goodwi...@googlemail.com>:
Frithjof Schulze
> ...
> Sage, FLINT, Pari, NTL, Givaro, Gap, Singular, M4RI and numerous other
> major open source mathematical projects have remained LGPL v2+.
>
> Continuing to remain with LGPL v2+ is a strategic step for MPIR, and
> we will revisit the issue should it become a hindrance to the project.
I don't know if this matters much but at least Pari and M4RI are under
the GPL instead of the LGPL so this should probably say "remained LGPL
or GPL v2+"
--
Frithjof Schulze
Bill Hart
Thanks for mentioning it.
Bill.
2009/7/17 Frithjof Schulze <frithjof...@uni-jena.de>: