I was just about to reply that OpenMP is supported in MSVC. I wouldn't have suggested it for MPIR otherwise as it wouldn't build. icc is free for non-commercial use on Linux, which this constitutes, and supports OpenMP too. However, I think it does some funny business with binaries i.e. optimising them per intel chipset and defaulting amd chips to the slowest, so maybe this is a nice to have rather than a most? Unless that feature can be disabled. I will download it again and look into it.
Available from: http://software.intel.com/en-us/articles/non-commercial-software-development/ Digital Mars is a free C/C++ compiler for Windows. I don't think many people use it, but I have in the past. In truth, I've no idea what it is like, really, I just thought wide support would be better than targeting say just gcc. (http://www.digitalmars.com/) I actually don't mind following any coding style... the GNU convention isn't my favourite but at the end of the day it's all C/C++/Assembly anyway, there's not much in it. Names was a bit of poor humour on my part. What it's called really doesn't matter - however, I think calling it mpir-something will be confusing, just as if we called mpir gmp-x, especially as this will be a near ground-up re-write. Hey, this is a debate for later stages though. I could look at the build system and see what I can come up with for an arch system? I can also admin a git repository on my vps if people want to, or we could use github or somewhere else. No matter, I can admin it if that is needed (to be honest once you've done git init --bare and git update-server-info there's not much else to do). Antony On 04/12/2010 11:16 PM, Bill Hart wrote: > Brian points out that MSVC has openMP support. As it is just pragmas > it'll be ignored by PCC (so long as we don't call OpenMP functions). > So yeah, why not. Let's fill the code with pragmas. > > So we should target pcc, gcc, MSVC and possibly icc. > > Six problems we have right off: > > * no longlong.h (so far I only use count_leading_zeros though) > * no TMP_ALLOC function > * no timing code (I suggest we use Dan Bernstein's library for this). > * no test framework > * no tuning framework > * no arch framework for assembly in my magic build system > > And all this is dependent on whether Jason Moxham is interested in > licensing his assembly BSD. We can't get within 50% of MPIR/GMP > without it. > > Bill. > > On 12 April 2010 23:05, Bill Hart <goodwillh...@googlemail.com> wrote: >> On 12 April 2010 21:04, Antony Vennard <antony.venn...@gmail.com> wrote: >>> Yes. >>> >>> Can we manage it with git? Is there a git repo already...? >> >> There's no git repo yet. But yes, we have to manage it with git. svn >> is too limiting. >> >> But we'd need to give very careful thought to how we do Windows >> support (git doesn't work very well on Windows GUI). >> >>> Can I write #pragma omp declarations all over it? I.e. can I start >>> parallelising things early on? >> >> This conflicts with one of your goals below. The only compilers which >> support OpenMP that I am aware of are the Intel compiler and GCC >> basically. Probably MSVC supports pthreads, not sure about OpenMP. >> >>> I'll license all contributions on MPIR as >>> BSD which is easily compatible with LGPLv3 then I'm good, really, >>> providing I don't duplicate any existing MPIR work. I shall be very >>> careful not to. >>> Can we make it build under various compilers i.e. pcc, gcc, icc, cl, >>> digital mars c etc? >> >> I think it is terribly important to target pcc and gcc, as you will >> get a lot more interest from BSD devels if you do that. I've never >> used icc personally, but I will be buying a copy some time soonish. So >> long as it does most of what gcc does, I don't see why not. I don't >> know anything about the others. I won't be buying copies. >> >> The main aim has got to be to get something working within 6-12 >> months. That means really restricting our goals. And that means not >> getting distracted with unimportant laundry lists of goals. Usually >> you find that if someone has an interest in doing something, they'll >> pop up and offer to do it. Just take them up on it when it happens, so >> long as it doesn't slow the whole project down. >> >> Can we get something working in 6-12 months. Yes we can, if we choose >> our goals carefully. >> >>> Obviously we might have to duplicate effort >>> sometimes, but one of my feelings for gnu software is that it can only >>> be compiled by gcc and I don't like that, or more specifically I don't >>> like being tied to one way of working should I want to change. >>> Can we not use the GNU coding style? The only reason for suggesting this >>> is I don't like it, there's no actual technical merit to it. I prefer >>> things with lots of braces in, 4-space tab width, functions all on one >>> line... you'll see when I start committing. >> >> Everyone has their preferred coding style. We'd have to agree on one, >> and it should be clear and readable. >> >>> >>> What's it gonna be called? >> >> I don't really care. So far I've had it called mpzz, libnt, mpir-bsd, >> flint3 and probably other things. I got sick of all of these pretty >> quick. >> >> I've already had far more off list interest in this idea than anything >> else we've floated. I'm leaning more and more towards actually doing >> it. >> >> Anything we come up with that is actually better than MPIR, we can >> insert into MPIR (so long as we keep the interface compatible enough), >> as BSD licensed code is still compatible with LGPL v3+. >> >> Bill. >> >> >>> >>> Antony >>> >>> On 04/12/2010 08:47 PM, Bill Hart wrote: >>>> Rather than talk about hypothetical code I wrote when I was thinking >>>> of producing BSD licensed library, I may as well expose it: >>>> >>>> http://sage.math.washington.edu/home/wbhart/mpir-bsd/ >>>> >>>> It has a magic makefile system such that if you drop files in, they >>>> just build automatically. >>>> >>>> Simply do make check to make it work (you have to edit the top level >>>> makefile to specify the location of MPIR and export LD_LIBRARY_PATH >>>> for MPIR and the top level source directory for this library). >>>> >>>> It is about the same speed as MPIR for multiplication up to about 100 >>>> limbs. Everywhere it was necessary to use assembly language, I just >>>> called MPIR, but these functions could be used in this library >>>> directly. >>>> >>>> Here's what I'd do if I were going to write a BSD library: >>>> >>>> For the first 6-12 months: >>>> >>>> * x86_64 only >>>> * linux, Windows and FreeBSD only >>>> * mpn layer only (what I've called nn) - the interface already exists, >>>> so work to it!! >>>> * no autotools >>>> * aim for performance within 20% of GMP/MPIR for everything up to 100 limbs >>>> * target PCC not GCC (a very clean and efficient BSD compiler which >>>> also works on Windows - trivial to port to Win64) >>>> * aim to have 5 regular committed contributors with 2 people able to >>>> manage releases by the end of 12 months >>>> * set up a donations system on the website with the aim of hiring >>>> contractors to address prespecified "bounties" >>>> * aim for the greatest possible simplicity of design, with performance >>>> a *secondary* goal >>>> * get the software architecture right from the start >>>> * very careful auditing of code for license, documentation and style >>>> (for the latter run it through indent) >>>> >>>> If it is judged a success at the 6 and 12 month stages, move the >>>> project forward and allow the goals to expand. >>>> >>>> Anyone interested? >>>> >>>> Bill. >>>> >>>> On 12 April 2010 14:57, Pierre Joye <pierre....@gmail.com> wrote: >>>>> hi Bill, >>>>> >>>>> Thanks for the extensive reply, very much appreciated. >>>>> >>>>> On Mon, Apr 12, 2010 at 1:55 PM, Bill Hart <goodwillh...@googlemail.com> >>>>> wrote: >>>>> >>>>> >>>>>> On 12 April 2010 11:18, Pierre Joye <pierre....@gmail.com> wrote: >>>>> >>>>>> The main appeal is that we can use code from GMP without replicating >>>>>> their efforts and accept code from developers who want to license >>>>>> their code v3+. It basically means less effort for us, and faster >>>>>> development times. It means that the bignum community is using a >>>>>> single license and is less fragmented. >>>>> >>>>> It makes sense, however I wonder if it is good for mpir users. But it >>>>> makes the work easier for mpir developers, that's a sure thing. >>>>> >>>>> I will have to split my reply as it is a rather large topic. >>>>> >>>>>> By "not compatible with the GPL", I assume you mean that you want to >>>>>> distribute PHP under terms that are more permissive than the GPL will >>>>>> allow. >>>>> >>>>> The GPL does not allow any GPL code to be linked with PHP Licensed >>>>> code, at least this restriction up to v2. For v3 there is a debate >>>>> about "linkage" and "usage" as in using GPL code in an external >>>>> process (calling a cmd line tool for example). But the whole v3 move >>>>> (gpl and lgpl) creates a lot of troubles lately for companies and >>>>> other OSS projects. The "or later" clause has also been ignored in the >>>>> past, but the v3 shows the implications and the direction the gpl >>>>> license takes is scary (no offense meant, only writing down my feeling >>>>> about the GPL movement for the last decade). >>>>> >>>>> Short reply but other will come in the next days :) >>>>> >>>>> Cheers, >>>>> -- >>>>> Pierre >>>>> >>>>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "mpir-devel" group. >>>>> To post to this group, send email to mpir-de...@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. >>>>> >>>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mpir-devel" group. >>> To post to this group, send email to mpir-de...@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. >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@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.
