Re: [mpir-devel] Building MPIR on Raspberry Pi (64-bit)

['Bill Hart' via mpir-devel]

I don't have any insight into the Raspberry Pi build environment.
However there are a lot of errors related to M4 there. Can you ensure
this is installed.

On the other hand it looks like the autoconf version you have just
isn't compatible somehow. Unfortunately I have no way to debug this.
It certainly works just about everywhere else.

Bill.

On Thu, 17 Mar 2022 at 21:34, Gregory Warnes
 wrote:
>
> Hi,
>
> TLDR:
>
> I want to use a GnuRadio package (gr-ofdm) that depends on mpir on Raspberry 
> Pi OS (64-bit).  './autogen.sh` using git://github.com/wbhart/mpir.git fails, 
> and I see a number of forks, as well as the package files on the `download` 
> page. What is the best version to use?
>
> Details:
>
> As recommended on the project web page (http://mpir.org/downloads.html), I 
> tried building from git://github.com/wbhart/mpir.git.  Unfortunately, the 
> build instructions in INSTALL are outdated, since there is no `configure` 
> script in the repo.
>
> I eventually located this group, and learned that I should use `autogen.sh`, 
> however this results in numerous errors (see below).
>
> Suggestions?
>
> -Greg
>
> ---
>
> src/mpir $ ./autogen.sh
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> configure.ac:2838: warning: AC_LIBTOOL_PROG_COMPILER_PIC is m4_require'd but 
> not m4_defun'd
> acinclude.m4:2193: GMP_ASM_X86_GOT_UNDERSCORE is expanded from...
> configure.ac:2838: the top level
> configure.ac:2841: warning: AC_ENABLE_SHARED is m4_require'd but not 
> m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> configure.ac:2841: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> autoreconf: configure.ac: tracing
> configure.ac:2838: warning: AC_LIBTOOL_PROG_COMPILER_PIC is m4_require'd but 
> not m4_defun'd
> acinclude.m4:2193: GMP_ASM_X86_GOT_UNDERSCORE is expanded from...
> configure.ac:2838: the top level
> configure.ac:2841: warning: AC_ENABLE_SHARED is m4_require'd but not 
> m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> configure.ac:2841: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /usr/bin/autoconf
> configure.ac:2838: warning: AC_LIBTOOL_PROG_COMPILER_PIC is m4_require'd but 
> not m4_defun'd
> acinclude.m4:2193: GMP_ASM_X86_GOT_UNDERSCORE is expanded from...
> configure.ac:2838: the top level
> configure.ac:2841: warning: AC_ENABLE_SHARED is m4_require'd but not 
> m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> configure.ac:2841: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd
> acinclude.m4:2507: GMP_ASM_X86_MCOUNT is expanded from...
> configure.ac:2841: the top level
> configure:11014: error: possibly undefined macro: AC_PROG_NM
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> configure:14468: error: possibly undefined macro: AC_LIBTOOL_PROG_COMPILER_PIC
> configure:14563: error: possibly undefined macro: AC_ENABLE_SHARED
> configure:14564: error: possibly undefined macro: AC_PROG_LIBTOOL
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/de347f03-715d-42bc-aa15-7e7b3aea2d01n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnspn%3Dt_1F88ANdebT3H%3DcP72drhCKgOemb%3D5sp92s7BtQ%40mail.gmail.com.

[mpir-devel] Re: MPIR status and 'raison d'être'

['Bill Hart' via mpir-devel]

I might mention that, as far as I know, Brian Gladman still maintains a 
version of MPIR on Windows. You can check his home page for information on 
this.

http://ccgi.gladman.plus.com/oldsite/computing/gmp4win.php

On Friday, 24 December 2021 at 05:54:50 UTC+1 Bill Hart wrote:

> MPIR is no longer maintained for years now.
>
> You would have to ask the maintainer(s) of GMP about "merging 
> developments" back into GMP; we have no say in that. I doubt they would be 
> interested. Either way, there are no plans to do so.
>
> On Friday, 24 December 2021 at 05:50:02 UTC+1 fabio.c...@gmail.com wrote:
>
>> Hi all, I have asked about the development and support status of MPIR on 
>> StackOverflow, but no answers from there, so It was suggested to me to ask 
>> here.
>>
>>
>> https://stackoverflow.com/questions/70430445/mpir-status-and-raison-d%c3%aatre
>>
>> I ask for what were the reasons to branch from GMP in the first place, 
>> and if there's functionality (besides running on Windows) in MPIR that is 
>> not in GMP.
>>
>> My point is, given all effort put into MPIR, did you ever consider to 
>> merge back important developments of MPIR into GMP?
>>
>> Thanks,
>> Fabio
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/d2761776-a148-4d52-a6de-3a24b503a3c6n%40googlegroups.com.

[mpir-devel] Re: MPIR status and 'raison d'être'

['Bill Hart' via mpir-devel]

MPIR is no longer maintained for years now.

You would have to ask the maintainer(s) of GMP about "merging developments" 
back into GMP; we have no say in that. I doubt they would be interested. 
Either way, there are no plans to do so.

On Friday, 24 December 2021 at 05:50:02 UTC+1 fabio.c...@gmail.com wrote:

> Hi all, I have asked about the development and support status of MPIR on 
> StackOverflow, but no answers from there, so It was suggested to me to ask 
> here.
>
>
> https://stackoverflow.com/questions/70430445/mpir-status-and-raison-d%c3%aatre
>
> I ask for what were the reasons to branch from GMP in the first place, and 
> if there's functionality (besides running on Windows) in MPIR that is not 
> in GMP.
>
> My point is, given all effort put into MPIR, did you ever consider to 
> merge back important developments of MPIR into GMP?
>
> Thanks,
> Fabio
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/2e67ce0c-fb01-479f-a293-d1a99334c28cn%40googlegroups.com.

Re: [mpir-devel] mpz_pow_ui exp argument

['Bill Hart' via mpir-devel]

Yeah it does actually sound suspect. There must be a bug in the pow_ui function.

On Mon, 12 Apr 2021 at 19:28, ErichSt  wrote:
>
> > There is a limit on the size of the exponent of an mpz itself.
>
> Sure ... but I thought you had said this limit was "2^37 on a 64 bit 
> machine".  Did I misunderstand?
> In above example the resulting exponent would be just 2^32.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/263c2734-a66a-4aea-b0d6-d9de48f6525dn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntrLgcUAWUh1mz4UFjcQ4p%3DmwEeeoX5my9-jad60KjWBA%40mail.gmail.com.

Re: [mpir-devel] mpz_pow_ui exp argument

['Bill Hart' via mpir-devel]

There is a limit on the size of the exponent of an mpz itself.

A 64 bit build refers to the size of the limbs used in the
multiprecision integers, not the size of the exponents in an mpz,
which is set by GMP.

On Mon, 12 Apr 2021 at 17:47, Erich Steinböck
 wrote:
>
> Even on a 64-bit system it seems that the exp argument of mpz_pow_ui cannot 
> be 2^32 or larger.
> To prove this really is a 64-bit build, first n is successfully set to 2^32.
> The second code block tries to calculate 2^(2^32) but apparently calculates 
> 2^0 instead.
>
> Is this intended or a bug?
>
> ~~~
> mpir_ui two32 = 65536ULL * 65536;
> mpz_t   n;
>
> mpz_init(n);
> mpz_init_set_ui(n, two32);
> // correctly prints: init_set_ui 4294967296 10
> printf("init_set_ui %zd %zd\r\n", two32, mpz_sizeinbase(n, 10));
>
> mpz_set_ui(n, 2);
> mpz_pow_ui(n, n, two32);
> // because 2^0 equals 1 this prints: mpz_pow_ui 4294967296 1
> printf("mpz_pow_ui %zd %zd\r\n", two32, mpz_sizeinbase(n, 10));
> ~~~
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/CAB8Mfh0XroFTd_%3Dc5O6HDteS9KE9mCMsTnny9jSd%3DyJFZxejRA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntpo1vNJ3NGq_C3d7zYRd8s%3DdM%3DYzX87uOMbvo%2BrqGF0g%40mail.gmail.com.

[mpir-devel] Flint 2.7.1 released

['Bill Hart' via mpir-devel]

Hi all,

I have just released flint-2.7.1. This fixes a number of (serious)
bugs and build issues with the recent flint-2.7.0.

A list of changes can be found in our NEWS file [1].

Please report any bugs to our GitHub issue tracker.

Best Wishes,

Bill.

[1] https://github.com/wbhart/flint2/blob/trunk/NEWS

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnv6XgZc85ZT52iypB4O3iJj1jM%2B3cX5xxy-oSEd0kDbyA%40mail.gmail.com.

[mpir-devel] Flint 2.7.0 Released!

['Bill Hart' via mpir-devel]

Hi all,

It is with pleasure that we release Flint 2.7.0. available at our
GitHub [1] and Website [2]. Documentation is available at [3]. Brian
Gladman also maintains MSVC solution files at [4].

New Improvements
===

The main improvements in this release are:

 * Multivariate factorisation
 * Square root and square testing for finite fields
 * Square root and square testing for multivariates
 * Zassenhaus factoring speedups (incl. degree pruning)
 * Fast factorisation of cubic univariate polynomials
 * Add context objects to fmpz_mod_poly functions
 * Use BLAS for matrix multiplication over Z/nZ (small n)
 * Linear solving for non-square/singular matrices (can_solve)
 * Speed up factorisation over Z/nZ (for multiprecision n)

Deprecations
==

The following are deprecated from the previous release:

n_gcd_full -> n_gcd
fmpz_poly_is_x -> fmpz_poly_is_gen
fmpz_mod_poly_is_x -> fmpz_mod_poly_is_gen
fmpq_poly_is_x -> fmpq_poly_is_gen

They will be removed shortly.

In addition, the following function has been deprecated

nmod_mat_scalar_mul_add (please use nmod_mat_scalar_addmul_ui instead).

Backwards incompatible changes
==

As promised, we have introduced a context object for the fmpz_mod_poly
module. All functions in this module now take an additional context
object.

Note that the fmpz_mod_mat module will get a similar update in the
not-too-distant future!

Contributors
==

The main contributors to this release were:

* Daniel Schultz
* William Hart

Additional contributions were made by:

Matthias Koeppe, Vincent Delecroix, Tommy Hofmann, Debian User, Max
Horn, Isuru Fernando, Fredrik Johansson, Jan Engelhardt, Ivan Tsybulin
and Mahrud Sayrafi.

Once again thanks to all the very many contributors to the Flint project!

The Flint Development Team

[1] https://github.com/wbhart/flint2/releases/tag/v2.7.0
[2] https://flintlib.org/
[3] https://flintlib.org/doc
[4] https://github.com/BrianGladman/flint

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnuLaZN3wx%2BGVvJOFP-2yjK6CRsggetyw4JKeQVxFq2mtA%40mail.gmail.com.

Re: [mpir-devel] Limits of mpz_t size

['Bill Hart' via mpir-devel]

No it's 2^37 on a 64 bit machine. This is due to the 32 bit type used
for the limb count in the mpz_t struct.

If you want to use larger integers, use the mpn functions as I explained.

On Tue, 27 Oct 2020 at 05:58, Gaj Satha  wrote:
>
> Is it correct in saying that these limits (41 billion) is related to 
> sizeof(int) = 4?
>
> My machine has sizeof(int) = 8, so I can allocate much more than 4GB using 
> malloc. Will I still suffer from this limit of I can go much beyond it?
>
>
> On 3/10/20 1:57 AM, 'Bill Hart' via mpir-devel wrote:
>
> The limits in MPIR are the same.
>
> In order to get around the limit, you can use the mpn layer of functions.
>
> On Tue, 10 Mar 2020 at 09:56, Gaj Satha  wrote:
>>
>> Hi:
>>
>> Are there any limits on the size of mpz_t in MPIR (Other than availble 
>> memory)?
>>
>> I came to know that GNU GMP had limit of 41 billion on mpz_t sometime back 
>> (as per https://gmplib.org/list-archives/gmp-discuss/2016-July/006013.html), 
>> which they plan to remove but I don't know if it has been removed.
>>
>> Please let me know. I need to calculate digits to 50 trillion.
>>
>> Gaj
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/mpir-devel/6a7df5d9-d3cb-451e-a249-d8ec5c309c21%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/CAB0xFntteZYVVGSeK0UKe-hch8p%3DG25Oczp6_B2Jm-_segyQKg%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/b4a3cdaf-ee75-a07b-2d48-314c2f3ed241%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnuh6pjhyrQyMoRJzy5N7t7G1GHiaULtnou7P_8o71pOFQ%40mail.gmail.com.

Re: [mpir-devel] strange behavior about mpf_t

['Bill Hart' via mpir-devel]

On Mon, 10 Aug 2020 at 10:48, wei zhao  wrote:
>
> em, i just hope mpir tries to add 0s at the end when conversion.

It doesn't add *anything* at the end. There is nothing after the end.
Once you reach the limit of the precision, there is no further data
after that point.

Finite precision means there's a finite number of bits. There's
nothing after those bits. Only finitely many bits are stored.

>
> i tried mpf_set_str(), it seems give me correct result.

It will give you the nearest approximation to the decimal value using
the the precision you set.

mpf is NOT a decimal system, it is a binary system. I think you are
confused about this. There is no exact conversion between fractional
decimal numbers to a given (decimal) precision and fractional binary
numbers to a given (binary) precision. The precision in mpf is a
BINARY precision, not a decimal one. You can lose information
converting between decimal and binary! That has nothing to do with
mpf. It is a feature of the mathematics itself.

The random digits you see are because you lost information converting
from decimal to binary and back again. mpf does not store the decimal
number. It stores a binary approximation. So when you convert back to
decimal, some information is gone and cannot be retrieved.

Think about it, how would YOU write 0.1 decimal in binary? It's not
possible in a finite number of bits.

Bill.

>
> wei.
>
>
> 在 2020年8月10日星期一 UTC+8下午4:24:43，Bill Hart写道：
>>
>> Correction: integers and powers of 10 with non-negative exponent are
>> exactly representable in binary.
>>
>> On Mon, 10 Aug 2020 at 10:22, Bill Hart  wrote:
>> >
>> > On Mon, 10 Aug 2020 at 10:08, wei zhao  wrote:
>> > >
>> > > thanks Bill.
>> > >
>> > > I am confused. As you said, i can NOT initialize mpf_t via a double, 
>> > > right?
>> >
>> > I did not say that. I said that doubles have 53 bits precision. You
>> > cannot get more precision from mpf if you start with 53 bits of
>> > precision at the input.
>> >
>> > > The reason I turn to multiple-precision is that I hope mpir could 
>> > > provide more precision, double does have 53bit precision, but mpf_z 
>> > > should have more.
>> >
>> > It does allow more precision, but you cannot start with less
>> > information than you want to end up with. mpf is not able to add
>> > precision that wasn't there to start with. The information was already
>> > lost in the conversion of 0.1 decimal to a double (binary). This
>> > happened before mpf even got the value.
>> >
>> > >
>> > > if so, mpir is not more accurate than double, because it adds some 
>> > > random numbers at the end, which will affect the computation result.
>> >
>> > No it does not "add random numbers". This is what 0.1 looks like to 53
>> > bits of precision, which is precisely what you passed into the mpf
>> > function. It stored exactly what you gave it.
>> >
>> > >
>> > > any idea to solve this issue？
>> >
>> > I already told you exactly how to solve the issue in my previous post.
>> > Did you try it?
>> >
>> > Decimal fractions aren't always exactly representable in (limited
>> > precision) binary. One way to solve it would be to put in an integer,
>> > then divide by a power of 10. Integers and powers of 10 are exactly
>> > representable in binary.
>> >
>> > Bill.
>> >
>> > >
>> > >
>> > > thanks.
>> > >
>> > >
>> > >
>> > > 在 2020年8月10日星期一 UTC+8下午2:45:56，Bill Hart写道：
>> > >>
>> > >> You are setting it to the double 0.1, which only has 53 bits
>> > >> precision. You can't get more precision than you put in.
>> > >>
>> > >> Try setting it to 0.5 first (which can be represented exactly in
>> > >> binary), and then divide by the integer 5, which is also able to be
>> > >> represented exactly in binary. Then you will get the 128 bits you are
>> > >> after.
>> > >>
>> > >> By the way, the mpf module isn't used much any more. You should look
>> > >> into mpfr (mpfr.org) instead, which is quite often much faster, and
>> > >> has more functionality and development effort.
>> > >>
>> > >> Bill.
>> > >>
>> > >> On Mon, 10 Aug 2020 at 08:32, wei zhao  wrote:
>> > >> >
>> > >> > hi all,
>> > >> >
>> 

Re: [mpir-devel] strange behavior about mpf_t

['Bill Hart' via mpir-devel]

Correction: integers and powers of 10 with non-negative exponent are
exactly representable in binary.

On Mon, 10 Aug 2020 at 10:22, Bill Hart  wrote:
>
> On Mon, 10 Aug 2020 at 10:08, wei zhao  wrote:
> >
> > thanks Bill.
> >
> > I am confused. As you said, i can NOT initialize mpf_t via a double, right?
>
> I did not say that. I said that doubles have 53 bits precision. You
> cannot get more precision from mpf if you start with 53 bits of
> precision at the input.
>
> > The reason I turn to multiple-precision is that I hope mpir could provide 
> > more precision, double does have 53bit precision, but mpf_z should have 
> > more.
>
> It does allow more precision, but you cannot start with less
> information than you want to end up with. mpf is not able to add
> precision that wasn't there to start with. The information was already
> lost in the conversion of 0.1 decimal to a double (binary). This
> happened before mpf even got the value.
>
> >
> > if so, mpir is not more accurate than double, because it adds some random 
> > numbers at the end, which will affect the computation result.
>
> No it does not "add random numbers". This is what 0.1 looks like to 53
> bits of precision, which is precisely what you passed into the mpf
> function. It stored exactly what you gave it.
>
> >
> > any idea to solve this issue？
>
> I already told you exactly how to solve the issue in my previous post.
> Did you try it?
>
> Decimal fractions aren't always exactly representable in (limited
> precision) binary. One way to solve it would be to put in an integer,
> then divide by a power of 10. Integers and powers of 10 are exactly
> representable in binary.
>
> Bill.
>
> >
> >
> > thanks.
> >
> >
> >
> > 在 2020年8月10日星期一 UTC+8下午2:45:56，Bill Hart写道：
> >>
> >> You are setting it to the double 0.1, which only has 53 bits
> >> precision. You can't get more precision than you put in.
> >>
> >> Try setting it to 0.5 first (which can be represented exactly in
> >> binary), and then divide by the integer 5, which is also able to be
> >> represented exactly in binary. Then you will get the 128 bits you are
> >> after.
> >>
> >> By the way, the mpf module isn't used much any more. You should look
> >> into mpfr (mpfr.org) instead, which is quite often much faster, and
> >> has more functionality and development effort.
> >>
> >> Bill.
> >>
> >> On Mon, 10 Aug 2020 at 08:32, wei zhao  wrote:
> >> >
> >> > hi all,
> >> >
> >> > I wrote a simple code to test mpir and found a strange thing.
> >> >
> >> > the code is
> >> >
> >> > mpf_t a;
> >> > mpf_init2(a, 128);
> >> > mpf_set_d(a, 0.1);
> >> >
> >> > mp_exp_t exp;
> >> > char str[256];
> >> > mpf_get_str(str, , 10, 128, a);
> >> > I checked str, and it was "155511151231257827021182" 
> >> > instead of "1000".
> >> >
> >> > anybody knows why? Does not it affect the computation precision?  how 
> >> > can I make the variable more accurate?
> >> >
> >> > thansk a lot
> >> >
> >> > wei
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "mpir-devel" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send 
> >> > an email to mpir-...@googlegroups.com.
> >> > To view this discussion on the web visit 
> >> > https://groups.google.com/d/msgid/mpir-devel/4dca16b4-7b7d-4a16-91c6-834def1f8f97o%40googlegroups.com.
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "mpir-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to mpir-devel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/mpir-devel/22b82e2c-cc4d-4557-9f8d-ce7c434aa5ado%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnvcThye8v%2BP%2Bb%3D8Wnhhmnc90h6OSmMCDGEt9VsFHXjfVA%40mail.gmail.com.

Re: [mpir-devel] strange behavior about mpf_t

['Bill Hart' via mpir-devel]

On Mon, 10 Aug 2020 at 10:08, wei zhao  wrote:
>
> thanks Bill.
>
> I am confused. As you said, i can NOT initialize mpf_t via a double, right?

I did not say that. I said that doubles have 53 bits precision. You
cannot get more precision from mpf if you start with 53 bits of
precision at the input.

> The reason I turn to multiple-precision is that I hope mpir could provide 
> more precision, double does have 53bit precision, but mpf_z should have more.

It does allow more precision, but you cannot start with less
information than you want to end up with. mpf is not able to add
precision that wasn't there to start with. The information was already
lost in the conversion of 0.1 decimal to a double (binary). This
happened before mpf even got the value.

>
> if so, mpir is not more accurate than double, because it adds some random 
> numbers at the end, which will affect the computation result.

No it does not "add random numbers". This is what 0.1 looks like to 53
bits of precision, which is precisely what you passed into the mpf
function. It stored exactly what you gave it.

>
> any idea to solve this issue？

I already told you exactly how to solve the issue in my previous post.
Did you try it?

Decimal fractions aren't always exactly representable in (limited
precision) binary. One way to solve it would be to put in an integer,
then divide by a power of 10. Integers and powers of 10 are exactly
representable in binary.

Bill.

>
>
> thanks.
>
>
>
> 在 2020年8月10日星期一 UTC+8下午2:45:56，Bill Hart写道：
>>
>> You are setting it to the double 0.1, which only has 53 bits
>> precision. You can't get more precision than you put in.
>>
>> Try setting it to 0.5 first (which can be represented exactly in
>> binary), and then divide by the integer 5, which is also able to be
>> represented exactly in binary. Then you will get the 128 bits you are
>> after.
>>
>> By the way, the mpf module isn't used much any more. You should look
>> into mpfr (mpfr.org) instead, which is quite often much faster, and
>> has more functionality and development effort.
>>
>> Bill.
>>
>> On Mon, 10 Aug 2020 at 08:32, wei zhao  wrote:
>> >
>> > hi all,
>> >
>> > I wrote a simple code to test mpir and found a strange thing.
>> >
>> > the code is
>> >
>> > mpf_t a;
>> > mpf_init2(a, 128);
>> > mpf_set_d(a, 0.1);
>> >
>> > mp_exp_t exp;
>> > char str[256];
>> > mpf_get_str(str, , 10, 128, a);
>> > I checked str, and it was "155511151231257827021182" 
>> > instead of "1000".
>> >
>> > anybody knows why? Does not it affect the computation precision?  how can 
>> > I make the variable more accurate?
>> >
>> > thansk a lot
>> >
>> > wei
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "mpir-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to mpir-...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/mpir-devel/4dca16b4-7b7d-4a16-91c6-834def1f8f97o%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/22b82e2c-cc4d-4557-9f8d-ce7c434aa5ado%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnvNS%2B6Okk%3DiZ-DGCqQ0N4xf6LD-jvkLuSHGew9VvyznjA%40mail.gmail.com.

