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.