[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Philipp Stephani
Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly.
Date: Wed, 4 Dec 2019 21:31:42 +0100

Am Mo., 25. Nov. 2019 um 22:59 Uhr schrieb 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.)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]