Re: [mpir-devel] strange behavior about mpf_t

['Bill Hart' via mpir-devel]

You are setting it to the double 0.1, which only has 53 bits
precision. You can't get more precision than you put in.

Try setting it to 0.5 first (which can be represented exactly in
binary), and then divide by the integer 5, which is also able to be
represented exactly in binary. Then you will get the 128 bits you are
after.

By the way, the mpf module isn't used much any more. You should look
into mpfr (mpfr.org) instead, which is quite often much faster, and
has more functionality and development effort.

Bill.

On Mon, 10 Aug 2020 at 08:32, wei zhao  wrote:
>
> hi all,
>
> I wrote a simple code to test mpir and found a strange thing.
>
> the code is
>
> mpf_t a;
> mpf_init2(a, 128);
> mpf_set_d(a, 0.1);
>
> mp_exp_t exp;
> char str[256];
> mpf_get_str(str, , 10, 128, a);
> I checked str, and it was "155511151231257827021182" instead 
> of "1000".
>
> anybody knows why? Does not it affect the computation precision?  how can I 
> make the variable more accurate?
>
> thansk a lot
>
> wei
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/4dca16b4-7b7d-4a16-91c6-834def1f8f97o%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnusL_Hw%3D6%2BizH8t9U4GjHjNDXJ9h5kmK_oQhq%3DX2uqP_w%40mail.gmail.com.

[mpir-devel] [ANN] Flint 2.6.2 released

['Bill Hart' via mpir-devel]

Hello all,

We have just released Flint-2.6.2. This combines numerous fixes for
various platforms (included in version 2.6.1, which we didn't announce
due to more bugs surfacing) along with all remaining critical issues
that we are aware of.

The release can be downloaded from our website [1] or is tagged on our
github repository [2].

The next major release of Flint will be Flint-2.7, hopefully out later
this year.

Many thanks to Julien Puydt for reporting and assisting with numerous
issues detected by the Debian build infrastructure.

Best Wishes,

The Flint Development Team.

[1] http://flintlib.org/downloads.html
[2] https://github.com/wbhart/flint2

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsGEYav-4kce%2BwkLsnJ1qnTdsA-su%2B%2B%3DokcS0%3DrpcZ%2BtA%40mail.gmail.com.

[mpir-devel] Flint 2.6.0 Released!

['Bill Hart' via mpir-devel]

Hi all,

It is with pleasure that we announce the release of Flint-2.6.0. This
is the first update of Flint in five years and probably the largest
release ever!

Flint is now almost 500,000 lines of code.

It is available for download from our website in the download section
[1]. Flint documentation is now available online in our new Sphinx
documentation [2].

Flint now supports (native) Windows, Linux, OSX, FreeBSD and OpenBSD.

For MSVC solution files please access Brian Gladman's port [3].

Please note the following deprecations for this release. The functions
have been renamed and the original symbols will be removed in a later
release.

n_gcd_full -> n_gcd
fmpz_poly_is_x -> fmpz_poly_is_gen
fmpz_mod_poly_is_x -> fmpz_mod_poly_is_gen
fmpq_poly_is_x -> fmpq_poly_is_gen

New Features
===

Here are the main new features:

  * multivariate polynomials over most standard rings (sparse distributed)
  * APR-CL primality proving
  * elliptic curve integer factoring
  * minpoly and charpoly
  * improved quadratic sieve for integer factoring
  * embeddings of finite fields
  * pollard rho integer factoring
  * p+1 integer factoring
  * best of breed smooth integer factoring routine
  * best of breed general integer factoring routine
  * howell and strong echelon form
  * large speedups for solve and hence inverse over Z and Q
  * randprime and nextprime functions
  * pernet-stein HNF improvements
  * moller-granlund precomputed inverses
  * resultant_modular_div
  * fibonacci polynomials
  * exception mechanism/flint_abort
  * sqrt of series and polynomials
  * division of series over Z
  * power sums
  * improved base cases of various power series functions
  * ability to switch memory allocators
  * fast recurrence for Hermite polys
  * shifted Legendre polynomials
  * Laguerre polynomials
  * Gegenbauer polys
  * sphinx documentation
  * van hoeij with gradual feeding implementation of polynomial factoring over Z
  * perfect power detection
  * divisibility testing for polynomials
  * fast block based memory manager for bundling fmpz allocations
  * uniform random generation
  * CMake build system
  * linear algebra speedups when everything can be kept in longs
  * nmod module for integers mod (small) n
  * fmpz_mod_mat module for matrices over integers mod multiprecision n
  * kronecker product (tensor product)
  * random primitive polys (for finite fields)
  * thread pool implementation
  * threading of FFT for integer and polynomial multiplication over Z
  * threading of quadratic sieve for integer factoring
  * improved threading of factoring of polynomials mod p
  * threading for multivariate polynomial multiplication, division and GCD
  * threaded multiplication of matrices mod p
  * Berlekamp-Massey (nmod)
  * fmpz_mod module for integers mod multiprecision n
  * Pohlig-Hellman (discrete log)
  * farey_neighbours
  * remove openMP option
  * additional integer division variants
  * speed up mpn_mulmod_preinv
  * fft precaching
  * cyclotomic polynomial detection
  * polynomial root finding over finite fields
  * GMP 6.2 support
  * MPIR 3.0.0 support
  * many small speedups and additional convenience functions added

Contributors
==

This release would not have been possible without an extraordinary
number of contributions. Here are the main contributors to this
release:

* Daniel Schultz - multivariate polynomials, root finding, thread
pool, many speedups and bug fixes
* Fredrik Johansson - Speedup of inverse and solve, speedup of
basecases with small entries, Sphinx documentation, many other
improvements, maintenance and patch review
* William Hart - Maintainer, qsieve, ecm, threading, polynomial
factoring, minpoly, charpoly, fft precaching, speedup of inverse and
solve, many other improvements
* Vladimir Glazachev - APRCL
* Kushagra Singh - qsieve improvements, pollard rho
* Nitin Kumar - qsieve improvements
* Tommy Hofmann - matrix normal forms, bug fixes
* Dan Roche - randprime, nextprime, some work on minpoly
* Claus Fieker - flint_abort, qadics without Conway polynomials, bug fixes
* Alex Best - integer factor improvements, bug fixes
* Shrivin Srivastava - Fibonacci polynomials, speed up linear
composition, bug fixes
* Ralf Stephan - Hermite, Laguerre, Shifted Legendre, Gegenbauer polynomials
* Isuru Fernando - testing, build issues, bug fixes
* Vincent Delecroix - power sums, polynomial speedups, root counting
* Luca De Feo - Embeddings of finite fields
* Martin Raum - Kronecker product
* xoviat - CMake support
* Edouard Rousseau - Embeddings of finite fields
* David Einstein - documentation proofreading, CMake fixes
* Jerry James - memory leak fixes, array overrun fixes
* Brian Gladman - Windows MSVC support

We wish to give special thanks to two contributors, namely Daniel
Schultz and Isuru Fernando. Daniel because of the extraordinary amount
of outstanding new code contributed (well over 100,000 lines of code)
and Fernando for going above and beyond in helping track down 

[mpir-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via mpir-devel]

Dear all,

I've tagged Flint 2.6.0-rc4 [2]. The new changes are:

* fixes for C++ wrapper
* fix verbose mode for build/tests
* fix quiet mode CXX printing

Assuming there are no additional serious bugs found, the release will
become final this Friday 5th June.

Issue to be reported on our GitHub issue tracker [2].

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc4
[2] https://github.com/wbhart/flint2/issues


On Fri, 29 May 2020 at 20:30, Bill Hart  wrote:
>
> Dear all,
>
> I've tagged Flint 2.6.0-rc3 [2]. The new changes are:
>
> * better support for old version of MSVC (fix some prototypes)
> * support for building Flint without pthreads (only useful for old platforms)
> * add const to some mpoly functions
>
> As these are not considered serious problems, the release is still
> scheduled for Monday.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc3
> [2] https://github.com/wbhart/flint2/issues
>
> On Thu, 28 May 2020 at 17:41, Bill Hart  wrote:
> >
> > Dear all,
> >
> > I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
> > found the release will become final on Monday June 1st.
> >
> > Issues should be reported on our issue tracker[2]. Successful builds
> > can be reported here.
> >
> > Bill.
> >
> > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
> > [2] https://github.com/wbhart/flint2/issues
> >
> > On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
> > >
> > > Dear all,
> > >
> > > I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> > > now available to download and try out.
> > >
> > > If there are no further bug reports by this Friday 29 May 2020 the
> > > final release of flint-2.6.0 will be made.
> > >
> > > Please report bugs on our GitHub issues and successful builds here.
> > >
> > > This is now a final opportunity for everyone, including end users, to
> > > report any issues before the final release (hopefully) on Friday.
> > >
> > > Note that Flint now has new online sphinx documentation [3].
> > >
> > > Contributors have been updated on our website [4], however we will
> > > acknowledge contributors to this release when the final release
> > > announcement is made on Friday and final release tarballs are put on
> > > the website.
> > >
> > > Please note that the soname will not be incremented for the final
> > > release. It has already been incremented for 2.6.0 in anticipation of
> > > the release.
> > >
> > > The only tasks that remain for the release are:
> > >
> > > * further updating of our website
> > > * Windows MSVC solution file documentation
> > > * release announcement
> > >
> > > Please note that the flint-2.5 branch in our repository is now
> > > defunct. All backporting from trunk will now occur on flint-2.6.
> > >
> > > Bill.
> > >
> > > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> > > [2] https://github.com/wbhart/flint2/issues
> > > [3] http://flintlib.org/doc/
> > > [4] http://flintlib.org/authors.html

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnuRCpX9LN%2B38r7bUkiP%2BVmLZ%2B8cdyKJmL%3D5-MAD3hqY%3DQ%40mail.gmail.com.

[mpir-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via mpir-devel]

Dear all,

I've tagged Flint 2.6.0-rc3 [2]. The new changes are:

* better support for old version of MSVC (fix some prototypes)
* support for building Flint without pthreads (only useful for old platforms)
* add const to some mpoly functions

As these are not considered serious problems, the release is still
scheduled for Monday.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc3
[2] https://github.com/wbhart/flint2/issues

On Thu, 28 May 2020 at 17:41, Bill Hart  wrote:
>
> Dear all,
>
> I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
> found the release will become final on Monday June 1st.
>
> Issues should be reported on our issue tracker[2]. Successful builds
> can be reported here.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
> [2] https://github.com/wbhart/flint2/issues
>
> On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
> >
> > Dear all,
> >
> > I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> > now available to download and try out.
> >
> > If there are no further bug reports by this Friday 29 May 2020 the
> > final release of flint-2.6.0 will be made.
> >
> > Please report bugs on our GitHub issues and successful builds here.
> >
> > This is now a final opportunity for everyone, including end users, to
> > report any issues before the final release (hopefully) on Friday.
> >
> > Note that Flint now has new online sphinx documentation [3].
> >
> > Contributors have been updated on our website [4], however we will
> > acknowledge contributors to this release when the final release
> > announcement is made on Friday and final release tarballs are put on
> > the website.
> >
> > Please note that the soname will not be incremented for the final
> > release. It has already been incremented for 2.6.0 in anticipation of
> > the release.
> >
> > The only tasks that remain for the release are:
> >
> > * further updating of our website
> > * Windows MSVC solution file documentation
> > * release announcement
> >
> > Please note that the flint-2.5 branch in our repository is now
> > defunct. All backporting from trunk will now occur on flint-2.6.
> >
> > Bill.
> >
> > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> > [2] https://github.com/wbhart/flint2/issues
> > [3] http://flintlib.org/doc/
> > [4] http://flintlib.org/authors.html

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnvs%3Dz392FNwJkfV_e0Pg75bMZFwy%3DOvjFu3VpKDC58DVg%40mail.gmail.com.

[mpir-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via mpir-devel]

Dear all,

I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
found the release will become final on Monday June 1st.

Issues should be reported on our issue tracker[2]. Successful builds
can be reported here.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
[2] https://github.com/wbhart/flint2/issues

On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
>
> Dear all,
>
> I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> now available to download and try out.
>
> If there are no further bug reports by this Friday 29 May 2020 the
> final release of flint-2.6.0 will be made.
>
> Please report bugs on our GitHub issues and successful builds here.
>
> This is now a final opportunity for everyone, including end users, to
> report any issues before the final release (hopefully) on Friday.
>
> Note that Flint now has new online sphinx documentation [3].
>
> Contributors have been updated on our website [4], however we will
> acknowledge contributors to this release when the final release
> announcement is made on Friday and final release tarballs are put on
> the website.
>
> Please note that the soname will not be incremented for the final
> release. It has already been incremented for 2.6.0 in anticipation of
> the release.
>
> The only tasks that remain for the release are:
>
> * further updating of our website
> * Windows MSVC solution file documentation
> * release announcement
>
> Please note that the flint-2.5 branch in our repository is now
> defunct. All backporting from trunk will now occur on flint-2.6.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> [2] https://github.com/wbhart/flint2/issues
> [3] http://flintlib.org/doc/
> [4] http://flintlib.org/authors.html

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsG%3D0D4MmAgkHkpsthkFFe%3DTVzyuEKh00xonq-M3Gge7g%40mail.gmail.com.

[mpir-devel] Flint 2.6.0-rc1

['Bill Hart' via mpir-devel]

Dear all,

I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
now available to download and try out.

If there are no further bug reports by this Friday 29 May 2020 the
final release of flint-2.6.0 will be made.

Please report bugs on our GitHub issues and successful builds here.

This is now a final opportunity for everyone, including end users, to
report any issues before the final release (hopefully) on Friday.

Note that Flint now has new online sphinx documentation [3].

Contributors have been updated on our website [4], however we will
acknowledge contributors to this release when the final release
announcement is made on Friday and final release tarballs are put on
the website.

Please note that the soname will not be incremented for the final
release. It has already been incremented for 2.6.0 in anticipation of
the release.

The only tasks that remain for the release are:

* further updating of our website
* Windows MSVC solution file documentation
* release announcement

Please note that the flint-2.5 branch in our repository is now
defunct. All backporting from trunk will now occur on flint-2.6.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
[2] https://github.com/wbhart/flint2/issues
[3] http://flintlib.org/doc/
[4] http://flintlib.org/authors.html

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFns5AumRwRV0eUtv_iLZDPwiNO_zCP9O%3D8ZJ6u5ZJ4Px1Q%40mail.gmail.com.

Re: [mpir-devel] Automatic disk Read/Write when numbers exceed available RAM

['Bill Hart' via mpir-devel]

No, unfortunately there is no automatic facility to do this other than
the swapping mechanism of your OS.

On Tue, 26 May 2020 at 06:37, Gaj Satha  wrote:
>
> The problem I have is that numbers have become so big that I can’t store them 
> in my RAM. Is there a way I can smartly write portions of my number to the 
> hard disk and load them when needed?
>
> Essentially what I want is that when the RAM is full, just write to the disk 
> and load is automatically without me writing the logic of disk read/write.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/1e4ba4af-3dc8-46f7-ac60-3bd9410bc89b%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsPTBXyJ7TNa9dm_-MNFCO2FLsEzo2ygVpR2MKAsz%3DUmg%40mail.gmail.com.

Re: [mpir-devel] Re: Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via mpir-devel]

I will leave it to the CMake people to document it if they want to.
I've made it clear I'm not the maintainer of the CMake build.

Documentation still remains to be done, so an update on the Visual
Studio build would be most appreciated. All that documentation will go
into .rst files, but if you send it to me in text format I can do the
conversion to .rst.

Bill.

On Wed, 20 May 2020 at 20:27, Brian Gladman  wrote:
>
> On 20/05/2020 17:40, 'Bill Hart' via mpir-devel wrote:
> > Hi again,
> >
> > Commit a960857c7d8e5ea7c4d4c2958e38ec52778d85d9  of the Flint
> > repository [1] is now flint-2.6.0-alpha2
> >
> > This is the last chance for developers working on related projects to
> > see if Flint works as expected for them, before we start asking end
> > users/distributions to start testing.
>
> I tested the release (that you announced recently) on Windows (with my
> Visual Studio build) and all tests passed.
>
> I can't test the new release immediately but I will hopefully be able to
> check it within the next few days.
>
> > We have made many modifications since alpha1, including:
> >
> > * removing all known memory leaks
> > * fixing a bug in the integer gcd (leak, inefficiency, very slim
> > chance of wrong answer)
> > * properly supporting GMP-6.2
> > * making matrices with zero rows/columns more robust
> > * many other less important fixes (35 commits total)
> > * fixing a bug/crash in the _f functions in the fmpz_mod_poly module
> >
> > We don't foresee the need for any further alpha releases, (assuming no
> > major issues are found). The next release will likely either be a beta
> > or release candidate. Please note the only important things that
> > remain to be done as far as we know are documentation/paperwork
> > related [2].
>
> The Visual Studio build documentation is out of date and we now have the
> CMake build on Windows that needs documentation.
>
> I am happy to provide an update of the Visual Studio build documentation
> but I can't help with CMake.
>
>Brian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/7d35b4ed-2382-54c6-f92f-f5e97af1e5c0%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsFeKVG3p3g0KMXnLU5oHF73c9%2B%2Bv_FCwHMY9SJ-f%2B8Ag%40mail.gmail.com.

[mpir-devel] Re: Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via mpir-devel]

Hi again,

Commit a960857c7d8e5ea7c4d4c2958e38ec52778d85d9  of the Flint
repository [1] is now flint-2.6.0-alpha2

This is the last chance for developers working on related projects to
see if Flint works as expected for them, before we start asking end
users/distributions to start testing.

We have made many modifications since alpha1, including:

* removing all known memory leaks
* fixing a bug in the integer gcd (leak, inefficiency, very slim
chance of wrong answer)
* properly supporting GMP-6.2
* making matrices with zero rows/columns more robust
* many other less important fixes (35 commits total)
* fixing a bug/crash in the _f functions in the fmpz_mod_poly module

We don't foresee the need for any further alpha releases, (assuming no
major issues are found). The next release will likely either be a beta
or release candidate. Please note the only important things that
remain to be done as far as we know are documentation/paperwork
related [2].

Please report bugs on our GitHub issue tracker. Successful builds can
be reported here.

Best Wishes,

The Flint Development Team

P.S. thanks to the Flint package maintainer in the Fedora project who
did early reporting/patching of many issues and to the numerous people
who gave feedback on the first alpha! Many more acknowledgements to
come in the release announcement!

[1] https://github.com/wbhart/flint2
[2] https://github.com/wbhart/flint2/milestone/2

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsg%3DQM%2BMuPG6AppwMepQXOsF9qhzXNy-4cKu%3D%2BJZ75row%40mail.gmail.com.

[mpir-devel] Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via mpir-devel]

Hi all,

The (latest) commit c6319d1d36248f2fc699e833ab2f6fa70d21e906 in the
official Flint repository [1] is flint-2.6.0-alpha1.

This is an opportunity for early testing and feedback before our first
official beta which will be released about Wednesday next week.

Some release tasks have not yet been done [2] and will follow in the
next few days, but shouldn't affect very much.

However, we might slip in some more deprecations before the beta
cycle, though the old function names will continue to be available
until the next release. Please report if you find this is not the
case.

Please place bug reports in GitHub issues. Successful builds can be
reported here.

A full release announcement of all new contributors and features will
be made when the new release is finally issued.

Best Wishes,

The Flint Development Team.

[1] https://github.com/wbhart/flint2
[2] https://github.com/wbhart/flint2/milestone/2

P.S Here is how I configure and build Flint for my system:

./configure --prefix=/home/wbhart/usr/ --with-gmp=/home/wbhart/usr
--with-mpfr=/home/wbhart/usr/
make -j install
make -j check

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntZOWPOu8hUdsMr4_p9wGc%2BoZmOZ_6ufR8QuOyy_%2BDFbw%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

You may be right, but I don't see where your files are in our repo:

https://github.com/wbhart/flint2

This would be better discussed on the flint list as Isuru Fernando could
chime in. He understands CMake much better than I do. I don't want to make
assertions about it, as they often prove to be wrong.

Perhaps you could open a ticket with your observations on my Flint repo?

Bill.

On Wed, 29 Apr 2020 at 00:23, Cactus  wrote:

>
>
> On Tuesday, 28 April 2020 23:09:02 UTC+1, Cactus wrote:
>>
>> On 28/04/2020 22:48, 'Bill Hart' via mpir-devel wrote:
>> > They both take about 0.6s with our continuous integration. I don't know
>> > if @tthsqe12 would expect them to randomly hit a really hard case?
>> >
>> >
>> https://ci.appveyor.com/project/wbhart/flint2/builds/32491737/job/1os2ex9o3pe53bhe
>>
>> I was under the impression that the Flint MSVC Windows build was no
>> longer dependent on my build system.  But I am now suspicious that you
>> might still be relying on my build as a basis for the CMake build.
>>
>> If I am right, I am afraid that the build will be out of date and will
>> not be correct unless the test build generator has been run to keep it
>> aligned with the Flint source code.
>>
>> Otherwise its hard to explain why my results are different.
>>
>>Brian
>>
>
> Here are my results using a 5 minute timeout for each test:
>
> Failed:
>
> fmpz_mat: t-scalar_smod ... ERROR 3221225477
> nmod_poly_mat: t-concat_vertical ... ERROR 3221225477
>
> Timed out:
>
> fmpq_mpoly: t-gcd
> fmpq_mpoly: t-gcd_cofactors
> fmpz_mod_poly: t-compose_mod_brent_kung_vec_preinv_threaded
> fmpz_mpoly: t-divides
> fmpz_mpoly: t-divides_heap_threaded
> fmpz_mpoly: t-gcd
> fmpz_mpoly: t-gcd_berlekamp_massey
> fmpz_mpoly: t-gcd_berlekamp_massey_threaded
> fmpz_mpoly: t-gcd_brown_threaded
> fmpz_mpoly: t-gcd_cofactors
> fmpz_mpoly: t-gcd_zippel
> fmpz_mpoly: t-mpolyuu_divides_threaded
> fmpz_mpoly: t-mul
> fmpz_mpoly: t-mul_array_threaded
> fmpz_mpoly: t-mul_heap_threaded
> fmpz_poly: t-taylor_shift_divconquer
> nmod_mpoly: t-divides
> nmod_mpoly: t-divides_heap_threaded
> nmod_mpoly: t-gcd
> nmod_mpoly: t-gcd_brown_threaded
> nmod_mpoly: t-gcd_cofactors
> nmod_mpoly: t-gcd_zippel
> nmod_mpoly: t-mpolyn_divides_threaded
> nmod_mpoly: t-mul
> nmod_mpoly: t-mul_array_threaded
> nmod_mpoly: t-mul_heap_threaded
> nmod_vec: t-discrete_log_pohlig_hellman
> qsieve: t-factor
> thread_pool: t-thread_pool
> ulong_extras: t-n_urandintulong_extras: t-n_urandint
>
> The two failures are both access violations.
>
>  Brian
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/8ae7122f-049d-4099-8e4f-239693bf6fe6%40googlegroups.com
> <https://groups.google.com/d/msgid/mpir-devel/8ae7122f-049d-4099-8e4f-239693bf6fe6%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnu2nTkR_yozG7235EW%3DV8JLV%3DSDYg6VTyB6_tu5bnv-rg%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

