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

[Philipp Stephani]

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.)