From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.devel
Subject: Re: [PATCH 2/2] Add module functions to convert from and to big
integers.
Date: Sat, 2 Nov 2019 20:17:39 +0100
Message-ID:
References: <20190423131742.65814-1-phst@google.com>
<20190423131742.65814-2-phst@google.com>
<102dc3dc-554c-a55e-ae7c-cc7357ee60f5@cs.ucla.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
logging-data="200176"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: Philipp Stephani , Emacs developers
To: Paul Eggert
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 02 20:18:13 2019
Return-path:
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.89)
(envelope-from )
id 1iQyuZ-000puU-AB
for ged-emacs-devel@m.gmane.org; Sat, 02 Nov 2019 20:18:11 +0100
Original-Received: from localhost ([::1]:50116 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1iQyuY-0002RY-2X
for ged-emacs-devel@m.gmane.org; Sat, 02 Nov 2019 15:18:10 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59820)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from ) id 1iQyuH-0002RF-Fb
for emacs-devel@gnu.org; Sat, 02 Nov 2019 15:17:54 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1iQyuG-0004eE-2m
for emacs-devel@gnu.org; Sat, 02 Nov 2019 15:17:53 -0400
Original-Received: from mail-oi1-x242.google.com ([2607:f8b0:4864:20::242]:40616)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from )
id 1iQyuF-0004cn-UD
for emacs-devel@gnu.org; Sat, 02 Nov 2019 15:17:52 -0400
Original-Received: by mail-oi1-x242.google.com with SMTP id r27so10889322oij.7
for ; Sat, 02 Nov 2019 12:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=9Whg9UHzQ86dct4tnevedBMwCO34W7kxtOcDL7C0aRg=;
b=OV3DKnuZpt78cl4cCn04pTU3FhnPXbqEp5EsL0WBR9bhSvJPewa1HbuB1+Xsfemn9W
EbeXeMHPN7Jt/J0tGp2pNqeXJp74csmGXhAheO+TwEDTubzgv67PYIPYkmS9aNyjrJqK
oejbi4xBEkJDbyF7ZdogX9083/45M9oe1RR6vZg6bnTvWmcEfUreNzNIxz2hC1Vw2CMA
SybDIrwa6M+ZEIUQU6E2idWOUOns4kPatygF0PX3sHeBey5cde7FzbVQc2gWqmN4BjxL
UKAOQYP52PRksNnMU6/86vJk9cWZamNDal55xiKO2ar5cVSzRAN6UIQWHvqoyhRTLuZ1
zpig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=9Whg9UHzQ86dct4tnevedBMwCO34W7kxtOcDL7C0aRg=;
b=Pn/t6TrHRFIRKJfW5tHuf9wv2jZwdHY5sPkBFb1iptzMACtnnn1BrwmgJwyX7KUugS
ovccs3xTgBt9V30Hc+QoLrCGyEPSf9ju+4t/4+/YqwoBgEEnhKBq4IYVWDR/jKmM706v
PF2l8XS9Mj/gZUuKAPiFnprT5wlEB77oSDxpdl5FwXnxSZARAJrv4b7wz5dh7wyLqOO7
TUou5+S1zkAdwdQ8Te4qIlHuaPv+f1q+IPuXkIO0Z3Efy5ITiLiUYcmtyySdMAbGocO3
8fl5vg2kNq+/bvtoAWah6+3INa/iGU5W4jePFHnmA13n0KbVoXpBcR6V4mAh+MozZCsA
Ugvw==
X-Gm-Message-State: APjAAAUcv2QdTMF6joL1W0Z0Lgczoh6ZOsfqQl0G3Y9R2nxSL3qhYyK+
LdmM+J3zSjVD47w7wbvqrQTzmd+79FpHW7WtPeCEhg==
X-Google-Smtp-Source: APXvYqwvoXq0qFSwDZjHMJYQ5iBSNa4ax6s2mr1c390i5ZNCMrXLDPi4Bb0pGTRp32yBJx6veidxIzX4yxfwfpuRWjU=
X-Received: by 2002:aca:c64c:: with SMTP id w73mr6092713oif.161.1572722270645;
Sat, 02 Nov 2019 12:17:50 -0700 (PDT)
In-Reply-To:
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2607:f8b0:4864:20::242
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Emacs development discussions."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel"
Xref: news.gmane.org gmane.emacs.devel:241744
Archived-At:
Am Di., 23. Apr. 2019 um 17:54 Uhr schrieb Philipp Stephani
:
>
> Am Di., 23. Apr. 2019 um 17:48 Uhr schrieb Paul Eggert :
> >
> > On 4/23/19 8:12 AM, Philipp Stephani wrote:
> > > I considered using GMP. However, it has quite a few downsides:
> > > - It would require making emacs-module.h dependent on GMP, even for
> > > users that don't use big integers. Right now it only depends on
> > > standard C, and I'd like to keep it that way.
> > > - It's unclear how well GMP is supported in other languages. mpz_t is
> > > a weird and unusual type, and other languages might not support it
> > > well in their C interface.
> > > - Other languages tend to have their own bigint support, so I don't
> > > think the advantages of using GMP directly are that big.
> >
> > All true, though Emacs requires GMP anyway (one way or another) and it's
> > typically faster than the non-GMP approaches used in Python (and I
> > assume elsewhere).
>
> Emacs does require GMP, but module authors might not.
>
> >
> > Some of this depends on the importance of performance and convenience
> > when communicating between Emacs Lisp and GMP-using modules. If these
> > are unimportant then the current approach is OK. However, I'm thinking
> > that at least some users will view them as being important.
>
> They are definitely not unimportant, though less important than
> robustness and simplicity.
> OTOH, the proposed approach isn't really simpler or more robust
> either. It's just less dependent on third-party libraries.
After gaining a bit of experience with the current implementation
(including writing bindings for Go), I'm now again convinced that we
should take the original approach (only relying on the C standard and
not introducing an optional dependency on GMP).
- It feels generally wrong and too heavyweight to introduce a
dependency on a third-party library just to represent what is
essentially a byte array plus a sign bit.
- The current implementation requires module authors to depend on
exactly the same GMP library as Emacs, because otherwise the
allocation functions aren't compatible. In particular, module authors
can't statically link GMP.
- Many programming languages such as Go, Java, or Python have big
integer support built into the language or the standard library. They
don't gain anything from using GMP in the module interface.
- The interface leaks an implementation detail of Emacs to the module
interface. Even if Emacs were to switch away from GMP at some point,
it would still have to support the GMP interface and link against GMP.
- Using conditional compilation means that the header isn't hermetic
any more. This can produce surprising results (compilation now depends
on whether some other header has already included emacs-module.h, with
potentially other preprocessor macros), and breaks things like
precompiled headers.
The primary advantages of using GMP in the interface are:
- C and C++ module authors that use GMP anyway benefit from a bit
easier interface. I don't think this argument is very strong, as
writing the necessary glue code using mpz_import and mpz_export isn't
too onerous and can easily be factored out.
- Not calling mpz_export/mpz_import is a bit faster. This seems like
premature optimization to me, but we can even avoid that overhead by
using an unsigned long array for the magnitude: then GMP will
special-case the export/import to a memcpy (in the typical case where
the GMP limb is itself an unsigned long).
Overall I now think the original approach (without mpz_t) is quite
superior, and unless I hear convincing counterarguments, I'll send a
patch to revert to that.