They both take about 0.6s with our continuous integration. I don't know
if @tthsqe12 would expect them to randomly hit a really hard case?

https://ci.appveyor.com/project/wbhart/flint2/builds/32491737/job/1os2ex9o3pe53bhe


Bill.

On Tue, 28 Apr 2020 at 16:51, Brian Gladman  wrote:

> On 28/04/2020 15:44, 'Bill Hart' via mpir-devel wrote:
>
> > That's great news, thanks Brian.
>
> I fear that I have reported a complete pass too early as I missed the
> fact that my test code had to abort two tests after running for too long
> (over 120 seconds).  These are:
>
>   fmpq_mpoly/t-gcd.exe
>   fmpq_mpoly/t-gcd_cofactors.exe
>
> I have just run them both manually and neither finsihed within the five
> minutes I gave them.  Should I expect to take longer then this?
>
>Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/4c21c68f-510f-dc35-5723-e0480c10f038%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnuG1ozDyU15T9ZtenY1zi-7%2Bhd1wbPS%3DJM8ejxDKYiw8w%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

That's great news, thanks Brian.

Bill.

On Tue, 28 Apr 2020 at 15:58, Brian Gladman  wrote:

> On 28/04/2020 00:06, Bill Hart wrote:
> > Dear Brian,
> >
> > MSVC 32 and 64 bit are now completely passing in out continuous
> > integration with our trunk branch.
> >
> > Could you possibly test this and see if it works for you. We are of
> > course using CMake to generate the build files and I know you have your
> > own solution files.
> >
> > I'd be interesting to hear whether you still have the t-minpoly failure.
> > Can you tell me what ERROR 3 is? That is not printed by our test code
> > and it should in fact print a failure message with some diagnostic
> > information if the test fails.
> >
> > I've opened a ticket for this issue until it is resolved, but there's
> > nothing more I can do for now without further information as we are
> > unable to reproduce it.
>
> THe name change of  config.h to flint-config.h was an initial issue for
> me but this is fortunately easy to fix.  I have built and tested the
> trunk branch of FLINT on Windows x64 and all tests pass.
>
> I am not running win32 builds these days as I consider them obsolescent
> but there is no reason to believe that they wont build if anyone wants
> to run them.
>
> The fmpq_mat/t-minpoly test passes and is not a FLINT code issue. I have
> tracked this down to a failure somewhere in my automted code to build
> and run the tests (why it fails one just one of well over 1000 tests is
> a puzzle but I suspect a naming anomaly of some kind).  Anyway, I have
> double checked by running this this test manually and it passes so the
> ticcket can be closed.
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/cc2bae2e-fa20-e5a0-c500-fe17fa2b09ed%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnuiEk4JoxFfzECiSjQUQy60KRQgssdW-j2taLCPjDK25Q%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

That's interesting. You have different errors with MSVC than we do.

We don't see this but we do see a different error.

On Tue, 21 Apr 2020 at 20:14, Brian Gladman  wrote:

> On 21/04/2020 16:50, 'Bill Hart' via mpir-devel wrote:
> > Isuru reinserted the necessary line FLINT_DLL const unsigned int
> > partitions_lookup[128];
> >
> > Perhaps you could check if this works for you now.
>
> It builds fine. The tests give one error:
>
> 
> 1523 tests:
> 1522 ran correctly
> 1 failed
> fmpq_mat: t-minpoly ERROR 3 minpoly
> 
>
> I have not yet retested Arb integration though.  But it should be OK
>
>Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/aecec632-87af-95b8-efc4-231d6c669387%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntg3OvhtLAV8BzZ1d5oc1tp%2BYoEkO4KfKhEmx%2B23cVY4w%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

Isuru reinserted the necessary line FLINT_DLL const unsigned int
partitions_lookup[128];

Perhaps you could check if this works for you now.

Bill.

On Tue, 21 Apr 2020 at 17:26, Bill Hart  wrote:

> Hi Brian,
>
> Isuru Fernando believes he may have found the issue. I'll try reinserting
> the export as soon as we fix some other issues and see if it passes again.
>
> For example, the fmpz_poly_factor test hangs at present. We haven't been
> able to figure out why.
>
> We are using MSVC files built by CMake I think. So we don't need the ones
> from your repository for our CI (I think). (To be honest I am a bit lost
> with the current Windows maintenance, as others have largely been doing it
> for me. For example I just learned that they had disabled some of the tests
> in the CI because they were hanging or crashing. We are now down to one of
> each.)
>
> Best Wishes,
>
> Bill.
>
> On Tue, 21 Apr 2020 at 09:56, Cactus  wrote:
>
>>
>>
>> On Tuesday, 21 April 2020 00:28:28 UTC+1, Bill Hart wrote:
>>>
>>> Hi Brian,
>>>
>>> After making these changes, our cmake continuous integration fails. I
>>> think the problem is with this line:
>>>
>>> FLINT_DLL const unsigned int partitions_lookup[128];
>>>
>>> Is this only relevant for MSVC?
>>>
>>> Bill.
>>>
>>
>> Good morning Bill,
>>
>> Unless something strange is going on, an Arb DLL, when built to import
>> from a FLINT DLL, will require that this symbol is exported when the flint
>> DLL is built.
>>
>> So the need for this symbol is not unique to MSVC but the mechanism for
>> exporting it using the FLINT_DLL defines in source code is MSVC specific.
>>
>> I believe that CMake builds flint on Windows using my flint MSVC build
>> files.  But my guess is that it doesn't use my build system to regenerate
>> these files when the build is updated (as in this case).
>>
>> If I am right about this, CMake may simply be failing because it is now
>> using the old MSVC build files.
>>
>> Regenerating these build files or importing them from my flint repository
>> may hence fix this issue (assuming that my repository is still in sync with
>> the master repository).
>>
>> Brian
>>
>>
>>> On Tue, 21 Apr 2020 at 00:37, Bill Hart 
>>> wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> I have fixed the three issues you pointed out to do with building an
>>>> Arb dll. Thanks very much for pointing these out.
>>>>
>>>> As for the flint dll, I don't mind what name is used. It's not a
>>>> problem for me. This is technically flint2, not flint. But it is very many
>>>> years since anyone has used the latter. I think it is fine to simply call
>>>> it flint now.
>>>>
>>>> Bill.
>>>>
>>>>
>>>> On Tue, 14 Apr 2020 at 19:55, Brian Gladman  wrote:
>>>>
>>>>> Hi Bill and Fredrik,
>>>>>
>>>>> Being in CORVID lockdown, I decided to have a look at building Arb with
>>>>> Visual Studio. This has gone pretty well but I have a few issues on
>>>>> which I would appreciate your advice.
>>>>>
>>>>> I can compile and build Arb as a static library without any issues but
>>>>> building Arb as a DLL fails because it needs two flint export ssymbols
>>>>> that are not present in the FLINT DLL.
>>>>>
>>>>> The first of these is '__flint_clz_tab' which I find can be switched on
>>>>> in FLINT by defining NEED_CLZ_TAB when building FLINT. This should not
>>>>> be a problem since I can modify my FLINT build to do this.
>>>>>
>>>>> The second missing symbol is 'partitions_lookup', which is defined in
>>>>> the FLINT file 'number_of_partitions.c' where it does have an export
>>>>> definition. But this is not visible to Arb because it this symbol is
>>>>> not
>>>>> declared in flint.h or, as far as I can tell, in any other exported
>>>>> FLINT header.
>>>>>
>>>>> So is this a symbol that FLINT should export and, if so, where should
>>>>> the export declaration be placed?
>>>>>
>>>>> Another issue I am keen to tidy up is library location and naming.  I
>>>>> am
>>>>> using simple names for the mpir dependent Windows builds: mpir, mpfr,
>>>>> pthreads, ... and adding exte

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

Hi Brian,

Isuru Fernando believes he may have found the issue. I'll try reinserting
the export as soon as we fix some other issues and see if it passes again.

For example, the fmpz_poly_factor test hangs at present. We haven't been
able to figure out why.

We are using MSVC files built by CMake I think. So we don't need the ones
from your repository for our CI (I think). (To be honest I am a bit lost
with the current Windows maintenance, as others have largely been doing it
for me. For example I just learned that they had disabled some of the tests
in the CI because they were hanging or crashing. We are now down to one of
each.)

Best Wishes,

Bill.

On Tue, 21 Apr 2020 at 09:56, Cactus  wrote:

>
>
> On Tuesday, 21 April 2020 00:28:28 UTC+1, Bill Hart wrote:
>>
>> Hi Brian,
>>
>> After making these changes, our cmake continuous integration fails. I
>> think the problem is with this line:
>>
>> FLINT_DLL const unsigned int partitions_lookup[128];
>>
>> Is this only relevant for MSVC?
>>
>> Bill.
>>
>
> Good morning Bill,
>
> Unless something strange is going on, an Arb DLL, when built to import
> from a FLINT DLL, will require that this symbol is exported when the flint
> DLL is built.
>
> So the need for this symbol is not unique to MSVC but the mechanism for
> exporting it using the FLINT_DLL defines in source code is MSVC specific.
>
> I believe that CMake builds flint on Windows using my flint MSVC build
> files.  But my guess is that it doesn't use my build system to regenerate
> these files when the build is updated (as in this case).
>
> If I am right about this, CMake may simply be failing because it is now
> using the old MSVC build files.
>
> Regenerating these build files or importing them from my flint repository
> may hence fix this issue (assuming that my repository is still in sync with
> the master repository).
>
> Brian
>
>
>> On Tue, 21 Apr 2020 at 00:37, Bill Hart  wrote:
>>
>>> Hi Brian,
>>>
>>> I have fixed the three issues you pointed out to do with building an Arb
>>> dll. Thanks very much for pointing these out.
>>>
>>> As for the flint dll, I don't mind what name is used. It's not a problem
>>> for me. This is technically flint2, not flint. But it is very many years
>>> since anyone has used the latter. I think it is fine to simply call it
>>> flint now.
>>>
>>> Bill.
>>>
>>>
>>> On Tue, 14 Apr 2020 at 19:55, Brian Gladman  wrote:
>>>
>>>> Hi Bill and Fredrik,
>>>>
>>>> Being in CORVID lockdown, I decided to have a look at building Arb with
>>>> Visual Studio. This has gone pretty well but I have a few issues on
>>>> which I would appreciate your advice.
>>>>
>>>> I can compile and build Arb as a static library without any issues but
>>>> building Arb as a DLL fails because it needs two flint export ssymbols
>>>> that are not present in the FLINT DLL.
>>>>
>>>> The first of these is '__flint_clz_tab' which I find can be switched on
>>>> in FLINT by defining NEED_CLZ_TAB when building FLINT. This should not
>>>> be a problem since I can modify my FLINT build to do this.
>>>>
>>>> The second missing symbol is 'partitions_lookup', which is defined in
>>>> the FLINT file 'number_of_partitions.c' where it does have an export
>>>> definition. But this is not visible to Arb because it this symbol is not
>>>> declared in flint.h or, as far as I can tell, in any other exported
>>>> FLINT header.
>>>>
>>>> So is this a symbol that FLINT should export and, if so, where should
>>>> the export declaration be placed?
>>>>
>>>> Another issue I am keen to tidy up is library location and naming.  I am
>>>> using simple names for the mpir dependent Windows builds: mpir, mpfr,
>>>> pthreads, ... and adding extensions 'lib and .dll accordingly.
>>>>
>>>> For example, MPIR is in a root directory callled 'mpir' and within this
>>>> directory I have lib, dll, and exe sub-directories where I place the
>>>> mpir.lb, mpir.dll and mpir.exe build outputs. The same structure
>>>> applies
>>>> to mpfr, pthreads but for FLINT I have been using the directory 'flint2'
>>>> rather than 'flint' and 'lib_flint.lib' and 'dll_flint.dll' for the
>>>> libraries (I am not sure why!)
>>>>
>>>> In order to get a consistent approach now that I am adding Arb, I would
>>>> like to use the 

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

Hi Brian,

After making these changes, our cmake continuous integration fails. I think
the problem is with this line:

FLINT_DLL const unsigned int partitions_lookup[128];

Is this only relevant for MSVC?

Bill.

On Tue, 21 Apr 2020 at 00:37, Bill Hart  wrote:

> Hi Brian,
>
> I have fixed the three issues you pointed out to do with building an Arb
> dll. Thanks very much for pointing these out.
>
> As for the flint dll, I don't mind what name is used. It's not a problem
> for me. This is technically flint2, not flint. But it is very many years
> since anyone has used the latter. I think it is fine to simply call it
> flint now.
>
> Bill.
>
>
> On Tue, 14 Apr 2020 at 19:55, Brian Gladman  wrote:
>
>> Hi Bill and Fredrik,
>>
>> Being in CORVID lockdown, I decided to have a look at building Arb with
>> Visual Studio. This has gone pretty well but I have a few issues on
>> which I would appreciate your advice.
>>
>> I can compile and build Arb as a static library without any issues but
>> building Arb as a DLL fails because it needs two flint export ssymbols
>> that are not present in the FLINT DLL.
>>
>> The first of these is '__flint_clz_tab' which I find can be switched on
>> in FLINT by defining NEED_CLZ_TAB when building FLINT. This should not
>> be a problem since I can modify my FLINT build to do this.
>>
>> The second missing symbol is 'partitions_lookup', which is defined in
>> the FLINT file 'number_of_partitions.c' where it does have an export
>> definition. But this is not visible to Arb because it this symbol is not
>> declared in flint.h or, as far as I can tell, in any other exported
>> FLINT header.
>>
>> So is this a symbol that FLINT should export and, if so, where should
>> the export declaration be placed?
>>
>> Another issue I am keen to tidy up is library location and naming.  I am
>> using simple names for the mpir dependent Windows builds: mpir, mpfr,
>> pthreads, ... and adding extensions 'lib and .dll accordingly.
>>
>> For example, MPIR is in a root directory callled 'mpir' and within this
>> directory I have lib, dll, and exe sub-directories where I place the
>> mpir.lb, mpir.dll and mpir.exe build outputs. The same structure applies
>> to mpfr, pthreads but for FLINT I have been using the directory 'flint2'
>> rather than 'flint' and 'lib_flint.lib' and 'dll_flint.dll' for the
>> libraries (I am not sure why!)
>>
>> In order to get a consistent approach now that I am adding Arb, I would
>> like to use the directory 'flint' rather than 'flint2' as the root
>> directory for FLINT and use the names 'flint.lib' and 'flint.dll' for
>> the libraries. But before I do this I would like to know if this change
>> is going to cause any issues for others (I am aware the the CMake FLINT
>> build depends on my FLINT build, which is why I am asking).
>>
>> with my regards,
>>
>>   Brian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mpir-devel/b0d4c8ab-8f2e-b1a3-0327-72f8d9e0557a%40gmail.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntiMAGBR7rO9cri6a5ZLjOfcswdF-%3DRAWNAMXA%2Bf4wZ0A%40mail.gmail.com.

Re: [mpir-devel] FLINT and ARB using Visual Studio

['Bill Hart' via mpir-devel]

Hi Brian,

I have fixed the three issues you pointed out to do with building an Arb
dll. Thanks very much for pointing these out.

As for the flint dll, I don't mind what name is used. It's not a problem
for me. This is technically flint2, not flint. But it is very many years
since anyone has used the latter. I think it is fine to simply call it
flint now.

Bill.


On Tue, 14 Apr 2020 at 19:55, Brian Gladman  wrote:

> Hi Bill and Fredrik,
>
> Being in CORVID lockdown, I decided to have a look at building Arb with
> Visual Studio. This has gone pretty well but I have a few issues on
> which I would appreciate your advice.
>
> I can compile and build Arb as a static library without any issues but
> building Arb as a DLL fails because it needs two flint export ssymbols
> that are not present in the FLINT DLL.
>
> The first of these is '__flint_clz_tab' which I find can be switched on
> in FLINT by defining NEED_CLZ_TAB when building FLINT. This should not
> be a problem since I can modify my FLINT build to do this.
>
> The second missing symbol is 'partitions_lookup', which is defined in
> the FLINT file 'number_of_partitions.c' where it does have an export
> definition. But this is not visible to Arb because it this symbol is not
> declared in flint.h or, as far as I can tell, in any other exported
> FLINT header.
>
> So is this a symbol that FLINT should export and, if so, where should
> the export declaration be placed?
>
> Another issue I am keen to tidy up is library location and naming.  I am
> using simple names for the mpir dependent Windows builds: mpir, mpfr,
> pthreads, ... and adding extensions 'lib and .dll accordingly.
>
> For example, MPIR is in a root directory callled 'mpir' and within this
> directory I have lib, dll, and exe sub-directories where I place the
> mpir.lb, mpir.dll and mpir.exe build outputs. The same structure applies
> to mpfr, pthreads but for FLINT I have been using the directory 'flint2'
> rather than 'flint' and 'lib_flint.lib' and 'dll_flint.dll' for the
> libraries (I am not sure why!)
>
> In order to get a consistent approach now that I am adding Arb, I would
> like to use the directory 'flint' rather than 'flint2' as the root
> directory for FLINT and use the names 'flint.lib' and 'flint.dll' for
> the libraries. But before I do this I would like to know if this change
> is going to cause any issues for others (I am aware the the CMake FLINT
> build depends on my FLINT build, which is why I am asking).
>
> with my regards,
>
>   Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/b0d4c8ab-8f2e-b1a3-0327-72f8d9e0557a%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntgpVFMsyVgJNUtPS4ZjGE2eT2RuzV%3DXPWRkC0LOmtDnA%40mail.gmail.com.

Re: [mpir-devel] Limits of mpz_t size

['Bill Hart' via mpir-devel]

The limits in MPIR are the same.

In order to get around the limit, you can use the mpn layer of functions.

On Tue, 10 Mar 2020 at 09:56, Gaj Satha  wrote:

