Here is an updated FAQ with some changes based on suggestions made in 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? Bill. 2009/7/1 Bill Hart <goodwillh...@googlemail.com>: > Actually two more before I go: > > 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. > > > > 2009/7/1 Bill Hart <goodwillh...@googlemail.com>: >> I have 8 minutes before I need to go out again, so here is 8 minutes >> 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 <goodwillh...@googlemail.com>: >>> Hi all, >>> >>> 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. >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
