Re: error handling

These are some very good ideas. But just to make clear what my own (rather narrow) goals are: to be able to compile GMP in such a way that the mpn-level routines do not call abort (except perhaps for asserts that indicate an internal bug), but rather, throw a C++ exception. As I understand it,

error handling

So I've just released NTL v8, which is a library that builds on the mpn-layer of GMP. See: http://www.shoup.net/ntl/index.html The main thing is that now NTL is exception safe, modulo exception safety in GMP (one can build a slower, fully exception-safe version of NTL that does not rely on GMP).

Re: Additional memory handler features.

, assuming all the necessary itch/scratch mpn-level routines are available, and none of them abort for any other reason. If anyone cares, I can generate a list of all mpn-level routines used by NTL... On Jan 4, 2015, at 5:27 PM, Marc Glisse wrote: On Sun, 4 Jan 2015, Victor Shoup wrote: But I see

Re: Additional memory handler features.

Thanks. This would more-or-less solve all my problems, if and when it all gets implemented. I don't find such functions right now in the GMP manual. On Jan 4, 2015, at 6:08 PM, Niels Möller wrote: Victor Shoup sh...@cs.nyu.edu writes: But I see mention of itching and scratching: could

Re: Memory barrier for fat initialization

Just to chime in here... I've recently worked on making some thread safe code, and learned all about the new memory model in the C11 and C++11 standards (these are thankfully compatible models). There's lot of stuff online (look for C11 atomics or C++11 atomics, and buzzwords like

VPMADD52

Within the next couple of years, we can expect to see a new instruction on Intel chips: VPMADD52. This will be a part of the AVX512 ISA, but it's not clear when actually chips with these instructions will ship. One variant does an 8-way 52-bit x 52-bit -> low 52-bits "fused multiply add" on

Re: VPMADD52

12 Oct 2015, at 9:29 am, Niels Möller <ni...@lysator.liu.se> wrote: > >> Victor Shoup <sh...@cs.nyu.edu> writes: >> >>> There is a complement of " blend" instructions which should do the >job. >> >> I'll have to look that up. >> >

__uint128_t

This may be a bit off topic, but I figure the people on this list might know something about this. In some code I've been developing lately (NTL related, of course), I've been making more use of the __uint128_t type that is available on gcc (and its clang and icc clones). It's all ifdef'd

Re: Any interest in multi-threaded code?

.@lysator.liu.se> wrote: > > Victor Shoup <sh...@cs.nyu.edu> writes: > >> So I guess I'm just asking where the FFT code is at and if there would be >> any objections to my using it in that way. > > Here: https://gmplib.org/repo/gcd-nisse/ > > The relati

Re: Any interest in multi-threaded code?

Presumably, that idea will work. But based on my experience with multi-threading, because of various overheads and latencies involved, you have to make sure that there is enough work to do per thread to make it worthwhile. Parallelizing the inner loops like this may or may not yield the expected

Re: Any interest in multi-threaded code?

Hi all, Since this FFT code is sitting around, I wonder if there's a chance I could adapt it to NTL. I've actually implemented David Harvey's ideas a few years ago (and his work is actually based on older NTL logic which I never really publicized). NTL currently only uses special types like

Re: Any interest in multi-threaded code?

Thanks! > On Apr 4, 2018, at 4:53 PM, Niels Möller <ni...@lysator.liu.se> wrote: > > Victor Shoup <sh...@cs.nyu.edu> writes: > >> So I guess I'm just asking where the FFT code is at and if there would be >> any objections to my using it in that way. &g

Re: mpn_mul is embarrassingly slow

Interesting. I see that this paper compares to NTL as well. I spent the morning seeing what I could do to improve the situation for NTL, whose mul routine has essentially the same functionality as mpz_mul (takes care of memory allocation and signs). I reduced some overheads and for small inputs

Re: mpn_mul is embarrassingly slow

I'm not sure that's a great idea from a backward compatibility point of view. Also: when exactly was mpn_sqr added to the public interface? That's something I'll have to take into account in writing GMP client code. > On Apr 24, 2018, at 8:11 AM, paul zimmermann

Re: mpn_mul is embarrassingly slow

Well, if you do, please change the name of the function backward compatibility... > On Apr 24, 2018, at 9:49 AM, Niels Möller wrote: > > I would prefer the opposite change for GMP7, to have all multiplication > functions return, but *not* store, the high limb of the

Re: gcd_22

Regarding the so-called doc bug, if I understand the issue correctly, I don’t think it’s a good idea to add more preconditions to the documentation. In fact, I think that would be a really bad idea. > On Aug 25, 2019, at 2:34 AM, niels mller > wrote: > > t...@gmplib.org (Torbjörn Granlund)

Re: Small gcdext_1

By the way, if you do changed extended Euclid, please remember to respect the documented constraints on the cofactors. This was an issue many years ago, which was eventually resolved, and hopefully will remain so. Thanks! > On Oct 31, 2019, at 12:00 PM, torbjrn granlund > wrote: > >