> Hi:
>
> Are there any limits on the size of mpz_t in MPIR (Other than availble
> memory)?
>
> I came to know that GNU GMP had limit of 41 billion on mpz_t sometime back
> (as per https://gmplib.org/list-archives/gmp-discuss/2016-July/006013.html),
> which they plan to remove but I don't know if it has been removed.
>
> Please let me know. I need to calculate digits to 50 trillion.
>
> Gaj
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/6a7df5d9-d3cb-451e-a249-d8ec5c309c21%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFntteZYVVGSeK0UKe-hch8p%3DG25Oczp6_B2Jm-_segyQKg%40mail.gmail.com.

Re: [mpir-devel] Can autoconfigure be done without YASM

['Bill Hart' via mpir-devel]

Yasm is actually required. It doesn't use AT syntax like gas, and we
actually use yasm specific features such as its macros.

There have been proposals to rewrite all the assembly for Linux in AT
syntax, but no one has ever found the time to actually do it.

Bill.

On Sat, 5 Oct 2019 at 21:51, David Lindauer  wrote:

> Is it possible to configure the autoconfigure to use an assembler other
> than YASM on windows?   I'm asking because I have an assembler that should
> do gas-like constructs that I'd like to test with MPIR.
>
> Thanks,
>
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/0136ce5f-1ed5-4b50-910b-60ad7129f522%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnv1YhY3rOS_ThAFY-0do9EiwA%2BNnf7pz9%2BC0o0a%3Diucfg%40mail.gmail.com.

Re: [mpir-devel] possible bug in fft/normmod_2expp1.c

['Bill Hart' via mpir-devel]

Are you sure? The double parentheses are usually used to remind oneself
that a single = was intended and not a typo.

Do you have a failing case for the FFT, or some reasoning as to why the
code is incorrect in its current state?

On Sat, 20 Jul 2019 at 20:59, Wolfgang Gahr  wrote:

> This is just a small file.
> I think the line
>
> if ((hi = t[limbs]))
>
> should be written as
>
> if ((hi == t[limbs]))
>
> Hope this helps.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mpir-devel/87a7d50d-499a-4163-9e72-3e9e2e36a97c%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnv0kjMW4CWU3iqV9gz_amDGpUsrJWUTD-%3D4C-OUjXA7ng%40mail.gmail.com.

Re: [mpir-devel] does mpir support multiprecision artihmetic with GPUs

['Bill Hart' via mpir-devel]

Unfortunately, no.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsF76_neKM%2BnsMCU-Jqpv%2BjkThE%2B107BaJR6wy_Po56HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: MPIR slow on macOS?

['Bill Hart' via mpir-devel]

One difference is in how jump tables are implemented. But I really don't
see how that would be related to this issue.

Are you sure you are not just running out of memory under OSX? Or perhaps
OSX is just pushing stuff out to disk earlier than Linux?

Bill.

On Tue, 15 Jan 2019 at 20:07, Ronald Mak/SJSU  wrote:

> Hi, Bill.
>
>
>
> This will take some detective work to see what are the differences, if
> any, between how MPIR is built on macOS and Linux. It could be a
> configuration issue. Maybe I’ll get a student to look into this.
>
>
>
> – Ron
> http://www.cs.sjsu.edu/~mak/
>
>
>
> “On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into
> the machine wrong figures, will the right answers come out?' I am not able
> rightly to apprehend the kind of confusion of ideas that could provoke such
> a question.”
> -- *Charles Babbage, 1791-1871, world’s first computer scientist*
>
>
>
>
>
> *From: *'Bill Hart' via mpir-devel 
> *Reply-To: *
> *Date: *Tuesday, January 15, 2019 at 2:16 AM
> *To: *mpir-devel 
> *Subject: *Re: [mpir-devel] Re: MPIR slow on macOS?
>
>
>
> That looks correct.
>
>
>
> So your idea that it might be swapping sounds pretty likely.
>
>
>
> I did find someone else reporting a slowdown the other day, and it turned
> out their program was linked to a very old GMP instead of the MPIR they
> built.
>
>
>
> I'm not a Mac expert, so I don't know how to check this, but I imagine you
> can find out online somewhere.
>
>
>
> Otherwise, I can't think of anything which would cause this to happen.
>
>
>
> Bill.
>
>
>
>
>
> On Tue, 15 Jan 2019 at 05:19, Ronald Mak/SJSU  wrote:
>
> Hi, Bill.
>
>
>
> On my Mac laptop:
>
>
>
> ~/mpir-3.0.0: ./config.guess
>
> ivybridge-apple-darwin18.2.0
>
> This is accurate, as far as I can tell.
>
> I’ve attached my pi program, which I assign to my C++ classes to give my
> students practice downloading, configuring, building, and deploying a
> software library.
>
>
>
> – Ron
> http://www.cs.sjsu.edu/~mak/
>
>
>
>
>
> *From: *'Bill Hart' via mpir-devel 
> *Reply-To: *
> *Date: *Monday, January 14, 2019 at 8:11 PM
> *To: *mpir-devel 
> *Subject: *[mpir-devel] Re: MPIR slow on macOS?
>
>
>
> What does ./config.guess say your machine is? It's probably just too new
> to be detected correctly.
>
>
>
> Bill.
>
> On Tuesday, 15 January 2019 05:05:06 UTC+1, Ronald Mak wrote:
>
> I wrote a C++ program that uses MPIR 3.0.0 to compute the first million
> digits of pi. On a native Linux laptop with a Core i7 1.8 GHz CPU, my pi
> program executed in under 8 seconds.
>
> I installed MPIR 3.0.0 on my MacBook Pro laptop with a Core i7 2.3 GHz CPU
> and macOS Mojave 10.14.2. The same pi program took over 135 seconds to
> execute.
>
> Then I used VirtualBox to install Ubuntu 18.10 in a virtual machine on my
> MacBook Pro laptop. I installed MPIR 3.0.0 on the Ubuntu VM, and the same
> pi program ran in about 7 seconds.
>
> What is going on with MPIR on macOS to cause my pi program to run so much
> more slowly? It's apparently not a hardware issue, since the latter two
> runs of my pi program were on the same laptop, but on different operating
> systems. Does MPIR cause macOS to generate interrupts? Interpret certain
> instructions? Paging?
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.c

Re: [mpir-devel] Re: MPIR slow on macOS?

['Bill Hart' via mpir-devel]

That looks correct.

So your idea that it might be swapping sounds pretty likely.

I did find someone else reporting a slowdown the other day, and it turned
out their program was linked to a very old GMP instead of the MPIR they
built.

I'm not a Mac expert, so I don't know how to check this, but I imagine you
can find out online somewhere.

Otherwise, I can't think of anything which would cause this to happen.

Bill.


On Tue, 15 Jan 2019 at 05:19, Ronald Mak/SJSU  wrote:

> Hi, Bill.
>
>
>
> On my Mac laptop:
>
>
>
> ~/mpir-3.0.0: ./config.guess
>
> ivybridge-apple-darwin18.2.0
>
> This is accurate, as far as I can tell.
>
> I’ve attached my pi program, which I assign to my C++ classes to give my
> students practice downloading, configuring, building, and deploying a
> software library.
>
>
>
> – Ron
> http://www.cs.sjsu.edu/~mak/
>
>
>
>
>
> *From: *'Bill Hart' via mpir-devel 
> *Reply-To: *
> *Date: *Monday, January 14, 2019 at 8:11 PM
> *To: *mpir-devel 
> *Subject: *[mpir-devel] Re: MPIR slow on macOS?
>
>
>
> What does ./config.guess say your machine is? It's probably just too new
> to be detected correctly.
>
>
>
> Bill.
>
> On Tuesday, 15 January 2019 05:05:06 UTC+1, Ronald Mak wrote:
>
> I wrote a C++ program that uses MPIR 3.0.0 to compute the first million
> digits of pi. On a native Linux laptop with a Core i7 1.8 GHz CPU, my pi
> program executed in under 8 seconds.
>
> I installed MPIR 3.0.0 on my MacBook Pro laptop with a Core i7 2.3 GHz CPU
> and macOS Mojave 10.14.2. The same pi program took over 135 seconds to
> execute.
>
> Then I used VirtualBox to install Ubuntu 18.10 in a virtual machine on my
> MacBook Pro laptop. I installed MPIR 3.0.0 on the Ubuntu VM, and the same
> pi program ran in about 7 seconds.
>
> What is going on with MPIR on macOS to cause my pi program to run so much
> more slowly? It's apparently not a hardware issue, since the latter two
> runs of my pi program were on the same laptop, but on different operating
> systems. Does MPIR cause macOS to generate interrupts? Interpret certain
> instructions? Paging?
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: MPIR slow on macOS?

['Bill Hart' via mpir-devel]

What does ./config.guess say your machine is? It's probably just too new to 
be detected correctly.

Bill.

On Tuesday, 15 January 2019 05:05:06 UTC+1, Ronald Mak wrote:
>
> I wrote a C++ program that uses MPIR 3.0.0 to compute the first million 
> digits of pi. On a native Linux laptop with a Core i7 1.8 GHz CPU, my pi 
> program executed in under 8 seconds. 
>
> I installed MPIR 3.0.0 on my MacBook Pro laptop with a Core i7 2.3 GHz CPU 
> and macOS Mojave 10.14.2. The same pi program took over 135 seconds to 
> execute. 
>
> Then I used VirtualBox to install Ubuntu 18.10 in a virtual machine on my 
> MacBook Pro laptop. I installed MPIR 3.0.0 on the Ubuntu VM, and the same 
> pi program ran in about 7 seconds. 
>
> What is going on with MPIR on macOS to cause my pi program to run so much 
> more slowly? It's apparently not a hardware issue, since the latter two 
> runs of my pi program were on the same laptop, but on different operating 
> systems. Does MPIR cause macOS to generate interrupts? Interpret certain 
> instructions? Paging?

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: make errors on Cygwin64 terminal

['Bill Hart' via mpir-devel]

By the way, MPIR does build in the Windows Subsystem for Linux, or with
recent MSVC, if either of those are an option for you.

MPIR should in theory build in Cygwin, since Sage has Cygwin support
(assuming they are not using GMP instead). However, I don't know if that is
32 or 64 bits.

In theory it also builds with msys/mingw-w64, but I have not done this for
ages, and it isn't as easy as it should be. I personally use the WSL and
find this to be very practical, however, you must install all the right
packages.

Bill.

On Thu, 10 Jan 2019 at 20:49, Dima Pasechnik  wrote:

>
>
> On Thu, 10 Jan 2019 18:21 Chintan Joshi 
>> Hi Bill,
>> Thanks for the prompt response. Any recommendations on how do I check
>> where the unsupported characters are coming from?
>>
>
> Where have you installed your Cygwin64 in?
> What is the path? Does it by any chances has non-ascii characters in it,
> or spaces?
> That \377\376 seem to indicate it is unicode, see
> https://en.m.wikipedia.org/wiki/Byte_order_mark#UTF-16
>
>
>
> Apart from this, I can say that symlinks on
> Cygwin were always a bit fragile.
>
> Cheers,
>> Chintan
>>
>> On Wednesday, January 9, 2019 at 10:47:00 PM UTC-8, Chintan Joshi wrote:
>>>
>>> Hi guys,
>>> I need MPIR for a package I am trying to use. I have a Windows 10
>>> machine. I start with:
>>>
>>> $ ./configure --disable-static --enable-shared
>>>
>>> This appears to go without any hiccups. However, when I run "make ". I
>>> even tried make install; no luck yet. Any help would be highly appreciated.
>>> Please do let me know if I can provide with any information from my end to
>>> help troubleshoot this issue. Below is the what I see:
>>>
>>> $ make
>>> E:/programs/GnuWin32/bin/make  all-recursive
>>> make[1]: Entering directory `E:/mpir-3.0.0'
>>> Making all in tests
>>> make[2]: Entering directory `E:/mpir-3.0.0/tests'
>>> makefile:1309: warning: overriding commands for target `.s.o'
>>> makefile:1294: warning: ignoring old commands for target `.s.o'
>>> makefile:1313: warning: overriding commands for target `.s.obj'
>>> makefile:1296: warning: ignoring old commands for target `.s.obj'
>>> makefile:1317: warning: overriding commands for target `.s.lo'
>>> makefile:1298: warning: ignoring old commands for target `.s.lo'
>>> Making all in .
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests'
>>> makefile:1309: warning: overriding commands for target `.s.o'
>>> makefile:1294: warning: ignoring old commands for target `.s.o'
>>> makefile:1313: warning: overriding commands for target `.s.obj'
>>> makefile:1296: warning: ignoring old commands for target `.s.obj'
>>> makefile:1317: warning: overriding commands for target `.s.lo'
>>> makefile:1298: warning: ignoring old commands for target `.s.lo'
>>> make[3]: Nothing to be done for `all-am'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests'
>>> Making all in devel
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/devel'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/devel'
>>> Making all in mpn
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpn'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpn'
>>> Making all in fft
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/fft'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/fft'
>>> Making all in mpz
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpz'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpz'
>>> Making all in mpq
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpq'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpq'
>>> Making all in mpf
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpf'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpf'
>>> Making all in rand
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/rand'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/rand'
>>> Making all in misc
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/misc'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/misc'
>>> Making all in cxx
>>> make[3]: Entering directory `E:/mpir-3.0.0/tests/cxx'
>>> make[3]: Nothing to be done for `all'.
>>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/cxx'
>>> make[2]: Leaving directory `E:/mpir-3.0.0/tests'
>>> Making all in mpn
>>> make[2]: Entering directory `E:/mpir-3.0.0/mpn'
>>> makefile:686: warning: overriding commands for target `.s.o'
>>> makefile:671: warning: ignoring old commands for target `.s.o'
>>> makefile:690: warning: overriding commands for target `.s.obj'
>>> makefile:673: warning: ignoring old commands for target `.s.obj'
>>> makefile:694: warning: overriding commands for target `.s.lo'
>>> makefile:675: warning: ignoring old commands for 

Re: [mpir-devel] Re: make errors on Cygwin64 terminal

['Bill Hart' via mpir-devel]

I don't use Cygwin, so I don't have any suggestions.

It looks to me like the makefile does not like Cygwin symlinks. But that is
not a problem I can help solve. I don't know anything about how Cygwin
handles this.

On Thu, 10 Jan 2019 at 19:21, Chintan Joshi  wrote:

> Hi Bill,
> Thanks for the prompt response. Any recommendations on how do I check
> where the unsupported characters are coming from?
> Cheers,
> Chintan
>
> On Wednesday, January 9, 2019 at 10:47:00 PM UTC-8, Chintan Joshi wrote:
>>
>> Hi guys,
>> I need MPIR for a package I am trying to use. I have a Windows 10
>> machine. I start with:
>>
>> $ ./configure --disable-static --enable-shared
>>
>> This appears to go without any hiccups. However, when I run "make ". I
>> even tried make install; no luck yet. Any help would be highly appreciated.
>> Please do let me know if I can provide with any information from my end to
>> help troubleshoot this issue. Below is the what I see:
>>
>> $ make
>> E:/programs/GnuWin32/bin/make  all-recursive
>> make[1]: Entering directory `E:/mpir-3.0.0'
>> Making all in tests
>> make[2]: Entering directory `E:/mpir-3.0.0/tests'
>> makefile:1309: warning: overriding commands for target `.s.o'
>> makefile:1294: warning: ignoring old commands for target `.s.o'
>> makefile:1313: warning: overriding commands for target `.s.obj'
>> makefile:1296: warning: ignoring old commands for target `.s.obj'
>> makefile:1317: warning: overriding commands for target `.s.lo'
>> makefile:1298: warning: ignoring old commands for target `.s.lo'
>> Making all in .
>> make[3]: Entering directory `E:/mpir-3.0.0/tests'
>> makefile:1309: warning: overriding commands for target `.s.o'
>> makefile:1294: warning: ignoring old commands for target `.s.o'
>> makefile:1313: warning: overriding commands for target `.s.obj'
>> makefile:1296: warning: ignoring old commands for target `.s.obj'
>> makefile:1317: warning: overriding commands for target `.s.lo'
>> makefile:1298: warning: ignoring old commands for target `.s.lo'
>> make[3]: Nothing to be done for `all-am'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests'
>> Making all in devel
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/devel'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/devel'
>> Making all in mpn
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpn'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpn'
>> Making all in fft
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/fft'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/fft'
>> Making all in mpz
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpz'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpz'
>> Making all in mpq
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpq'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpq'
>> Making all in mpf
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpf'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpf'
>> Making all in rand
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/rand'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/rand'
>> Making all in misc
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/misc'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/misc'
>> Making all in cxx
>> make[3]: Entering directory `E:/mpir-3.0.0/tests/cxx'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `E:/mpir-3.0.0/tests/cxx'
>> make[2]: Leaving directory `E:/mpir-3.0.0/tests'
>> Making all in mpn
>> make[2]: Entering directory `E:/mpir-3.0.0/mpn'
>> makefile:686: warning: overriding commands for target `.s.o'
>> makefile:671: warning: ignoring old commands for target `.s.o'
>> makefile:690: warning: overriding commands for target `.s.obj'
>> makefile:673: warning: ignoring old commands for target `.s.obj'
>> makefile:694: warning: overriding commands for target `.s.lo'
>> makefile:675: warning: ignoring old commands for target `.s.lo'
>> E:/cygwin64/bin/sh.exe ../libtool  --tag=CC   --mode=compile gcc
>> -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dummy1
>> | sed 's/_$//'`   -O2 -c -o dummy1.lo dummy1.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
>> -DOPERATION_dummy1 -O2 -c dummy1.c  -DDLL_EXPORT -DPIC -o .libs/dummy1.o
>> E:/cygwin64/bin/sh.exe ../libtool  --tag=CC   --mode=compile gcc
>> -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add |
>> sed 's/_$//'`   -O2 -c -o add.lo add.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
>> -DOPERATION_add -O2 -c add.c  -DDLL_EXPORT -DPIC -o .libs/add.o
>> add.c:1:1: error: expected identifier or '(' before '!' token
>>  !▒▒. . / m p n / g e n e 

Re: [mpir-devel] make errors on Cygwin64 terminal

['Bill Hart' via mpir-devel]

I don't really know what might be causing this. You might have to ask some
Cygwin experts.

But one possibility is that there are some unsupported characters in the
path to where you are building MPIR.

Bill.

On Thu, 10 Jan 2019 at 07:47, Chintan Joshi  wrote:

> Hi guys,
> I need MPIR for a package I am trying to use. I have a Windows 10 machine.
> I start with:
>
> $ ./configure --disable-static --enable-shared
>
> This appears to go without any hiccups. However, when I run "make ". I
> even tried make install; no luck yet. Any help would be highly appreciated.
> Please do let me know if I can provide with any information from my end to
> help troubleshoot this issue. Below is the what I see:
>
> $ make
> E:/programs/GnuWin32/bin/make  all-recursive
> make[1]: Entering directory `E:/mpir-3.0.0'
> Making all in tests
> make[2]: Entering directory `E:/mpir-3.0.0/tests'
> makefile:1309: warning: overriding commands for target `.s.o'
> makefile:1294: warning: ignoring old commands for target `.s.o'
> makefile:1313: warning: overriding commands for target `.s.obj'
> makefile:1296: warning: ignoring old commands for target `.s.obj'
> makefile:1317: warning: overriding commands for target `.s.lo'
> makefile:1298: warning: ignoring old commands for target `.s.lo'
> Making all in .
> make[3]: Entering directory `E:/mpir-3.0.0/tests'
> makefile:1309: warning: overriding commands for target `.s.o'
> makefile:1294: warning: ignoring old commands for target `.s.o'
> makefile:1313: warning: overriding commands for target `.s.obj'
> makefile:1296: warning: ignoring old commands for target `.s.obj'
> makefile:1317: warning: overriding commands for target `.s.lo'
> makefile:1298: warning: ignoring old commands for target `.s.lo'
> make[3]: Nothing to be done for `all-am'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests'
> Making all in devel
> make[3]: Entering directory `E:/mpir-3.0.0/tests/devel'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/devel'
> Making all in mpn
> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpn'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpn'
> Making all in fft
> make[3]: Entering directory `E:/mpir-3.0.0/tests/fft'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/fft'
> Making all in mpz
> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpz'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpz'
> Making all in mpq
> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpq'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpq'
> Making all in mpf
> make[3]: Entering directory `E:/mpir-3.0.0/tests/mpf'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/mpf'
> Making all in rand
> make[3]: Entering directory `E:/mpir-3.0.0/tests/rand'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/rand'
> Making all in misc
> make[3]: Entering directory `E:/mpir-3.0.0/tests/misc'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/misc'
> Making all in cxx
> make[3]: Entering directory `E:/mpir-3.0.0/tests/cxx'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `E:/mpir-3.0.0/tests/cxx'
> make[2]: Leaving directory `E:/mpir-3.0.0/tests'
> Making all in mpn
> make[2]: Entering directory `E:/mpir-3.0.0/mpn'
> makefile:686: warning: overriding commands for target `.s.o'
> makefile:671: warning: ignoring old commands for target `.s.o'
> makefile:690: warning: overriding commands for target `.s.obj'
> makefile:673: warning: ignoring old commands for target `.s.obj'
> makefile:694: warning: overriding commands for target `.s.lo'
> makefile:675: warning: ignoring old commands for target `.s.lo'
> E:/cygwin64/bin/sh.exe ../libtool  --tag=CC   --mode=compile gcc
> -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dummy1
> | sed 's/_$//'`   -O2 -c -o dummy1.lo dummy1.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
> -DOPERATION_dummy1 -O2 -c dummy1.c  -DDLL_EXPORT -DPIC -o .libs/dummy1.o
> E:/cygwin64/bin/sh.exe ../libtool  --tag=CC   --mode=compile gcc
> -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add |
> sed 's/_$//'`   -O2 -c -o add.lo add.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
> -DOPERATION_add -O2 -c add.c  -DDLL_EXPORT -DPIC -o .libs/add.o
> add.c:1:1: error: expected identifier or '(' before '!' token
>  !▒▒. . / m p n / g e n e r i c / a d d . c
>  ^
> add.c:1:11: error: stray '\377' in program
>  !▒▒. . / m p n / g e n e r i c / a d d . c
>^
> add.c:1:12: error: stray '\376' in program
>  !▒▒. . / m p n / g e n e r i c / a d d . c
> ^
> add.c:1:14: warning: null character(s) ignored
>  !▒▒. . / m p n / g e n e r i c / a d d . 

Re: [mpir-devel] What does 'gc' mean?

['Bill Hart' via mpir-devel]

That stands for generic C, i.e. no assembly optimisation.

On Sun, 4 Nov 2018 at 20:42, Russell Wallace 
wrote:

> These days, msbuild.bat to build mpir on Windows, seems to want 'gc' to be
> specified for the CPU architecture. What does this mean?
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

Guys, this discussion of "our Swedish friend", and beligerant claims that I
am in fact maintaining MPIR when I have announced that this will not be
happening, is not appropriate for this list.

Please go elsewhere and have this discussion. Once again, this is a
development forum for developers in the community. If you want to know some
of the projects and communities that still use MPIR, please refer to our
website. Go and bother them.

This is your last warning. The next person that posts inappropriate
comments or speculation here will be banned for abusive content!

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

I have repeatedly asked you to stop posting to this list. If you continue
to do so, I will ban you. This list is for developers and we don't have
time to answer stupid questions like this.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

Please note that the mpir-devel list is no longer the place for ordinary
users to ask questions. It is for developers of MPIR. Please direct your
questions about MPIR to the developers of your system which makes use of
MPIR.

Note that MPIR is NOT being maintained by us. It is community maintained.
We merely curate the project for that community. Please direct your
questions there.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

It's needed by various projects, but obviously not by you. Please note we
don't have time for extensive discussions on this topic.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

We never suggested it was not.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: MPIR update announcement

['Bill Hart' via mpir-devel]

Correction. Read:

"have decided to separate the Windows MSVC and Linux/OSX builds of MPIR"

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] MPIR update announcement

['Bill Hart' via mpir-devel]

Dear All,

We have recently updated the MPIR repository to fix a number of
longstanding issues with MPIR and have begun a cleanup effort to lower the
maintenance burden, so that this community project can be maintained into
the future with a minimum of effort for the benefit of the community as a
whole. The repository now passes all Linux and OSX continuous integration
tests and modulo bugs reported on our issue tracker and lack of detection
of recent CPUs, should function correctly.

You will see numerous changes in the next little while across the project,
which we felt best to begin to announce now. The project remains a
community supported project which accepts complete, working pull requests
from the community as its only source of improvement. There is no
"development team" actively developing the project.

Some of the changes include the following:

* Dr. Brian Gladman (the Windows maintainer) and Dr. William Hart (the
Linux/Mac "maintainer"), have decided to separate the Windows MSVC and
Linux/Mac builds of Linux to reduce the complexity of the project.

* Dr. William Hart's GitHub repository [1] will move to a continuous
release model, whereby it is maintained in a continuous state of usability
on Linux and OSX, as tested by Travis/Appveyor CI.

* Brian Gladman will distribute MSVC builds of MPIR from his GitHub account
[2] and website [3].

* The MPIR project will direct support requests from ordinary users of MPIR
to the relevant projects which make use of it, and respond only to
developer support requests.

* The focus will be on maintaining MPIR so it continues to *build* on
Linux, OSX and Windows, and to *detect* newer CPUs (it does not currently
do this -- check if ./config.guess is returning x86_64-... on your machine
-- if so, your CPU is NOT detected -- pull requests to cpuid.c and
configure.ac are welcome).

We will make a formal announcement of all the changes that have been made
in about a month, once the dust has settled a little. Unfortunately, we do
not have time for extensive discussions in the mean time. We hope the
changes will be of ultimate benefit to the community.

Best Wishes,

Dr. William Hart
Dr. Brian Gladman.

[1] https://github.com/wbhart/mpir/
[2] https://github.com/BrianGladman/mpir
[3] http://www.gladman.me.uk

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint C Configuration and IDE integration

['Bill Hart' via mpir-devel]

I don't know which book you are talking about.

This is the MPIR list, not the Flint list.

I don't use a Mac, so can't help you with that.

Instructions on installing Flint are in the Flint manual.


On Thu, 30 Aug 2018 at 04:21, nii ayitey Sosu  wrote:

> Hello,
>
> I am a new Rexford Sosu a student of cryptography and C++ hoping to dwell
> in the research areas of Cryptography.
> I am currently reading your book on Cryptography in C and C++ Second
> Edition.
> I would be glad if i could get further assistance and clarification on the
> following:
> 1. Configuration and Installation of the Flint C application on Mac OS.
> 2. An IDE that works on Mac OS platform to integrate with the Flint C
> libraries.
>
> Your help will be greatly appreciated to help in my understanding and
> practice of the theory knowledge which i will gain from your book.
> Thank you.
>
> Best regards,
> Rex
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Can you just make us a Windows binary instead of source code?

['Bill Hart' via mpir-devel]

There are plenty of MPIR binaries already on the web put up by various
people. We don't really have the bandwidth to host binaries.

