Re: [PATCH] Change module interface to no longer use GMP objects directly.

[Philipp Stephani]

Am Mo., 25. Nov. 2019 um 22:59 Uhr schrieb Philipp Stephani
<address@hidden>:
>
> Am Mo., 25. Nov. 2019 um 22:03 Uhr schrieb Paul Eggert <address@hidden>:
> >
> > On 11/24/19 1:28 AM, Andreas Schwab wrote:
> > > It's like compiling for a completely different architecture.
> >
> > Yes, and that's the point.
> >
> > We agree that choice of 'configure' options can change the platform, and
> > that one cannot assume that modules built for one platform are
> > compatible with an Emacs built for another.
>
> It cannot "change the platform" for usual definitions of "platform"
> (combination of operating system and CPU architecture). Different
> configuration options don't constitute "platforms."
>
> >
> > The disagreement is whether we should consider GMP to be "part of Emacs"
> > (so GMP should not affect the module ABI) or "part of the platform" (so
> > GMP can affect it). Both approaches are plausible; the former lets
> > modules be more portable, and the latter gives modules better
> > performance. Although I'm a fan of portability, here the portability
> > advantage seems small and the performance advantage significant, so it's
> > not clear that saying "GMP is part of Emacs" would be a win.
>
> Unsurprisingly I completely disagree with that. As I've shown (!) in
> the commit message, even in the case of a function that does nothing
> except dealing with big integers, the overhead on GNU/Linux (and
> presumably most Unix systems) is insignificant. (In fact, in an
> earlier benchmark using unsigned char as magnitude element I couldn't
> find any significant slowdown either, even though GMP always had to
> pick the slow path during converting.) On the other hand, you haven't
> shown any significant performance advantage of your approach at all,
> making this a discussion about a purely hypothetical
> micro-optimization. I won't compromise on stability on robustness
> without any data point that would necessitate such a compromise.
> To be totally clear, the primary goals of the module API are
> stability, robustness, and simplicity. Performance is only a secondary
> goal. Even so, in this case there's no performance disadvantage at
> all.
>
> >
> > Since an Emacs 27 release is imminent, perhaps the best thing to do
> > would be to remove the extract_big_integer and make_big_integer methods
> > from src/emacs-module.h.in. These methods are not good in master because
> > they depend on gmp.h, and the proposed replacements are not good because
> > they're slow and awkward.
>
> They are not slow and awkward (at least not more awkward than typical
> C APIs), they are portable, stable, relatively clean, simple, and fast
> enough.
>
> > Plus, quite possibly it will turn out that module authors don't much
> > need a specialized API for bignums. After all, we've gotten along so far
> > without a specialized API for bool-vectors, and to some extent bignums
> > are just bool-vectors in disguise.
>
> Boolean vectors are an exotic data type that isn't common in Emacs
> Lisp or other languages, unlike big integers, which are built in in
> some languages (Python, Haskell), or readily available in the standard
> library (Java, Go).
> (I'm not opposed to adding functionality to extract and create Boolean
> vectors, but they are clearly less important.)

Since there were no more comments or objections, and all other points
of discussion have been resolved, I've pushed a slightly modified
version of the patch as 096be9c454. Except for extremely exotic
architectures or custom GMP builds, the chosen limb should be the same
as the default GMP limb.