What you say about Windows is usually true. There's usually only one
platform to worry about. But with assembly libraries, this isn't the case.
You need a binary built for your processor. That would mean we'd have to
post bundles of binaries, one for each different processor we support. Then
people will want debug versions of the library, and so on.

It's far better if you build it yourself. If you post the specific problems
you are having, I'm sure someone can help you out.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] install mpir

['Bill Hart' via mpir-devel]

It can't find a working 64 bit compiler on your 64 bit machine.

Also the cpu in your machine is probably not supported.

I don't think we can help you, sorry.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fermat's FFT multiplication technique brief explanation

['Bill Hart' via mpir-devel]

On 25 April 2018 at 21:39, Tanushree Banerjee <
banerjee.tanushre...@gmail.com> wrote:

> I see. I know that  standard Schoenhage-Strassen algorithm. has the
> complexity of O(n. log(n). log(log(n)),  this algorithm also has the same
> complexity then?
>

Yes.


>
> I was confused as in the GMP and MPIR documents, it was mentioned that FFT
> based multiplication will have O(n^{k/(k-2)}) complexity
>

What is k?

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fermat's FFT multiplication technique brief explanation

['Bill Hart' via mpir-devel]

On 25 April 2018 at 19:35, Tanushree Banerjee <
banerjee.tanushre...@gmail.com> wrote:

> Thanks @Bill Hart . I was going through the second link. So what is the
> complexity of this algorithm ?
>

It's the same complexity as the standard Schoenhage-Strassen algorithm.


> (I have a jpeg file attached with FFT multiplication algorithm snapshot, I
> think this is not used in the mpir implementation, isnt it? )
>

The algorithm used in MPIR is much more sophisticated. It would not be easy
to write in pseudocode and I would not like to attempt it.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fermat's FFT multiplication technique brief explanation

['Bill Hart' via mpir-devel]

There is, by the way, a brief introduction to the FFT used in MPIR (the
same FFT is used in Flint), here [1].

[1] https://github.com/wbhart/flint2/blob/trunk/fft/README

On 25 April 2018 at 10:18, Bill Hart <goodwillh...@googlemail.com> wrote:

> Hi,
>
> We don't use quite this FFT in MPIR. The best reference on the FFT that I
> know of is by Joerg Arndt.
>
> https://www.jjj.de/fxt/fxtbook.pdf
>
> It doesn't cover the FFT we use, but it gives you the basic ideas that are
> necessary to understand it.
>
> Bill.
>
> On 25 April 2018 at 03:51, Tanushree Banerjee <banerjee.tanushree10@gmail.
> com> wrote:
>
>> I was going through the documentation of MPIR (
>> http://mpir.org/mpir-3.0.0.pdf), specially section 16.1.5 where they
>> refer to the use of Fermat's style FFT. I tried to follow the reference but
>> couldn't quite understand this technique, can anyone explain to me how this
>> Fermat's FFT work? I don't understand how and why the modulus changes from
>> (2^N+1) to (2M+k+3) using FFT-k splitting? If there is some documentation
>> on this with better explanation it would be very helpful! Thanks a lot for
>> your patience
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to mpir-devel@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mpir-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Fermat's FFT multiplication technique brief explanation

['Bill Hart' via mpir-devel]

Hi,

We don't use quite this FFT in MPIR. The best reference on the FFT that I
know of is by Joerg Arndt.

https://www.jjj.de/fxt/fxtbook.pdf

It doesn't cover the FFT we use, but it gives you the basic ideas that are
necessary to understand it.

Bill.

On 25 April 2018 at 03:51, Tanushree Banerjee <
banerjee.tanushre...@gmail.com> wrote:

> I was going through the documentation of MPIR (http://mpir.org/mpir-3.0.0.
> pdf), specially section 16.1.5 where they refer to the use of Fermat's
> style FFT. I tried to follow the reference but couldn't quite understand
> this technique, can anyone explain to me how this Fermat's FFT work? I
> don't understand how and why the modulus changes from (2^N+1) to (2M+k+3)
> using FFT-k splitting? If there is some documentation on this with better
> explanation it would be very helpful! Thanks a lot for your patience
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] MPIR check fails

['Bill Hart' via mpir-devel]

The usual problem with VMs is MPIR not being able to properly detect the
CPU. Sometimes VMs have been known to return an incorrect cpuid.

On the other hand, the usual symptom is a segfault, not a couple of failed
tests.

Can you tell us what ./config.guess returns in the VM (in the MPIR source
tree). It might not actually help, but I've not seen this failure before
(or don't remember it), so I need some other clue.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: The future of computing and the MPIR project

['Bill Hart' via mpir-devel]

Correction: 1U -> 2U

On 26 February 2018 at 14:42, Bill Hart <goodwillh...@googlemail.com> wrote:

> Hi all,
>
> I've been thinking recently about computing, and how an ideal community
> would move forward with MPIR development. I realise we don't actually have
> all that much of a community left, but perhaps my comments will inspire a
> new generation of developers to pitch in, as I myself am totally engaged
> with other projects nowadays and don't have time to commit to MPIR.
>
> Currently I see no reason to duplicate work being done in the official GMP
> project. They are doing a good job of supporting modern CPU
> microarchitectures. I believe MPIR development effort should focus
> elsewhere. But let me explain why that is.
>
> There's a perception in our community (at least amongst older researchers)
> that once clock speeds leveled off in about 2004/5 that Moore's law was at
> an end for single core performance. (GMP and MPIR are currently single core
> libraries.) But that perception is not correct.
>
> In fact, single core performance of CPU's has increased unabated, with a
> predicted leveling off only in the next year or so, with a few minor
> improvements yet to come due to shrinking of dies.
>
> Whilst clock speeds have not gone up, pipelines have gotten deeper,
> numerous new features have been added, including various revisions of SSE
> and then AVX, more integer ports, specialised instructions for
> multiprecision arithmetic (yes the kind GMP/MPIR specialise in),
> performance management through temperature profiles, hyperthreading (though
> this is usually useless for superoptimised code; it's great for code coming
> from a C compiler, depending on the application) and more recently
> real-time AI adjustment of silicon usage to optimise performance.
>
> All of this development means that nothing prior to Intel's Core
> architecture and nothing prior to AMD's K10 architecture is now relevant,
> even for single core performance. But even these won't be relevant much
> longer. There's a feeling that this past year, Core 2 has finally become
> totally obsolete.
>
> Looking to the future, bigger changes are coming. Because yields go down
> as die sizes go up, it is inevitable that large monolithic CPU cores will
> give way to a far greater number of smaller dies, especially as we move
> from the current 14nm technology to an eventual 5nm, where things will
> surely start to get really hard (Intel is already reportedly having major
> problems with yield at 10nm).
>
> Then there's the performance decreases we have seen due to Spectre and
> Meltdown. A lot of the superoptimisation MPIR does is surely worthless in
> light of this. I see more and more of this sort of thing happening in the
> future.
>
> Like it or not, the era of single core performance increases is almost at
> an end.
>
> MPIR is also about 3-5 years behind anyway; the latest Intel
> microarchitecture we optimise for is Skylake, which was 2015 and the latest
> AMD microarchitecture we had a good look at was Piledriver, from 2012, not
> that AMD has been terribly relevant in the period 2012-2016. Admittedly
> server architectures are usually a few generations behind desktop
> architectures.
>
> But the face of CPU and computing technology development is all changing
> fast. Abstractly, modern computer processors consist (or will consist) of
> three components, a CPU, GPU and TPU (tensor processing unit). The CPU as
> we know it is becoming less relevant every day (it will still continue to
> exist, but will change radically; for example I/O, memory controllers and
> cache will be separated from an increasing number of small dies for
> arithmetic pipelines).
>
> Modern Ryzen/Threadripper/EPYC CPU's from AMD already basically use a kind
> of TPU to control the temperature profile of the CPU (switching silicon on
> and off and scheduling which silicon does what). Result: 10-30% performance
> improvement by adapting to the values coming from bazillions of sensors,
> based on what code is currently running.
>
> Modern EPYC server racks have 640 CPU cores, but this is a tiny fraction
> of their compute power. By far, the greatest part of their compute power is
> in their GPU's. If I have my calculations correct, in excess of 320,000 GPU
> cores (actually there are three different kinds of cores in the GPU's), all
> in a 1U rack. These are targeted at Data Centres, AI research and
> Scientific computing, but why not also computer algebra system users? You
> can use a GPU for Groebner basis computations or for linear algebra, right?
> Why not other things too?
>
> Still worried about memory bandwidth? How does 11 Gbps sound?
>
> Then there are tensor cores. Nvidia's Volta 

[mpir-devel] The future of computing and the MPIR project

['Bill Hart' via mpir-devel]

Hi all,

I've been thinking recently about computing, and how an ideal community
would move forward with MPIR development. I realise we don't actually have
all that much of a community left, but perhaps my comments will inspire a
new generation of developers to pitch in, as I myself am totally engaged
with other projects nowadays and don't have time to commit to MPIR.

Currently I see no reason to duplicate work being done in the official GMP
project. They are doing a good job of supporting modern CPU
microarchitectures. I believe MPIR development effort should focus
elsewhere. But let me explain why that is.

There's a perception in our community (at least amongst older researchers)
that once clock speeds leveled off in about 2004/5 that Moore's law was at
an end for single core performance. (GMP and MPIR are currently single core
libraries.) But that perception is not correct.

In fact, single core performance of CPU's has increased unabated, with a
predicted leveling off only in the next year or so, with a few minor
improvements yet to come due to shrinking of dies.

Whilst clock speeds have not gone up, pipelines have gotten deeper,
numerous new features have been added, including various revisions of SSE
and then AVX, more integer ports, specialised instructions for
multiprecision arithmetic (yes the kind GMP/MPIR specialise in),
performance management through temperature profiles, hyperthreading (though
this is usually useless for superoptimised code; it's great for code coming
from a C compiler, depending on the application) and more recently
real-time AI adjustment of silicon usage to optimise performance.

All of this development means that nothing prior to Intel's Core
architecture and nothing prior to AMD's K10 architecture is now relevant,
even for single core performance. But even these won't be relevant much
longer. There's a feeling that this past year, Core 2 has finally become
totally obsolete.

Looking to the future, bigger changes are coming. Because yields go down as
die sizes go up, it is inevitable that large monolithic CPU cores will give
way to a far greater number of smaller dies, especially as we move from the
current 14nm technology to an eventual 5nm, where things will surely start
to get really hard (Intel is already reportedly having major problems with
yield at 10nm).

Then there's the performance decreases we have seen due to Spectre and
Meltdown. A lot of the superoptimisation MPIR does is surely worthless in
light of this. I see more and more of this sort of thing happening in the
future.

Like it or not, the era of single core performance increases is almost at
an end.

MPIR is also about 3-5 years behind anyway; the latest Intel
microarchitecture we optimise for is Skylake, which was 2015 and the latest
AMD microarchitecture we had a good look at was Piledriver, from 2012, not
that AMD has been terribly relevant in the period 2012-2016. Admittedly
server architectures are usually a few generations behind desktop
architectures.

But the face of CPU and computing technology development is all changing
fast. Abstractly, modern computer processors consist (or will consist) of
three components, a CPU, GPU and TPU (tensor processing unit). The CPU as
we know it is becoming less relevant every day (it will still continue to
exist, but will change radically; for example I/O, memory controllers and
cache will be separated from an increasing number of small dies for
arithmetic pipelines).

Modern Ryzen/Threadripper/EPYC CPU's from AMD already basically use a kind
of TPU to control the temperature profile of the CPU (switching silicon on
and off and scheduling which silicon does what). Result: 10-30% performance
improvement by adapting to the values coming from bazillions of sensors,
based on what code is currently running.

Modern EPYC server racks have 640 CPU cores, but this is a tiny fraction of
their compute power. By far, the greatest part of their compute power is in
their GPU's. If I have my calculations correct, in excess of 320,000 GPU
cores (actually there are three different kinds of cores in the GPU's), all
in a 1U rack. These are targeted at Data Centres, AI research and
Scientific computing, but why not also computer algebra system users? You
can use a GPU for Groebner basis computations or for linear algebra, right?
Why not other things too?

Still worried about memory bandwidth? How does 11 Gbps sound?

Then there are tensor cores. Nvidia's Volta architecture has 640 Tensor
cores, for 100 teraflops per device.

Google's second generation TPU's (what Google use in their data centres for
photo processing and Google ranking: 100 million photos processed per day
per device) are 15-30 times faster than Nvidia's GPU's for many tasks (23
petaflops per rack). And Nvidia are already ahead of AMD (who make Ryzen,
Threadripper and EPYC).

It's very clear that the future of MPIR is in multicore/GPU/TPU code. This
means a fundamental change in approach, and a lot of work.

If 

Re: [mpir-devel] can't pass compiliation involving mpir

['Bill Hart' via mpir-devel]

On 19 February 2018 at 21:58, <tamwen...@gmail.com> wrote:

> Mr. Hart,
>
> May I ask a follow-up question then?  I did the same things on my Mac OS
> desktop as on my Ubuntu laptop, same g++ command (for compiling the same
> cpp file), same configure command (for installing mpir).  Well, I didn't
> have to manually install m4 on my Mac OS while I had to do it on my Ubuntu
> as you advised earlier.  So I suppose m4 was pre-installed on Mac OS.  Yet
> I encountered no compiling issues on the Mac OS like the ones on the
> Ubuntu.  Any insight on this?
>

No idea.


>
> With regard to your latest reply, I didn't pass --enable-gmpcompat to
> configure.  Must I do this?
>

If you want a gmp.h and libgmp, you need to pass this to configure.


> I just sort of thought since I didn't do it on my Mac OS and it worked, I
> probably could repeat it on my Ubuntu.  I need some more detailed
> instructions on how to accomplish what you mentioned in your reply.  Sorry
> I'm a newbie on this.  After mpir installation on my Ubuntu computer, the
> relevant header files are in the default /usr/local/include/ and the
> libraries are in the default /usr/local/lib/.  Based on your reply, I'm
> guessing here's what I need to do.  FIrst, configure and install mpir again
> with
>
> ./configure --with-yasm=/usr/local/bin/yasm --enable-cxx
> -enable-gmpcompat
>
> Then in my source code, instead of #include  directive, I should
> put
>
> #include "/usr/local/include/mpir.h"
> #include "/usr/local/include/gmp.h"
>

You put just the second line, not the mpir.h line.


>
> And I'm lost on the proper g++ command.
>
> Please enlighten me.  Thank you so much for your time.
>
> On Monday, February 19, 2018 at 12:38:23 PM UTC-8, Bill Hart wrote:
>>
>> You need to give the location of the .h files (mpir.h or gmp.h if you
>> pass --enable-gmpcompat to configure). For this you must use the -I
>> directive to gcc. You also need to tell it where to find the library, with
>> the -L directive. These are always required when linking against libraries.
>>
>
It's -I/path1 -L/path2

where path1 is the directory where the mpir.h/gmp.h file is installed and
path2 is the directory where the library (libgmp.so) is installed.

You also need -lgmp (assuming you passed --enable-gmpcompat). But I think
you had that.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] can't pass compiliation involving mpir

['Bill Hart' via mpir-devel]

You need to give the location of the .h files (mpir.h or gmp.h if you pass
--enable-gmpcompat to configure). For this you must use the -I directive to
gcc. You also need to tell it where to find the library, with the -L
directive. These are always required when linking against libraries.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] configure doesn't generate Makefile, couldn't proceed with install

['Bill Hart' via mpir-devel]

You simply need to install m4 on your system. You can either install it
using apt-get, or download the tarball locally, build and install it.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Broadwell support

['Bill Hart' via mpir-devel]

There is also this file, which is by Jens, and can be used on Haswell,
Broadwell and Skylake. It relies on AVX/BMI2.

You may need to convert line endings. Not sure.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.


addadd_n.as
Description: Binary data

Re: [mpir-devel] Broadwell support

['Bill Hart' via mpir-devel]

Just to clarify for Fernando, the code Brian is referring to here is in the
x86_64w directory and is independent of the code that needs to be added to
the x86_64 directory. Native windows uses a different ABI and where
possible MPIR supports it explicitly, rather than automatically.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: Broadwell support

['Bill Hart' via mpir-devel]

The following would be important tickets to resolve before updating the
GMP_VERSION to 6.1.0 (or releasing MPIR-3.0.0). Otherwise we should do a
2.8.0 instead.

https://github.com/wbhart/mpir/issues/191
https://github.com/wbhart/mpir/issues/190

There's a list of other tickets marked for a 2.8.0 or 3.0.0 release here:

https://github.com/wbhart/mpir/milestone/2

But I see no others in that list which are absolutely critical.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: Broadwell support

['Bill Hart' via mpir-devel]

The ticket for Broadwell support is here:

https://github.com/wbhart/mpir/issues/198

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: Broadwell support

['Bill Hart' via mpir-devel]

It's Haswells and Broadwells that may not support BMI2. Note that we now
occasionally encounter such machines.

https://github.com/wbhart/mpir/issues/209

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: Broadwell support

['Bill Hart' via mpir-devel]

For a release, we need to fix a performance issue noted by Marcel Keller.
It shows up on Ivy Bridge when linking against MPIR with pthreads vs
without (yes it's very strange).

A program used by Marcel to get timings is attached.

Also attached are addmul_1.asm by Jens Nurmann, which tries to fix the
issue. And there is a similar file addmul_1.opt by Marcell which also fixes
the issue.

Unfortunately, speed says Jens' code is faster, but Marcell's program says
his is much faster. This is likely down to the aforementioned issues with
speed on Intel processors.

This should be resolved and the correct version included in MPIR (and the
Ivy Bridge tuning may need to be redone). Of course try will also needs to
be run for 24 hours on the code that is chosen to ensure it is correct.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.


addmul_1.opt.s
Description: Binary data
#include 
#include 
#include 

const int t = 5;
const int n = 1e8;

void mpn(mp_limb_t* zz, mp_limb_t* x, mp_limb_t y)
{
struct timespec start, stop;
clock_gettime(CLOCK_REALTIME, );
for (int i = 0; i < n; i++)
zz[t] = mpn_addmul_1(zz, x, t, y);
clock_gettime(CLOCK_REALTIME, );
printf("mpn_addmul_1: %f\n", 1e-9 * (stop.tv_nsec - start.tv_nsec) +
(stop.tv_sec - start.tv_sec));
}

int main()
{
mp_limb_t x[t+1], y, z[t+1];
mpn(z, x, y);
}



addmul_1.asm
Description: Binary data

[mpir-devel] Re: Broadwell support

['Bill Hart' via mpir-devel]

Attached are two more files which should be included in the Broadwell
directory. They should also be faster on Skylake, though Skylake will
automatically look in there.

I don't think they can work on Haswell, but this could be checked.

Also, I forgot one step in the above post:

* Make a tuning file for Broadwell after everything is running (it
shouldn't be necessary to do this for Haswell, as logops don't feature in
tuning, but it should also be done for Skylake when the files attached to
this post are added).

The tuning file for broadwell is in
mpn/x86_64/haswell/broadwell/gmp-mparam.h

To generate one, configure on a broadwell machine and do:

cd tune
make tune

copy the output into the relevant file.

Also, I should point out the ajs superoptimiser that was written for ODK:

https://github.com/akruppa/ajs

There's also a version here:

https://github.com/alexjbest/ajs

I'm not sure which is more up-to-date.

Unfortunately, setting up a machine so this can be used is very hard (it
requires root access and a lot of configuration of the kernel, as Intel
have made getting cycle accurate timings really, really hard nowadays).
This is not an automatic process, so expect to spend weeks working on it if
you decide to do it.

The files attached to this post have already been superoptimised for
Skylake (but not for Broadwell).

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.


addsub_n.as
Description: Binary data


subadd_n.as
Description: Binary data

Re: [mpir-devel] mpir-3.0.0 fails 37 tests on Linux with processor Intel Celeron G1820

['Bill Hart' via mpir-devel]

Great to hear.

On 24 January 2018 at 21:57, Daniel Șuteu <triz...@gmail.com> wrote:

> Building it for `ivybridge-unknown-linux-gnu` does indeed solve the
> problem and all the tests are passed correctly.
>
> Thank you very much.
>
> On Wednesday, January 24, 2018 at 10:38:48 PM UTC+2, Bill Hart wrote:
>>
>> That looks correct. Perhaps this Haswell is missing some instructions.
>> They do exist, unfortunately.
>>
>> You can try forcing it to build with ivybridge-unknown-linux-gnu instead
>> of haswell-unknown-linux-gnu and see if the problem goes away.
>>
>> On 24 January 2018 at 21:36, Daniel Șuteu <tri...@gmail.com> wrote:
>>
>>> The output of `./config.guess` is: haswell-unknown-linux-gnu
>>>
>>> On Wednesday, January 24, 2018 at 10:32:23 PM UTC+2, Bill Hart wrote:
>>>>
>>>> What is the output of config.guess
>>>>
>>>> On 24 January 2018 at 18:28, Daniel Șuteu <tri...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> There seems to be minor issue with mpir-3.0.0 under Intel Celeron
>>>>> G1820 (compiled on Arch Linux with GCC-7.2.1+20180116-1).
>>>>>
>>>>> Some tests (37 of them) fail with the error "Illegal instruction".
>>>>>
>>>>> Bellow is a snippet of the output of `make check`:
>>>>>
>>>>> libtool: link: gcc -march=native -O3 -pipe -fstack-protector-strong
>>>>> --param=ssp-buffer-size=4 -fno-plt -Wl,-O1 -Wl,--sort-common
>>>>> -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/t-tdiv_qr
>>>>> t-tdiv_qr.o  ../../tests/.libs/libtests.a /tmp/mpir-3.0.0/.libs/libmpir.so
>>>>> -lm ../../.libs/libmpir.so
>>>>> make[4]: Leaving directory '/tmp/mpir-3.0.0/tests/mpn'
>>>>> make  check-TESTS
>>>>> make[4]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
>>>>> make[5]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
>>>>> PASS: t-addadd_n
>>>>> PASS: t-addsub_n
>>>>> PASS: t-aors_1
>>>>> PASS: t-asmtype
>>>>> ../../test-driver: line 107:  3482 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_bdiv_q
>>>>> ../../test-driver: line 107:  3501 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_bdiv_q_n
>>>>> ../../test-driver: line 107:  3566 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_bdiv_qr_n
>>>>> ../../test-driver: line 107:  3540 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_bdiv_qr
>>>>> ../../test-driver: line 107:  3603 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_div_q
>>>>> ../../test-driver: line 107:  3626 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_div_qr
>>>>> ../../test-driver: line 107:  3672 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_divappr_q
>>>>> ../../test-driver: line 107:  3660 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-dc_div_qr_n
>>>>> ../../test-driver: line 107:  3718 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-divebyff
>>>>> ../../test-driver: line 107:  3749 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-divebyfobm1
>>>>> PASS: t-divrem_1
>>>>> ../../test-driver: line 107:  3803 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-fat
>>>>> ../../test-driver: line 107:  3825 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>> FAIL: t-gcdext
>>>>> PASS: t-get_d
>>>>> PASS: t-instrument
>>>>> ../../test-driver: line 107:  3888 Illegal instruction (core
>>>>> dumped) "$@" > $log_file 2>&1
>>>>

Re: [mpir-devel] mpir-3.0.0 fails 37 tests on Linux with processor Intel Celeron G1820

['Bill Hart' via mpir-devel]

That looks correct. Perhaps this Haswell is missing some instructions. They
do exist, unfortunately.

You can try forcing it to build with ivybridge-unknown-linux-gnu instead of
haswell-unknown-linux-gnu and see if the problem goes away.

On 24 January 2018 at 21:36, Daniel Șuteu <triz...@gmail.com> wrote:

> The output of `./config.guess` is: haswell-unknown-linux-gnu
>
> On Wednesday, January 24, 2018 at 10:32:23 PM UTC+2, Bill Hart wrote:
>>
>> What is the output of config.guess
>>
>> On 24 January 2018 at 18:28, Daniel Șuteu <tri...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> There seems to be minor issue with mpir-3.0.0 under Intel Celeron G1820
>>> (compiled on Arch Linux with GCC-7.2.1+20180116-1).
>>>
>>> Some tests (37 of them) fail with the error "Illegal instruction".
>>>
>>> Bellow is a snippet of the output of `make check`:
>>>
>>> libtool: link: gcc -march=native -O3 -pipe -fstack-protector-strong
>>> --param=ssp-buffer-size=4 -fno-plt -Wl,-O1 -Wl,--sort-common
>>> -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/t-tdiv_qr
>>> t-tdiv_qr.o  ../../tests/.libs/libtests.a /tmp/mpir-3.0.0/.libs/libmpir.so
>>> -lm ../../.libs/libmpir.so
>>> make[4]: Leaving directory '/tmp/mpir-3.0.0/tests/mpn'
>>> make  check-TESTS
>>> make[4]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
>>> make[5]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
>>> PASS: t-addadd_n
>>> PASS: t-addsub_n
>>> PASS: t-aors_1
>>> PASS: t-asmtype
>>> ../../test-driver: line 107:  3482 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_bdiv_q
>>> ../../test-driver: line 107:  3501 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_bdiv_q_n
>>> ../../test-driver: line 107:  3566 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_bdiv_qr_n
>>> ../../test-driver: line 107:  3540 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_bdiv_qr
>>> ../../test-driver: line 107:  3603 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_div_q
>>> ../../test-driver: line 107:  3626 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_div_qr
>>> ../../test-driver: line 107:  3672 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_divappr_q
>>> ../../test-driver: line 107:  3660 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-dc_div_qr_n
>>> ../../test-driver: line 107:  3718 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-divebyff
>>> ../../test-driver: line 107:  3749 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-divebyfobm1
>>> PASS: t-divrem_1
>>> ../../test-driver: line 107:  3803 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-fat
>>> ../../test-driver: line 107:  3825 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-gcdext
>>> PASS: t-get_d
>>> PASS: t-instrument
>>> ../../test-driver: line 107:  3888 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-hgcd
>>> ../../test-driver: line 107:  3936 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-inv_div_q
>>> ../../test-driver: line 107:  3966 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-inv_div_qr
>>> ../../test-driver: line 107:  3998 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-inv_div_qr_n
>>> ../../test-driver: line 107:  4024 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-inv_divappr_q
>>> ../../test-driver: line 107:  4056 Illegal instruction (core dumped)
>>> "$@" > $log_file 2>&1
>>> FAIL: t-inv_divappr_q_n
>>> PASS: t-iord_u
>>> ../../test-driver: line 107:  4082 Illegal instructio

Re: [mpir-devel] mpir-3.0.0 fails 37 tests on Linux with processor Intel Celeron G1820

['Bill Hart' via mpir-devel]

What is the output of config.guess

On 24 January 2018 at 18:28, Daniel Șuteu  wrote:

> Hello,
>
> There seems to be minor issue with mpir-3.0.0 under Intel Celeron G1820
> (compiled on Arch Linux with GCC-7.2.1+20180116-1).
>
> Some tests (37 of them) fail with the error "Illegal instruction".
>
> Bellow is a snippet of the output of `make check`:
>
> libtool: link: gcc -march=native -O3 -pipe -fstack-protector-strong
> --param=ssp-buffer-size=4 -fno-plt -Wl,-O1 -Wl,--sort-common
> -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/t-tdiv_qr
> t-tdiv_qr.o  ../../tests/.libs/libtests.a /tmp/mpir-3.0.0/.libs/libmpir.so
> -lm ../../.libs/libmpir.so
> make[4]: Leaving directory '/tmp/mpir-3.0.0/tests/mpn'
> make  check-TESTS
> make[4]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
> make[5]: Entering directory '/tmp/mpir-3.0.0/tests/mpn'
> PASS: t-addadd_n
> PASS: t-addsub_n
> PASS: t-aors_1
> PASS: t-asmtype
> ../../test-driver: line 107:  3482 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_bdiv_q
> ../../test-driver: line 107:  3501 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_bdiv_q_n
> ../../test-driver: line 107:  3566 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_bdiv_qr_n
> ../../test-driver: line 107:  3540 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_bdiv_qr
> ../../test-driver: line 107:  3603 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_div_q
> ../../test-driver: line 107:  3626 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_div_qr
> ../../test-driver: line 107:  3672 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_divappr_q
> ../../test-driver: line 107:  3660 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-dc_div_qr_n
> ../../test-driver: line 107:  3718 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-divebyff
> ../../test-driver: line 107:  3749 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-divebyfobm1
> PASS: t-divrem_1
> ../../test-driver: line 107:  3803 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-fat
> ../../test-driver: line 107:  3825 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-gcdext
> PASS: t-get_d
> PASS: t-instrument
> ../../test-driver: line 107:  3888 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-hgcd
> ../../test-driver: line 107:  3936 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-inv_div_q
> ../../test-driver: line 107:  3966 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-inv_div_qr
> ../../test-driver: line 107:  3998 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-inv_div_qr_n
> ../../test-driver: line 107:  4024 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-inv_divappr_q
> ../../test-driver: line 107:  4056 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-inv_divappr_q_n
> PASS: t-iord_u
> ../../test-driver: line 107:  4082 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-invert
> ../../test-driver: line 107:  4147 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-lorrshift1
> PASS: t-mp_bases
> ../../test-driver: line 107:  4179 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-matrix22
> ../../test-driver: line 107:  4235 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-mullow_basecase
> ../../test-driver: line 107:  4264 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-mullowhigh
> ../../test-driver: line 107:  4290 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-mulmid
> ../../test-driver: line 107:  4315 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-mulmod_2expm1
> ../../test-driver: line 107:  4348 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-mulmod_2expp1
> PASS: t-perfsqr
> ../../test-driver: line 107:  4377 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-neg
> ../../test-driver: line 107:  4438 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-redc_1
> ../../test-driver: line 107:  4452 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-sb_bdiv_q
> ../../test-driver: line 107:  4493 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-sb_bdiv_qr
> ../../test-driver: line 107:  4512 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-sb_div_q
> ../../test-driver: line 107:  4554 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-sb_div_qr
> ../../test-driver: line 107:  4586 Illegal instruction (core dumped)
> "$@" > $log_file 2>&1
> FAIL: t-sb_divappr_q

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

On 24 January 2018 at 17:32, Brian Gladman <b...@gladman.plus.com> wrote:

> On 24/01/2018 16:07, 'Bill Hart' via mpir-devel wrote:
>
> [snip]
> > On a more optimistic note, the work that Jens Nurmann and I have
> done in
> > adding new assembler code for recent machine architectures is
> available
> > for those who are willing to work with the repository version of
> MPIR.
> >
> > And it may well make sense to add the new functions to my repository
> > anyway as it will at least mean that I can keep the repository
> versions
> > of both MPIR and FLINT for Windows x64 in a fully working state (the
> > FLINT changes needed are very limited as discussed earlier).
> >
> >
> > Was all Jens' Broadwell optimisation committed. The last I recall we
> > were waiting for someone with a Broadwell to test and see which
> > functions were faster than the current ones. This would have had to be
> > done on a Linux system, since it isn't possible to get reliable timings
> > on a Windows box, unfortunately.
> >
> > Or are you only talking about Skylake and Nehelem, which I think is in
> > MPIR-3.0.0.
>
> I was thinking about Broadwell and Skylake but couldn't remember what
> got in to MPIR-3
>

Skylake got in, but Broadwell did not. There was an ongoing conversation
between David and Jens about it. I think it petered out though. I can
understand why given that I wasn't able to attend to their correspondence
in a timely manner.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

On 24 January 2018 at 16:45, Brian Gladman <b...@gladman.plus.com> wrote:

> On 24/01/2018 12:15, 'Bill Hart' via mpir-devel wrote:
>
> [snip]
> > What has just occurred to me is that we can arrive at a 'perfect'
> MPIR
> > integer API by reversing how the doubles and integers are returned:
> >
> > mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src)
> > mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src)
> >
> > If these returned a 64 bit integer and I had code like:
> >
> > long s = mpz_get_2exp_d(r, src);
> >
> > would this automatically cast down to the shorter length integer? I'm
> > not sure I see why this is better than the current situation?
>
> The fix doesn't do a lot here but it helps in two other situations.
>
> With what we have now, when a 64-bit value is stored via a pointer into
> a 32-bit location, the upper 32-bits will overwrite data in adjoining
> locations and cause erroneous results and/or crashes.
>
> Also, when a 32-bit value is stored via a pointer into a 64-bit
> location, the upper 32-bits won't be overwritten so whatever was in the
> top 32-bits will remain causing the value to be incorrect.
>
> These bugs turn up not infrequently on Windows x64 and it would be good
> to remove them.
>
> > Well, it is better in the sense that it gives the full 64 bits, which we
> > will obviously use in Flint. But does it make writing code any easier?
>
> Yes in that it will make it easier to write code that doesn't contain
> the sort of bugs that we are discussing.
>
> > Also, any existing code will not be using these and will have to be
> > rewritten. Not a big problem for Flint, as you have noted, but maybe for
> > other systems?
>
> Not immediately since I envisage these as functions that are additions
> to, rather than replacements of, the existing functions.  We might, of
> course, remove the older ones later.
>
> > As the MPIR Windows developer/maintainer, moving to an MPIR API that
> is
> > pure in respect of integer length is compelling, especially so as it
> is
> > not hard to achieve at the code level.
> >
> > But it would seem that making this change won't be possible unless we
> > can find a volunteer to do the work that this requires for Linux/Unix
> > and for delivering new MPIR distributions.
> >
> > I very much doubt we will find one. I've been calling for people to
> > contribute for years. No one has stepped forward and stuck with it.
> >
> > It requires a very skilled individual, most of whom are busy with other
> > projects.
>
> > Leaving FLINT on Windows x64 (and other applications that depend on
> it)
> > reliant on old versions of MPIR and GMP would effectively mean that
> it
> > would progressively die on Windows since it would not be able to take
> > advantage of the work that Jens Nurmann and I have done in adding
> > assembler code support for recent Intel processor architectures.
> >
> > I think MPIR will die on all platforms, in time. The community just
> > doesn't have any interest in it. Were the interest there, we'd know by
> now.
> >
> > People only seem keen on fixing it if it stops building. They don't care
> > about performance, adding functionality or dealing with tickets that
> > aren't immediately breaking their code.
>
> > It's especially a shame that the work Jens put in still sits in limbo.
> > But I just don't have the time to do the testing, profiling and
> > integration required. There's a week of work for someone who knows what
> > they are doing, or a months for someone who is new to MPIR but otherwise
> > very skilled.
>
> On a more optimistic note, the work that Jens Nurmann and I have done in
> adding new assembler code for recent machine architectures is available
> for those who are willing to work with the repository version of MPIR.
>
> And it may well make sense to add the new functions to my repository
> anyway as it will at least mean that I can keep the repository versions
> of both MPIR and FLINT for Windows x64 in a fully working state (the
> FLINT changes needed are very limited as discussed earlier).
>

Was all Jens' Broadwell optimisation committed. The last I recall we were
waiting for someone with a Broadwell to test and see which functions were
faster than the current ones. This would have had to be done on a Linux
system, since it isn't possible to get reliable timings on a Windows box,
unfortunately.

Or are you only talking about Skylake and Nehelem, which I think is in
MPIR-3.0.0.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

On 24 January 2018 at 12:19, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote:
> >
> >
> > On 23 January 2018 at 22:13, Brian Gladman <b...@gladman.plus.com
> > <mailto:b...@gladman.plus.com>> wrote:
> >
> > On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> > > Hi Brian,
> > >
> > > I believe the problem is that our LLL code actually relies on a 64
> bit
> > > exponent on Windows 64 (in practice, not just in theory), but GMP
> (or
> > > the compatibility function) only returns a 32 bit one.
> >
> > Ah, OK.  So basically FLINT won't work on Windows x64 because longs
> are
> > 32-bits and FLINT expects longs to be 64-bits.
> >
> > So FLINT on Windows x64 won't work at all with current versions of
> GMP
> > since longs are 32-bits. And it won't work with MPIR 3 because we
> have a
> > function that uses 32 bit longs in its interface.
> >
> > But could we not have a 'compatibility define' in MPIR that makes the
> > function work for 64-bit longs when needed?
> >
> > I guess that's an option. It won't fix the GMP issue for us either way.
>
> I was pondering this issue further last night and it occurred to me that
> there is a solution that I wish I had thought of earlier.
>
> The introduction of the typedefs mpir_ui and mpir_si for unsigned and
> signed integers in the MPIR API was an almost complete solution to the
> Windows x64 problem caused by its use of 32-bit integers.  It worked
> almost everywhere as a result of automatic promotion rules except for
> just two functions that returned integers via pointers:
>
> double mpz_get_d_2exp(mpir_si *exp2, mpz_srcptr src)
> double mpf_get_d_2exp(mpir_si *exp2, mpf_srcptr src)
>
> These caused a number of bugs since 64-bit values would be written into
> 32-bit ones corrupting adjoining memory and 32-bit values would be
> written to 64-bit ones leaving 32-bits undefined.
>
> What has just occurred to me is that we can arrive at a 'perfect' MPIR
> integer API by reversing how the doubles and integers are returned:
>
> mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src)
> mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src)
>

If these returned a 64 bit integer and I had code like:

long s = mpz_get_2exp_d(r, src);

would this automatically cast down to the shorter length integer? I'm not
sure I see why this is better than the current situation?

Well, it is better in the sense that it gives the full 64 bits, which we
will obviously use in Flint. But does it make writing code any easier?

Also, any existing code will not be using these and will have to be
rewritten. Not a big problem for Flint, as you have noted, but maybe for
other systems?


>
> By introducing these two functions we will have no more 32/64-bit
> trouble on Windows x64 provided these new functions are used in place of
> the old ones.  And, if the FLINT code is a typical example, the work
> needed to switch to these new functions will be small at least at the
> code level.
>
> This still leaves the problem in GMP but FLINT has a GMP compatibility
> layer where these two new functions could be derived from their GMP
> equivalents or implemented directly.
>

Correct.


>
> As the MPIR Windows developer/maintainer, moving to an MPIR API that is
> pure in respect of integer length is compelling, especially so as it is
> not hard to achieve at the code level.
>
> But it would seem that making this change won't be possible unless we
> can find a volunteer to do the work that this requires for Linux/Unix
> and for delivering new MPIR distributions.
>

I very much doubt we will find one. I've been calling for people to
contribute for years. No one has stepped forward and stuck with it.

It requires a very skilled individual, most of whom are busy with other
projects.


>
> Leaving FLINT on Windows x64 (and other applications that depend on it)
> reliant on old versions of MPIR and GMP would effectively mean that it
> would progressively die on Windows since it would not be able to take
> advantage of the work that Jens Nurmann and I have done in adding
> assembler code support for recent Intel processor architectures.


I think MPIR will die on all platforms, in time. The community just doesn't
have any interest in it. Were the interest there, we'd know by now.

People only seem keen on fixing it if it stops building. They don't care
about performance, adding functionality or dealing with tickets that aren't
immediately breaking their code.

It's a shame it has come to this, after all the work we invested. But this
is the reality we are faced with.

It's especially a sh

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

There's quite a bit of work required to add files to MPIR on the *nix side.
We also need some tests, which are not trivial here.

Anyway, as I say, I'm only merging patches for MPIR nowadays. I have
hundreds of other things I need to do. I can't spend a month a year working
on MPIR any more.

On 23 January 2018 at 23:50, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote:
> >
> >
> > On 23 January 2018 at 22:13, Brian Gladman <b...@gladman.plus.com
> > <mailto:b...@gladman.plus.com>> wrote:
> >
> > On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> > > Hi Brian,
> > >
> > > I believe the problem is that our LLL code actually relies on a 64
> bit
> > > exponent on Windows 64 (in practice, not just in theory), but GMP
> (or
> > > the compatibility function) only returns a 32 bit one.
> >
> > Ah, OK.  So basically FLINT won't work on Windows x64 because longs
> are
> > 32-bits and FLINT expects longs to be 64-bits.
> >
> > So FLINT on Windows x64 won't work at all with current versions of
> GMP
> > since longs are 32-bits. And it won't work with MPIR 3 because we
> have a
> > function that uses 32 bit longs in its interface.
> >
> > But could we not have a 'compatibility define' in MPIR that makes the
> > function work for 64-bit longs when needed?
> >
> >
> > I guess that's an option. It won't fix the GMP issue for us either way.
> >
> > The problem of course is that an mpz (and hence an fmpz) can be 2^31
> > words, not bits. Therefore the number of bits in such an exponent can be
> > larger than 2^32.
> >
> > Any solution requires non-trivial work, anyway. And unfortunately I have
> > no time for such things these days. I can only merge patches into MPIR.
> > That's all I have time for. The community is suppose to be taking over
> > the job of handling releases, etc. But so far there haven't been any
> > volunteers.
>
> At a code level the changes needed to fix this are not large if we do it
> by adding two functions in MPIR in parallel with the existing ones - say
> mpz_get_d_2exp_si() and mpf_get_d_2exp_si().  This would need changes in
> at most four lines in FLINT and the work in MPIR is not large (I would
> be happy to do it).
>
> But I do understand the wider cost in doing releases etc.  Nevertheless
> it seems a pity to give up on FLINT on Windows 64 when an MPIR based fix
> looks to be feasible.
>
>  Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

On 23 January 2018 at 22:13, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote:
> > Hi Brian,
> >
> > I believe the problem is that our LLL code actually relies on a 64 bit
> > exponent on Windows 64 (in practice, not just in theory), but GMP (or
> > the compatibility function) only returns a 32 bit one.
>
> Ah, OK.  So basically FLINT won't work on Windows x64 because longs are
> 32-bits and FLINT expects longs to be 64-bits.
>
> So FLINT on Windows x64 won't work at all with current versions of GMP
> since longs are 32-bits. And it won't work with MPIR 3 because we have a
> function that uses 32 bit longs in its interface.
>
> But could we not have a 'compatibility define' in MPIR that makes the
> function work for 64-bit longs when needed?
>
>
I guess that's an option. It won't fix the GMP issue for us either way.

The problem of course is that an mpz (and hence an fmpz) can be 2^31 words,
not bits. Therefore the number of bits in such an exponent can be larger
than 2^32.

Any solution requires non-trivial work, anyway. And unfortunately I have no
time for such things these days. I can only merge patches into MPIR. That's
all I have time for. The community is suppose to be taking over the job of
handling releases, etc. But so far there haven't been any volunteers.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

Hi Brian,

I believe the problem is that our LLL code actually relies on a 64 bit
exponent on Windows 64 (in practice, not just in theory), but GMP (or the
compatibility function) only returns a 32 bit one.

Bill.

On 23 January 2018 at 15:14, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 12:28, 'Bill Hart' via mpir-devel wrote:
>
> > Yes, but Flint itself relies on the old version, and no one has time to
> > fix it.
>
> Hi Bill,
>
> I must be missing something here since this makes no sense to me.
>
> The function mpf_get_d_2exp() is mentioned only once in FLINT2 and there
> is no difference in the calls to MPIR and GMP. So this function doesn't
> seem to be a problem.
>
> There are three calls to mpz_get_d_2exp in FLINT2:
>
> In dlog.c:
> --
> #if defined(__MPIR_VERSION)
> slong e;
> #else
> long e;
> #endif
>
> s = mpz_get_d_2exp(, COEFF_TO_PTR(*x));
> --
>
> In get_d_2exp.c:
> --
> #if defined(__MPIR_VERSION)
>return mpz_get_d_2exp(exp, COEFF_TO_PTR(d));
> #else
>long exp2;
>double m = mpz_get_d_2exp(, COEFF_TO_PTR(d));
>*exp = exp2;
>return m;
> #endif
> --
>
> In both cases changing:
>
> #if defined(__MPIR_VERSION)
>
> to
>
> #if __MPIR_VERSION < 3
>
> fixes the issue.
>
> Are you really saying that no one has the time to do this?
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

Yes, but Flint itself relies on the old version, and no one has time to fix
it.

On 23 January 2018 at 13:23, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 11:58, 'Bill Hart' via mpir-devel wrote:
> > Hi Brian,
> >
> > The history of the Flint issue is in this ticket here:
> >
> > https://github.com/wbhart/flint2/issues/338
> >
> > I'm not sure if MPIR Windows users will actually *want* this fixed. But
> > unfortunately, Flint relies on the old semantics, and can't be easily
> > fixed, I think.
>
> Hi Bill,
>
> Since, in respect of the two functions involved, the current versions of
> MPIR and GMP now use the same semantics, the GMP compatibility layer
> must have a fix for this.
>
> Can this fix not be applied to the MPIR interface?
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

Hi Brian,

The history of the Flint issue is in this ticket here:

https://github.com/wbhart/flint2/issues/338

I'm not sure if MPIR Windows users will actually *want* this fixed. But
unfortunately, Flint relies on the old semantics, and can't be easily
fixed, I think.

Bill.

On 23 January 2018 at 12:42, Brian Gladman <b...@gladman.plus.com> wrote:

> On 23/01/2018 09:59, 'Bill Hart' via mpir-devel wrote:
> > Hi all,
> >
> > This is just a brief note to let the community know that as of
> > MPFR-4.0.0, Flint no longer supports the latest versions of MPIR or MPFR
> > on Windows.
> >
> > MPFR-4.0.0 is no longer compatible with MPIR-2.7.2 and Flint is no
> > longer compatible with MPIR-3.0.0. I doubt that anyone wants to fix any
> > of these issues.
>
> Since the MPIR (repository) and MPFR (version 4) are fully compatible on
> Windows, can you say more about the problems in Flint that mean these
> versions can no longer be used?
>
>Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Flint, MPIR and Windows compatibility

['Bill Hart' via mpir-devel]

Hi all,

This is just a brief note to let the community know that as of MPFR-4.0.0,
Flint no longer supports the latest versions of MPIR or MPFR on Windows.

MPFR-4.0.0 is no longer compatible with MPIR-2.7.2 and Flint is no longer
compatible with MPIR-3.0.0. I doubt that anyone wants to fix any of these
issues.

For a while, we can use MPIR-2.7.2 and MPFR-3.1.6 on Windows, but
eventually Flint won't support these either, since we'll eventually depend
on functionality not in these packages. So this is just a temporary band
aid.

We can switch to using GMP instead of MPIR on Windows, however, Flint uses
a compatibility layer to support GMP on Windows, and this adds performance
issues which can't really be removed.

I don't know what the implications are for Arb. Perhaps Fredrik can be more
specific about that.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] t-mullowhigh.exe test failed

['Bill Hart' via mpir-devel]

The likelihood is that it is being miscompiled. But can you give some
information about your machine, such as gcc version and the result of
config.guess.

It's unlikely we can track this down, since we don't see a similar failure
on our machines.

On 1 December 2017 at 02:40, James Nall  wrote:

> Good evening.
>
> I was installing MPIR in accordance with the documentation instructions
> and when I ran the check all tests passed with the exception of
> t-mullowhigh.exe.  I am perforing the installation on a Windows 10 64-bit
> system using the 64-bit Cygwin to run my utilities.
>
> The log file only produced the following line:
> mpn_mullow_n error 2
>
> Thank you for your help and time.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] gmp source/include compatibility?

['Bill Hart' via mpir-devel]

Yes, it can be copied for full compatibility. Note that we take a different
convention on x64 that _ui and _si functions use 64 bit words instead of 32
bits. But for most functions this doesn't affect compatibility.

On 20 September 2017 at 12:30, Francis Andre 
wrote:

> Hello
>
> I am porting on Windows a Linux application that is a consuler of the GNU
> gmp library. Googling for GMP on Windows, I did not find any realistic GMP
> packaging on Windows except the mpir library, which in my understandin is a
> fork fo the GNU gmp library. So I choose to use the mpir librairy to
> replace the GNU gmp one. But the include interface is different. The ported
> application is referring the include gmpxx.h which is in fact the mpir.h.
>
> Thus can this 'mpir.h' include be renamed 'gmpxx.h' or copied to 'gmpxx.h'
> so that a full compatibility be insured. By the way, the head of mpir.h is
> as below
>
> /* gmpxx.h -- C++ class wrapper for GMP types.  -*- C++ -*-
>
> Copyright 2001, 2002, 2003, 2006, 2008, 2011, 2012 Free Software
> Foundation,
> Inc.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: [sage-devel] Unable to compile 8.0.rc2 on mac

['Bill Hart' via mpir-devel]

Reimer Behrends has helped me track down the explicit issue. We don't have 
a patch yet, but the bug (and solution) is described here [1].

Basically the M4 macro JMPENT in mpn/x86_64/x86_64-defs.mac needs to do 
more than just subtract the two addresses on Mac. However, I'm confused why 
this isn't affecting every 64 bit Skylake Mac out there. But his has only 
been reported twice! Are Skylake Macs really rare or something?

Bill.

[1] https://gmplib.org/list-archives/gmp-bugs/2012-December/002836.html

On Wednesday, 19 July 2017 11:15:09 UTC+2, Bill Hart wrote:
>
> It's certainly not a generic problem affecting Mac [0]. It's Skylake 
> specific and something their linker doesn't like that works on that 
> architecture on Linux.
>
> Bill.
>
> [0] 
> https://travis-ci.org/wbhart/mpir/builds/252901954?utm_source=github_status_medium=notification
>
> On Wednesday, 19 July 2017 11:12:37 UTC+2, Bill Hart wrote:
>>
>> Alex Best pointed out this morning that something similar came up for the 
>> GMP guys a while back. Apparently something to do with jump tables. That is 
>> probably affecting our code here [1].
>>
>> We'll look into it. Unfortunately, in the mean time, the best one can 
>> really do is delete the affected file.
>>
>> Bill.
>>
>> [1] 
>> https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm#L100
>>
>> On Wednesday, 19 July 2017 01:46:48 UTC+2, Andrew wrote:
>>>
>>>
>>>
>>> On Wednesday, 19 July 2017 00:59:27 UTC+10, Dima Pasechnik wrote:
>>>>
>>>> Surely MPIR guys would appreciate feedback.
>>>> This might be their assembler bug.
>>>>
>>>> Will let them know.
>>> A. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Weird performance behaviour

['Bill Hart' via mpir-devel]

Thanks. We'll take a look into it and see if we can fix it.

Bill.

On 14 August 2017 at 16:51, <csm...@bristol.ac.uk> wrote:

> Hi,
>
> I've dug a bit deeper, and it seems that there is an alignment issue
> within addmul_1. I've created two marginally different programs, of which
> one is much faster:
>
> $ gcc -O3 addmul_1.s -o addmul_1.o -c; for i in a b; do gcc -O3 $i.cpp -o
> $i.out addmul_1.o; ./$i.out ; done
> Time: 0.490647
> Time: 0.681671
>
> addmul_1.s is the Sandy Bridge-optimized assembly. When I change the
> alignment there a bit as in addmul_1.opt.s, the difference disappears:
>
> $ gcc -O3 addmul_1.opt.s -o addmul_1.o -c; for i in a b; do gcc -O3 $i.cpp
> -o $i.out addmul_1.o; ./$i.out ; objdump -CSD $i.out > $i.dis ;done
> Time: 0.505714
> Time: 0.495640
>
> Best regards,
> Marcel
>
>
> On Friday, August 11, 2017 at 7:00:10 PM UTC+1, Bill Hart wrote:
>>
>> We've noticed similar sorts of things. One possibility is that the loop
>> in your test code is not aligned as well in one version. Or perhaps your
>> stack is hitting the same location modulo 4096, which is a known issue on
>> some modern processors. There might be SSE code in the linker and AVX code
>> in the addmul_1 function. The kernel might pin the process to a different
>> CPU which is slightly slower or faster, when the pthreads library is used.
>> You might also hit some frequency scaling in the CPU due to the pthreads
>> library taking longer to link in. There's so many possibilities on a modern
>> CPU, it hardly bears thinking about.
>>
>> Also, in your code, you don't seem to set y anywhere and I wasn't aware
>> you could use 1e8 as an int constant.
>>
>> Bill.
>>
>> On 11 August 2017 at 18:10, Marcel Keller <m.ke...@bristol.ac.uk> wrote:
>>
>>> Hi,
>>>
>>> I've noticed that the performance of mpn_addmul_1 can depend
>>> considerably on whether I link against libpthread, which strikes me as very
>>> weird:
>>>
>>> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o
>>> -o a.out
>>>
>>> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o
>>> -o b.out  -lpthread
>>>
>>> $ ./a.out
>>> mpn_addmul_1: 0.506279
>>>
>>> $ ./b.out
>>> mpn_addmul_1: 0.682086
>>>
>>> Disassembling the binaries shows that the mpn function in
>>> Time-addmul_1.cpp is compiled exactly the same way.
>>>
>>> I'm running CentOS 7 and GCC 6.2. The source as well as the outputs are
>>> attached.
>>>
>>> Does anyone have any idea why this could be?
>>>
>>> Best regards,
>>> Marcel
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mpir-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mpir-devel+...@googlegroups.com.
>>> To post to this group, send email to mpir-...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/mpir-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Weird performance behaviour

['Bill Hart' via mpir-devel]

Of course if you are using an AMD processor, surely it is a "performance
marginality problem". :-)

Bill.

On 11 August 2017 at 20:00, Bill Hart <goodwillh...@googlemail.com> wrote:

> We've noticed similar sorts of things. One possibility is that the loop in
> your test code is not aligned as well in one version. Or perhaps your stack
> is hitting the same location modulo 4096, which is a known issue on some
> modern processors. There might be SSE code in the linker and AVX code in
> the addmul_1 function. The kernel might pin the process to a different CPU
> which is slightly slower or faster, when the pthreads library is used. You
> might also hit some frequency scaling in the CPU due to the pthreads
> library taking longer to link in. There's so many possibilities on a modern
> CPU, it hardly bears thinking about.
>
> Also, in your code, you don't seem to set y anywhere and I wasn't aware
> you could use 1e8 as an int constant.
>
> Bill.
>
> On 11 August 2017 at 18:10, Marcel Keller <m.kel...@bristol.ac.uk> wrote:
>
>> Hi,
>>
>> I've noticed that the performance of mpn_addmul_1 can depend considerably
>> on whether I link against libpthread, which strikes me as very weird:
>>
>> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o -o
>> a.out
>>
>> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o -o
>> b.out  -lpthread
>>
>> $ ./a.out
>> mpn_addmul_1: 0.506279
>>
>> $ ./b.out
>> mpn_addmul_1: 0.682086
>>
>> Disassembling the binaries shows that the mpn function in
>> Time-addmul_1.cpp is compiled exactly the same way.
>>
>> I'm running CentOS 7 and GCC 6.2. The source as well as the outputs are
>> attached.
>>
>> Does anyone have any idea why this could be?
>>
>> Best regards,
>> Marcel
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to mpir-devel@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mpir-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Weird performance behaviour

['Bill Hart' via mpir-devel]

We've noticed similar sorts of things. One possibility is that the loop in
your test code is not aligned as well in one version. Or perhaps your stack
is hitting the same location modulo 4096, which is a known issue on some
modern processors. There might be SSE code in the linker and AVX code in
the addmul_1 function. The kernel might pin the process to a different CPU
which is slightly slower or faster, when the pthreads library is used. You
might also hit some frequency scaling in the CPU due to the pthreads
library taking longer to link in. There's so many possibilities on a modern
CPU, it hardly bears thinking about.

Also, in your code, you don't seem to set y anywhere and I wasn't aware you
could use 1e8 as an int constant.

Bill.

On 11 August 2017 at 18:10, Marcel Keller  wrote:

> Hi,
>
> I've noticed that the performance of mpn_addmul_1 can depend considerably
> on whether I link against libpthread, which strikes me as very weird:
>
> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o -o
> a.out
>
> $ g++ -O3 Time-addmul_1.cpp ~/src/mpir-3.0.0-ivybridge/mpn/addmul_1.o -o
> b.out  -lpthread
>
> $ ./a.out
> mpn_addmul_1: 0.506279
>
> $ ./b.out
> mpn_addmul_1: 0.682086
>
> Disassembling the binaries shows that the mpn function in
> Time-addmul_1.cpp is compiled exactly the same way.
>
> I'm running CentOS 7 and GCC 6.2. The source as well as the outputs are
> attached.
>
> Does anyone have any idea why this could be?
>
> Best regards,
> Marcel
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Configure missing from Master branch

['Bill Hart' via mpir-devel]

Hi Michael,

yes, we removed the configure script from the git repo. It is autogenerated
using autotools. Users should make use of the tarballs on the website, not
the developers' repository.

Bill.

On 30 July 2017 at 02:42, Michael Frey  wrote:

> The configure script file is missing from the master branch.
>
> I am trying to get mpir 3.0.0 to build on my MacBook Pro to use with sage
> 8.0.  I download the git repository with git clone
> https://github.com/wbhart/mpir.git and found the configure file was
> missing.
>
> Hopefully this is an easy fix.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Can any Mac experts shed light on this?

['Bill Hart' via mpir-devel]

Someone has reported issues with building on a Mac [1]. It seems that the
gas assembler is not able to compile the new BMI instructions on a Haswell
(which supports them).

What can we do the help this user?

Bill.

[1] https://github.com/wbhart/mpir/issues/217

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Problems using mpir-tune

['Bill Hart' via mpir-devel]

It's extremely hard to make the timing code work on Windows. It would
probably at least involve putting the OS into safe mode. It's certainly not
intended for users.

On 16 April 2017 at 17:08, Alexander _  wrote:

> You not the first who raise this issue. The short answer: don't waste your
> time on this. AIUI, content of 'MPIR/tune/' folder is intended for MPIR
> Developers, not Users.
>
> Longer by Torbjörn Granlund:
>
> We never ported timing things to WinDoS.
>
> One should not need to run any of the things in tune/ on non-Unix
> platforms.  The important thing is to run it on each CPU type.
>
>
> (the full thread https://gmplib.org/list-archives/gmp-bugs/2015-
> December/003879.html )
>
> Since GMP Developers don't care about running "GMP timing things" on
> Windows, it's hard to expect that "MPIR timing things" be very different
> (since they share the same limitations). Even in spite of all attempts of
> MPIR Developers to shave-off rough edges.
>
>
> Alexander
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Fabrice Bellard's bignum library

['Bill Hart' via mpir-devel]

Fredrik Johansson pointed out to me that Fabrice Bellard has released a
tiny bignum library with an SIMD optimised Number Theoretic Transform that
is faster than GMP 6 [1].

It would make a very interesting project for someone to port his code
(which is MIT licensed) to MPIR.

Since the codebase is very small, this shouldn't be too difficult. Though
setting up the appropriate assembly functions in MPIR is a bit of work.

Bill.

[1] http://bellard.org/libbf/

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Mpir 3.0.0 seems to be about 8% slower than 2.7.2 for small floats (1-4 limbs)

['Bill Hart' via mpir-devel]

If I'm reading your timings correctly, you are also showing that the
Skylake and Haswell code isn't the fastest for your Broadwell architecture,
which is certainly not what I expect to see.

Timing on Windows is always difficult though. We don't superoptimise on
Windows since it is essentially impossible, and once the additional code is
added to take care of the different ABI on Windows, any superoptimisation
done on Linux can be thrown right out on Windows. This will particularly
affect very small operations.

Bill.

On 5 March 2017 at 02:56, Bill Hart <goodwillh...@googlemail.com> wrote:

> I can't think of anything specific that we changed that should affect the
> speed in this way. We literally didn't touch the assembly code for any of
> those architectures and the C code has only changed for powering mod n.
>
> You are probably noticing a slowdown due to the library being rearranged
> slightly at the level of linking, or something like that.
>
> Of course there is no Broadwell specific code, and perhaps when there is,
> you will again notice a speedup.
>
> Bill.
>
> On 4 March 2017 at 21:57, <kesse...@schema.de> wrote:
>
>> Hi,
>>
>> first of all, thanks for all the great MPIR work! I've been using it for
>> about 4 years to compute visually compelling deep Mandelbrot zoom videos.
>>
>> Yesterday I've downloaded 3.0.0 and compiled it using VS 2015 U3 on an
>> Intel Core i7 6900K (8 cores, Broadwell) on Windows 10 64.
>>
>> Unfortunately, 3.0.0 seems to be slower than 2.7.2 by about 8% when small
>> floats are used. By small floats I mean a precision of up to 256 bits (4
>> limbs on x64).
>>
>> Compilation worked flawlessly for all of the 10 architectures I've
>> selected. Just to make sure Visual Studio updates are not the source of the
>> problem, I also recompiled the 7 architectures I've been testing with 2.7.2.
>>
>> The stats below are based on several hundred million Mandelbrot
>> iterations for each data point. All 16 threads of the 6900K are used and
>> all of them are at 100% capacity.
>>
>> I get the following speedup matrix for 128 precision floats over all
>> compiled versions and architectures:
>>
>> Results from file: Run_2017-03-04T20_10_18.xml; number model: GMP128
>>1 mpir_3_0_0_x64_gc  MFlops:252.6
>>2 mpir_2_7_2_x64_gc  MFlops:274.7
>> Speedup: 8.73%
>>3 mpir_3_0_0_x64_haswell_avx MFlops:357.9
>> Speedup:41.67%30.30%
>>4 mpir_3_0_0_x64_skylake_avx MFlops:365.9
>> Speedup:44.82%33.20% 2.22%
>>5 mpir_3_0_0_x64_haswell MFlops:368.1
>> Speedup:45.72%34.02% 2.86% 0.62%
>>6 mpir_3_0_0_x64_skylake MFlops:371.0
>> Speedup:46.84%35.05% 3.65% 1.39% 0.77%
>>7 mpir_3_0_0_x64_core2   MFlops:377.0
>> Speedup:49.23%37.26% 5.34% 3.05% 2.41% 1.63%
>>8 mpir_3_0_0_x64_sandybridge_ivybridge   MFlops:386.7
>> Speedup:53.07%40.79% 8.05% 5.70% 5.05% 4.25%
>>  2.57%
>>9 mpir_3_0_0_x64_nehalem_westmereMFlops:389.3
>> Speedup:54.10%41.74% 8.78% 6.41% 5.76% 4.95%
>>  3.26% 0.67%
>>   10 mpir_3_0_0_x64_nehalem MFlops:389.5
>> Speedup:54.19%41.82% 8.84% 6.47% 5.82% 5.01%
>>  3.32% 0.73% 0.06%
>>   11 mpir_3_0_0_x64_sandybridge MFlops:395.1
>> Speedup:56.39%43.84%10.39% 7.99% 7.33% 6.51%
>>  4.80% 2.17% 1.48% 1.43%
>>   12 mpir_2_7_2_x64_haswell MFlops:398.3
>> Speedup:57.66%45.01%11.28% 8.87% 8.20% 7.37%
>>  5.65% 3.00% 2.31% 2.25% 0.81%
>>   13 mpir_2_7_2_x64_sandybridge_ivybridge   MFlops:404.3
>> Speedup:60.04%47.20%12.97%10.51% 9.83% 8.99%
>>  7.24% 4.55% 3.85% 3.79% 2.33% 1.51%
>>   14 mpir_2_7_2_x64_sandybridge MFlops:405.2
>> Speedup:60.40%47.52%13.22%10.76%10.07% 9.23%
>>  7.48% 4.78% 4.08% 4.02% 2.56% 1.74% 0.22%
>>   15 mpir_2_7_2_x64_nehalem_westmereMFlops:417.3
>> Speedup:65.16%51.91%16.58%14.05%13.35%12.48%
>> 10.67% 7.90% 7.18% 7.12% 5.61% 4.76% 3.20% 2.97%
>>   16 mpir_2_7_2_x64_core2   MFlops:419.0
>> Speedup:65.85%52.54%   

Re: [mpir-devel] Mpir 3.0.0 seems to be about 8% slower than 2.7.2 for small floats (1-4 limbs)

['Bill Hart' via mpir-devel]

I can't think of anything specific that we changed that should affect the
speed in this way. We literally didn't touch the assembly code for any of
those architectures and the C code has only changed for powering mod n.

You are probably noticing a slowdown due to the library being rearranged
slightly at the level of linking, or something like that.

Of course there is no Broadwell specific code, and perhaps when there is,
you will again notice a speedup.

Bill.

On 4 March 2017 at 21:57,  wrote:

> Hi,
>
> first of all, thanks for all the great MPIR work! I've been using it for
> about 4 years to compute visually compelling deep Mandelbrot zoom videos.
>
> Yesterday I've downloaded 3.0.0 and compiled it using VS 2015 U3 on an
> Intel Core i7 6900K (8 cores, Broadwell) on Windows 10 64.
>
> Unfortunately, 3.0.0 seems to be slower than 2.7.2 by about 8% when small
> floats are used. By small floats I mean a precision of up to 256 bits (4
> limbs on x64).
>
> Compilation worked flawlessly for all of the 10 architectures I've
> selected. Just to make sure Visual Studio updates are not the source of the
> problem, I also recompiled the 7 architectures I've been testing with 2.7.2.
>
> The stats below are based on several hundred million Mandelbrot iterations
> for each data point. All 16 threads of the 6900K are used and all of them
> are at 100% capacity.
>
> I get the following speedup matrix for 128 precision floats over all
> compiled versions and architectures:
>
> Results from file: Run_2017-03-04T20_10_18.xml; number model: GMP128
>1 mpir_3_0_0_x64_gc  MFlops:252.6
>2 mpir_2_7_2_x64_gc  MFlops:274.7 Speedup:
>8.73%
>3 mpir_3_0_0_x64_haswell_avx MFlops:357.9 Speedup:
>   41.67%30.30%
>4 mpir_3_0_0_x64_skylake_avx MFlops:365.9 Speedup:
>   44.82%33.20% 2.22%
>5 mpir_3_0_0_x64_haswell MFlops:368.1 Speedup:
>   45.72%34.02% 2.86% 0.62%
>6 mpir_3_0_0_x64_skylake MFlops:371.0 Speedup:
>   46.84%35.05% 3.65% 1.39% 0.77%
>7 mpir_3_0_0_x64_core2   MFlops:377.0 Speedup:
>   49.23%37.26% 5.34% 3.05% 2.41% 1.63%
>8 mpir_3_0_0_x64_sandybridge_ivybridge   MFlops:386.7
> Speedup:53.07%40.79% 8.05% 5.70% 5.05% 4.25%
>  2.57%
>9 mpir_3_0_0_x64_nehalem_westmereMFlops:389.3
> Speedup:54.10%41.74% 8.78% 6.41% 5.76% 4.95%
>  3.26% 0.67%
>   10 mpir_3_0_0_x64_nehalem MFlops:389.5 Speedup:
>   54.19%41.82% 8.84% 6.47% 5.82% 5.01% 3.32%
>  0.73% 0.06%
>   11 mpir_3_0_0_x64_sandybridge MFlops:395.1 Speedup:
>   56.39%43.84%10.39% 7.99% 7.33% 6.51% 4.80%
>  2.17% 1.48% 1.43%
>   12 mpir_2_7_2_x64_haswell MFlops:398.3 Speedup:
>   57.66%45.01%11.28% 8.87% 8.20% 7.37% 5.65%
>  3.00% 2.31% 2.25% 0.81%
>   13 mpir_2_7_2_x64_sandybridge_ivybridge   MFlops:404.3
> Speedup:60.04%47.20%12.97%10.51% 9.83% 8.99%
>  7.24% 4.55% 3.85% 3.79% 2.33% 1.51%
>   14 mpir_2_7_2_x64_sandybridge MFlops:405.2 Speedup:
>   60.40%47.52%13.22%10.76%10.07% 9.23% 7.48%
>  4.78% 4.08% 4.02% 2.56% 1.74% 0.22%
>   15 mpir_2_7_2_x64_nehalem_westmereMFlops:417.3
> Speedup:65.16%51.91%16.58%14.05%13.35%12.48%
> 10.67% 7.90% 7.18% 7.12% 5.61% 4.76% 3.20% 2.97%
>   16 mpir_2_7_2_x64_core2   MFlops:419.0 Speedup:
>   65.85%52.54%17.07%14.53%13.82%12.95%11.14%
>  8.35% 7.62% 7.56% 6.05% 5.20% 3.63% 3.40% 0.42%
>   17 mpir_2_7_2_x64_nehalem MFlops:422.8 Speedup:
>   67.37%53.94%18.14%15.58%14.86%13.99%12.16%
>  9.34% 8.61% 8.55% 7.02% 6.16% 4.58% 4.35%
>  1.34% 0.92%
>
>1 2 3 4 5 6 7
>  8 9101112131415
> 16
>
> I've taken these measurements three times with the same results.
>
> The six fastest versions are all 2.7.2.
>
> Note that architectural compilation and the Broadwell CPU do not seem to
> be the issue, since the slowest two versions, the generic C
> mpir_3_0_0_x64_gc and mpir_2_7_2_x64_gc also differ by about 8%. Both
> compiled on the same machine within 5 minutes of each other with VS 2015.
>
> Another hint that architectural compilation and optimization is working
> fine, is that once I test with 1024 bits precision, the fastest version is
> mpir_3_0_0_x64_skylake_avx (the Broadwell CPU used in 

[mpir-devel] MPIR-3.0.0 released

['Bill Hart' via mpir-devel]

Hi all,

We have just released MPIR-3.0.0.

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation [1]
* No Intel Kaby Lake support [2]
* No AMD Steamroller support [3]
* No AMD Excavator support [4]
* No ARM64 support [5]
* No ARM-UWP support [6]
* New GMP 6.1 functionality not fully supported [7, 8]
* Tuning values for many architectures missing [9]
* Fat binary not available on OSX [10]

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports, including:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander), jengelh

Thanks to William Stein for providing access to a Bulldozer machine.

Bill.
[1] https://github.com/wbhart/mpir/issues/198
[2] https://github.com/wbhart/mpir/issues/199
[3] https://github.com/wbhart/mpir/issues/200
[4] https://github.com/wbhart/mpir/issues/201
[5] https://github.com/wbhart/mpir/issues/108
[6] https://github.com/wbhart/mpir/issues/177
[7] https://github.com/wbhart/mpir/issues/191
[8] https://github.com/wbhart/mpir/issues/190
[9] https://github.com/wbhart/mpir/issues/194
[10] https://github.com/wbhart/mpir/issues/212

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Re: MPIR-3.0.0-rc1 released

['Bill Hart' via mpir-devel]

I just issued RC2 since a directory was missing from the Windows release.
This won't affect Linux users.

On 21 February 2017 at 15:22, Bill Hart <goodwillh...@googlemail.com> wrote:

> Hi all,
>
> We have just released MPIR-3.0.0-rc1. If no issues are reported with this
> release candidate by 28th Feb, we will make it the final MPIR-3.0.0 release.
>
> The only changes since the last alpha were additional Broadwell CPUs
> supported, which should only affect you if your Broadwell chip was
> misidentified.
>
> Download MPIR-3.0.0-rc1 from:
>
> http://mpir.org/
>
> Note that you now need to have the latest yasm to build MPIR.
>
> http://yasm.tortall.net/
>
> To build yasm, download the tarball:
>
> ./configure
> make
>
> To test MPIR, download the tarball:
>
> ./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
> make
> make check
>
> Major changes in MPIR-3.0.0 are:
>
> * Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
> MPIR's configure, or install yasm systemwide if you prefer)
> * New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
> GMP
> * New Intel Haswell assembly support due to Alex Kruppa and GMP
> * Rudimentary Broadwell support (no optimisation)
> * Improved AMD Bulldozer support due to Alex Kruppa
> * Faster mpz_powm, mpz_powm_ui from GMP
> * New mpz_limbs functionality from GMP 6
> * New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
> functions from GMP
> * New mpn_nsumdiff_n function (speeds up FFT on haswell)
> * Visual Studio 2017 support due to Brian Gladman
> * mpir.net for interface to .net languages due to Alex Dyachenko
> * Appveyor-CI support
> * GMP 6 compatibility
> * Numerous bug fixes
>
> Known issues with the 3.0.0 release:
>
> * No Intel Broadwell optimisation (it is now being worked on for
> MPIR-3.1.0)
> * No Intel Kaby Lake support
> * No AMD Steamroller support
> * No AMD Excavator support
> * No ARM64 support
> * No ARM-UWP support
> * New GMP 6.1 functionality not fully supported
> * Tuning values for many architectures missing
>
> As all MPIR funding has now run out, MPIR is again maintained by community
> volunteers. Patches in the form of complete GitHub Pull Requests are very
> welcome.
>
> This release of MPIR was supported in part by the OpenDreamKit EU
> Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
> assembly superoptimiser which has been used to superoptimise for some of
> the above architectures.
>
> The main contributors to this release were:
>
>Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
>Flori, Isuru Fernando, William Hart
>
> As usual we would also like to acknowledge the GMP developers for their
> indirect contribution through the official GNU project, and numerous others
> who submitted tuning values, bug fixes or bug reports. Other contributors
> to this release include:
>
>Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
> (Alexander)
>
> Thanks to William Stein for providing access to a Bulldozer machine.
>
> Bill.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] MPIR-3.0.0-rc1 released

['Bill Hart' via mpir-devel]

Hi all,

We have just released MPIR-3.0.0-rc1. If no issues are reported with this
release candidate by 28th Feb, we will make it the final MPIR-3.0.0 release.

The only changes since the last alpha were additional Broadwell CPUs
supported, which should only affect you if your Broadwell chip was
misidentified.

Download MPIR-3.0.0-rc1 from:

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation (it is now being worked on for MPIR-3.1.0)
* No Intel Kaby Lake support
* No AMD Steamroller support
* No AMD Excavator support
* No ARM64 support
* No ARM-UWP support
* New GMP 6.1 functionality not fully supported
* Tuning values for many architectures missing

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports. Other contributors
to this release include:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander)

Thanks to William Stein for providing access to a Bulldozer machine.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[mpir-devel] Intention to release MPIR release candidate today

['Bill Hart' via mpir-devel]

We intend to issue the first MPIR-3.0.0 release candidate today, as there
don't seem to be any major issues being reported with our alpha releases
(at least, not ones we can fix).

After this point there will be an mpir-3.0.0 branch which will only accept
bug fixes for the MPIR 3.0.0 release candidates.

The aim is to release a final version of MPIR-3.0.0 by the end of the
month, i.e. about a week from today.

Thanks very much to everyone who has done testing, submitted bug fixes and
patches.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [mpir-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via mpir-devel]

I added model 71 to cpuid.c as a Broadwell. The other models I have left
out for now, as I don't find sufficient evidence for those identifications
just yet. Perhaps Intel has reserved them for future chips. When people
start reporting to us that they have chips in these families, we'll take a
look at what they are and add them as appropriate.

On 21 February 2017 at 11:11, Bill Hart <goodwillh...@googlemail.com> wrote:

> I've opened [1] for the haswell bmi2 issue. I doubt it will be dealt with
> in this release. As far as I can tell, such machines are vanishingly rare.
>
> Bill.
>
> [1] https://github.com/wbhart/mpir/issues/209
>
> On 21 February 2017 at 11:03, Bill Hart <goodwillh...@googlemail.com>
> wrote:
>
>> Whoops, looks like I was wrong about us correctly handling Haswell
>> without BMI2. We handle Skylake correctly, but Haswell we don't check for
>> BMI2.
>>
>> It looks like the Haswell directory has been divided into haswell and
>> haswell/avx, which is probably intended for this distinction, but I think
>> we decided to wait and see if anyone actually had one of these machines
>> before we panicked too much.
>>
>> I'll have a think about this.
>>
>> On 21 February 2017 at 10:53, Bill Hart <goodwillh...@googlemail.com>
>> wrote:
>>
>>> I have just been contacted off list by a very experienced assembly
>>> expert who would like to help develop Broadwell assembly optimisations,
>>> guided by your experiments (as far as I know, he doesn't actually have a
>>> Broadwell machine).
>>>
>>> If you are ok with it, I could share your email with him so that he can
>>> communicate with you off list. Would you be up for working with him on this?
>>>
>>> Bill.
>>>
>>> On 21 February 2017 at 09:05, Bill Hart <goodwillh...@googlemail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 21 February 2017 at 00:35, <wrai...@morpheus.net> wrote:
>>>>
>>>>> Hello Bill,
>>>>>
>>>>> I can report that both of my systems are now correctly detected.
>>>>> Thank you for the fix!
>>>>>
>>>>> I also noticed that there were a couple of other missing processor
>>>>> models when compared with GMP mpn/x86_64/fat/fat.c: (the * star values are
>>>>> missing in MPIR)
>>>>> Broadwell:
>>>>> 0x3d=61
>>>>> 0x47=71 *
>>>>> 0x4f=79
>>>>> 0x56=86 *
>>>>> Skylake:
>>>>> 0x4e=78
>>>>> 0x55=85 *
>>>>> 0x5e=94
>>>>> Kabylake:
>>>>> 0x8e=142 *
>>>>> 0x9e=158 *
>>>>> There was a word of warning in the GMP source about some Haswell's not
>>>>> supporting BMI2, and so they treated those as Sandybridges.  I'm not sure
>>>>> how you want to handle this, but I wanted to make sure I passed the 
>>>>> warning
>>>>> on to you.
>>>>>
>>>>
>>>> Thanks, I will look into the models we are missing. We have no support
>>>> for Kaby Lake at this point. We are aware of the crippled Haswells and
>>>> handle those I believe.
>>>>
>>>>
>>>>>
>>>>> I ran the speed program, but I do not see how to "choose different
>>>>> assembly files".  Do I have to build different speed programs with
>>>>> different assembly files linked in?
>>>>
>>>>
>>>> It only uses the assembly files currently linked into MPIR. You have to
>>>> put different files in and rebuild.
>>>>
>>>>
>>>>>   Is this an option passed to "make speed"?  Do various gmp-mparam.h
>>>>> files need to be copied to a specific location before "make speed" to
>>>>> create a different speed binary?
>>>>
>>>>
>>>> gmp-mparam.h has no effect on speed.
>>>>
>>>>
>>>>> Once I'm past this step, I believe I can figure out the rest by
>>>>> writing a script to automate the data gathering.
>>>>>
>>>>> What sizes are of interest when running these tests? 1-100, 1-1000,
>>>>> 1-1, etc?
>>>>
>>>>
>>>> Typically 1-100 or 1-1000 is of interest.
>>>>
>>>>
>>>>> Can a given test be faster with one assembly file at one size, but be
>>>>> faster wit

Re: [mpir-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via mpir-devel]

I've opened [1] for the haswell bmi2 issue. I doubt it will be dealt with
in this release. As far as I can tell, such machines are vanishingly rare.

Bill.

[1] https://github.com/wbhart/mpir/issues/209

On 21 February 2017 at 11:03, Bill Hart <goodwillh...@googlemail.com> wrote:

> Whoops, looks like I was wrong about us correctly handling Haswell without
> BMI2. We handle Skylake correctly, but Haswell we don't check for BMI2.
>
> It looks like the Haswell directory has been divided into haswell and
> haswell/avx, which is probably intended for this distinction, but I think
> we decided to wait and see if anyone actually had one of these machines
> before we panicked too much.
>
> I'll have a think about this.
>
> On 21 February 2017 at 10:53, Bill Hart <goodwillh...@googlemail.com>
> wrote:
>
>> I have just been contacted off list by a very experienced assembly expert
>> who would like to help develop Broadwell assembly optimisations, guided by
>> your experiments (as far as I know, he doesn't actually have a Broadwell
>> machine).
>>
>> If you are ok with it, I could share your email with him so that he can
>> communicate with you off list. Would you be up for working with him on this?
>>
>> Bill.
>>
>> On 21 February 2017 at 09:05, Bill Hart <goodwillh...@googlemail.com>
>> wrote:
>>
>>>
>>>
>>> On 21 February 2017 at 00:35, <wrai...@morpheus.net> wrote:
>>>
>>>> Hello Bill,
>>>>
>>>> I can report that both of my systems are now correctly detected.  Thank
>>>> you for the fix!
>>>>
>>>> I also noticed that there were a couple of other missing processor
>>>> models when compared with GMP mpn/x86_64/fat/fat.c: (the * star values are
>>>> missing in MPIR)
>>>> Broadwell:
>>>> 0x3d=61
>>>> 0x47=71 *
>>>> 0x4f=79
>>>> 0x56=86 *
>>>> Skylake:
>>>> 0x4e=78
>>>> 0x55=85 *
>>>> 0x5e=94
>>>> Kabylake:
>>>> 0x8e=142 *
>>>> 0x9e=158 *
>>>> There was a word of warning in the GMP source about some Haswell's not
>>>> supporting BMI2, and so they treated those as Sandybridges.  I'm not sure
>>>> how you want to handle this, but I wanted to make sure I passed the warning
>>>> on to you.
>>>>
>>>
>>> Thanks, I will look into the models we are missing. We have no support
>>> for Kaby Lake at this point. We are aware of the crippled Haswells and
>>> handle those I believe.
>>>
>>>
>>>>
>>>> I ran the speed program, but I do not see how to "choose different
>>>> assembly files".  Do I have to build different speed programs with
>>>> different assembly files linked in?
>>>
>>>
>>> It only uses the assembly files currently linked into MPIR. You have to
>>> put different files in and rebuild.
>>>
>>>
>>>>   Is this an option passed to "make speed"?  Do various gmp-mparam.h
>>>> files need to be copied to a specific location before "make speed" to
>>>> create a different speed binary?
>>>
>>>
>>> gmp-mparam.h has no effect on speed.
>>>
>>>
>>>> Once I'm past this step, I believe I can figure out the rest by writing
>>>> a script to automate the data gathering.
>>>>
>>>> What sizes are of interest when running these tests? 1-100, 1-1000,
>>>> 1-1, etc?
>>>
>>>
>>> Typically 1-100 or 1-1000 is of interest.
>>>
>>>
>>>> Can a given test be faster with one assembly file at one size, but be
>>>> faster with a different assembly file at a larger size?
>>>
>>>
>>> Yes, sometimes a stall can slow down the processor from some size on.
>>> Anything can happen. The only way to get it optimal is to wrote new
>>> assembly for that particular CPU after analysing stalls and performance
>>> counters.
>>>
>>>
>>>> When I gather this data, would you like a copy of it?
>>>
>>>
>>> No. I don't have time to do anything with it.
>>>
>>>
>>>> Perhaps in a csv file?
>>>>
>>>> BTW, when I run the speed program as is, right now, it gives results
>>>> similar to the following:
>>>>
>>>> $ ./speed -s 10-20 -t 5 mpz_add
>>>> overhead 0.4 secs, precision 100 units of 

Re: [mpir-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via mpir-devel]

Whoops, looks like I was wrong about us correctly handling Haswell without
BMI2. We handle Skylake correctly, but Haswell we don't check for BMI2.

It looks like the Haswell directory has been divided into haswell and
haswell/avx, which is probably intended for this distinction, but I think
we decided to wait and see if anyone actually had one of these machines
before we panicked too much.

I'll have a think about this.

On 21 February 2017 at 10:53, Bill Hart <goodwillh...@googlemail.com> wrote:

> I have just been contacted off list by a very experienced assembly expert
> who would like to help develop Broadwell assembly optimisations, guided by
> your experiments (as far as I know, he doesn't actually have a Broadwell
> machine).
>
> If you are ok with it, I could share your email with him so that he can
> communicate with you off list. Would you be up for working with him on this?
>
> Bill.
>
> On 21 February 2017 at 09:05, Bill Hart <goodwillh...@googlemail.com>
> wrote:
>
>>
>>
>> On 21 February 2017 at 00:35, <wrai...@morpheus.net> wrote:
>>
>>> Hello Bill,
>>>
>>> I can report that both of my systems are now correctly detected.  Thank
>>> you for the fix!
>>>
>>> I also noticed that there were a couple of other missing processor
>>> models when compared with GMP mpn/x86_64/fat/fat.c: (the * star values are
>>> missing in MPIR)
>>> Broadwell:
>>> 0x3d=61
>>> 0x47=71 *
>>> 0x4f=79
>>> 0x56=86 *
>>> Skylake:
>>> 0x4e=78
>>> 0x55=85 *
>>> 0x5e=94
>>> Kabylake:
>>> 0x8e=142 *
>>> 0x9e=158 *
>>> There was a word of warning in the GMP source about some Haswell's not
>>> supporting BMI2, and so they treated those as Sandybridges.  I'm not sure
>>> how you want to handle this, but I wanted to make sure I passed the warning
>>> on to you.
>>>
>>
>> Thanks, I will look into the models we are missing. We have no support
>> for Kaby Lake at this point. We are aware of the crippled Haswells and
>> handle those I believe.
>>
>>
>>>
>>> I ran the speed program, but I do not see how to "choose different
>>> assembly files".  Do I have to build different speed programs with
>>> different assembly files linked in?
>>
>>
>> It only uses the assembly files currently linked into MPIR. You have to
>> put different files in and rebuild.
>>
>>
>>>   Is this an option passed to "make speed"?  Do various gmp-mparam.h
>>> files need to be copied to a specific location before "make speed" to
>>> create a different speed binary?
>>
>>
>> gmp-mparam.h has no effect on speed.
>>
>>
>>> Once I'm past this step, I believe I can figure out the rest by writing
>>> a script to automate the data gathering.
>>>
>>> What sizes are of interest when running these tests? 1-100, 1-1000,
>>> 1-1, etc?
>>
>>
>> Typically 1-100 or 1-1000 is of interest.
>>
>>
>>> Can a given test be faster with one assembly file at one size, but be
>>> faster with a different assembly file at a larger size?
>>
>>
>> Yes, sometimes a stall can slow down the processor from some size on.
>> Anything can happen. The only way to get it optimal is to wrote new
>> assembly for that particular CPU after analysing stalls and performance
>> counters.
>>
>>
>>> When I gather this data, would you like a copy of it?
>>
>>
>> No. I don't have time to do anything with it.
>>
>>
>>> Perhaps in a csv file?
>>>
>>> BTW, when I run the speed program as is, right now, it gives results
>>> similar to the following:
>>>
>>> $ ./speed -s 10-20 -t 5 mpz_add
>>> overhead 0.4 secs, precision 100 units of 8.33e-10 secs, CPU
>>> freq 1200.00 MHz
>>>   mpz_add
>>> 100.00025
>>> 150.00031
>>> 200.00033
>>>
>>> $ ./speed -s 10-20 -t 5 mpn_sqrtrem
>>> overhead 0.4 secs, precision 100 units of 8.33e-10 secs, CPU
>>> freq 1200.00 MHz
>>>   mpn_sqrtrem
>>> 100.00717
>>> 150.00900
>>> 200.01129
>>>
>>> Are there any specific options you would like me to use when running
>>> these speed tests and gathering results?
>>>
>>
>> No. But typically I use -t 1 because I want to be able t

Re: [mpir-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via mpir-devel]

I have just been contacted off list by a very experienced assembly expert
who would like to help develop Broadwell assembly optimisations, guided by
your experiments (as far as I know, he doesn't actually have a Broadwell
machine).

If you are ok with it, I could share your email with him so that he can
communicate with you off list. Would you be up for working with him on this?

Bill.

On 21 February 2017 at 09:05, Bill Hart <goodwillh...@googlemail.com> wrote:

>
>
> On 21 February 2017 at 00:35, <wrai...@morpheus.net> wrote:
>
>> Hello Bill,
>>
>> I can report that both of my systems are now correctly detected.  Thank
>> you for the fix!
>>
>> I also noticed that there were a couple of other missing processor models
>> when compared with GMP mpn/x86_64/fat/fat.c: (the * star values are missing
>> in MPIR)
>> Broadwell:
>> 0x3d=61
>> 0x47=71 *
>> 0x4f=79
>> 0x56=86 *
>> Skylake:
>> 0x4e=78
>> 0x55=85 *
>> 0x5e=94
>> Kabylake:
>> 0x8e=142 *
>> 0x9e=158 *
>> There was a word of warning in the GMP source about some Haswell's not
>> supporting BMI2, and so they treated those as Sandybridges.  I'm not sure
>> how you want to handle this, but I wanted to make sure I passed the warning
>> on to you.
>>
>
> Thanks, I will look into the models we are missing. We have no support for
> Kaby Lake at this point. We are aware of the crippled Haswells and handle
> those I believe.
>
>
>>
>> I ran the speed program, but I do not see how to "choose different
>> assembly files".  Do I have to build different speed programs with
>> different assembly files linked in?
>
>
> It only uses the assembly files currently linked into MPIR. You have to
> put different files in and rebuild.
>
>
>>   Is this an option passed to "make speed"?  Do various gmp-mparam.h
>> files need to be copied to a specific location before "make speed" to
>> create a different speed binary?
>
>
> gmp-mparam.h has no effect on speed.
>
>
>> Once I'm past this step, I believe I can figure out the rest by writing a
>> script to automate the data gathering.
>>
>> What sizes are of interest when running these tests? 1-100, 1-1000,
>> 1-1, etc?
>
>
> Typically 1-100 or 1-1000 is of interest.
>
>
>> Can a given test be faster with one assembly file at one size, but be
>> faster with a different assembly file at a larger size?
>
>
> Yes, sometimes a stall can slow down the processor from some size on.
> Anything can happen. The only way to get it optimal is to wrote new
> assembly for that particular CPU after analysing stalls and performance
> counters.
>
>
>> When I gather this data, would you like a copy of it?
>
>
> No. I don't have time to do anything with it.
>
>
>> Perhaps in a csv file?
>>
>> BTW, when I run the speed program as is, right now, it gives results
>> similar to the following:
>>
>> $ ./speed -s 10-20 -t 5 mpz_add
>> overhead 0.4 secs, precision 100 units of 8.33e-10 secs, CPU
>> freq 1200.00 MHz
>>   mpz_add
>> 100.00025
>> 150.00031
>> 200.00033
>>
>> $ ./speed -s 10-20 -t 5 mpn_sqrtrem
>> overhead 0.4 secs, precision 100 units of 8.33e-10 secs, CPU
>> freq 1200.00 MHz
>>   mpn_sqrtrem
>> 100.00717
>> 150.00900
>> 200.01129
>>
>> Are there any specific options you would like me to use when running
>> these speed tests and gathering results?
>>
>
> No. But typically I use -t 1 because I want to be able to analyse all the
> data.
>
> You might also find mpir_bench_two useful (see our website). Note that
> you'll need to run speed multiple times, and keep an eye on the reported
> CPU frequency. Timings vary a lot.
>
> Also, please only use these tools on Linux. Windows is not stable enough
> to get meaningful timings. Good luck!
>
> Bill.
>
>
>>
>> -David C.
>>
>> On 2/20/2017 10:09 AM, 'Bill Hart' via mpir-devel wrote:
>>
>>> I have issued an alpha3 which supports your particular Broadwell chip,
>>> which was
>>> a Family we weren't aware of. Can you verify that it is now detected
>>> correctly.
>>>
>>> As for optimising for Broadwell, if you are interested, we'd be happy to
>>> have
>>> the help. I've added details to the relevant ticket [1] to explain what
>>> would
>>> need to be done. But it's not for the faint hearted!
>&