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] Change module interface to no longer use GMP objects
directly.
Date: Mon, 25 Nov 2019 22:59:29 +0100
Message-ID:
References:
<20191117183828.82379-1-phst@google.com>
<089f3d06-e227-27da-c8fe-afcbbbbc934a@cs.ucla.edu>
<10cefdff-38ce-438b-881d-15d2fe816a8b@cs.ucla.edu>
<3d727645-911e-fc71-1f86-364aa82d06ba@cs.ucla.edu>
<287b5f71-75eb-bae2-4f6e-01cce6f07b02@cs.ucla.edu> <87sgmdmxn9.fsf@hase.home>
<3479c610-17b7-579c-8109-f7f5d237dcc2@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="254861"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: Philipp Stephani , Andreas Schwab ,
Stefan Monnier ,
Emacs developers
To: Paul Eggert
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 22:59:54 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 1iZMOg-0014Ai-Co
for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2019 22:59:54 +0100
Original-Received: from localhost ([::1]:48616 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1iZMOf-0002Ax-2p
for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2019 16:59:53 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36336)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from ) id 1iZMOV-00028M-BQ
for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:59:44 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1iZMOU-0004GX-3y
for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:59:43 -0500
Original-Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]:33047)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from )
id 1iZMOT-0004GF-Vm
for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:59:42 -0500
Original-Received: by mail-ot1-x343.google.com with SMTP id q23so8222940otn.0
for ; Mon, 25 Nov 2019 13:59:41 -0800 (PST)
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=oZhy9Lb6yHUx6XBjzpN0kkDajWzAYgdRND2pIjbecb0=;
b=eNwUYZXzpGFl9966R0e0b3bZ6J2TIw2QBZokELnd5kludKFvDILuvrW8Wqg5QYv5R5
D9Xgn43pv1VB5z6BMcs6bZQoUN0+SKf17miEUHHOvbu1YG37sWZaoFjFAjeW4Pvu9TKI
SxT0VKOGKzdPLHeGq52zo5Dw6xVS8CVbNEGgoS86gMd+EGwKf/eGqhg3/wk+H6hTUW3I
iZ4a6oVyxCyKt6qlGhcziCW0FVhWAHQ62H1W5cuCwFPMGVgnWI76bdvispvWVO4Fkn5K
JGGD/u5oCjUtxQWs1TVxQvbTtuIhaz48aMmhu+zdg/MDUUAnhwxJFalOzWX/0W2xpVn8
I/8Q==
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=oZhy9Lb6yHUx6XBjzpN0kkDajWzAYgdRND2pIjbecb0=;
b=uHaMqKD0f1uzQRLA76gWqZRP1cRjZvatb7+MQfFzVqv6CtYO1HrJauXjECJZSVPy5W
PUImAOXsvztHBOpaVxLZq8JGg7gK2k5b9CEWp/U5MAiSc2mNuXZQBLbl5oPmDDIXYr4P
sfAVHkq17P/ATICI/NbQ3GV8e5/tUg914ZOkPwmcJIFoEr+IpTLRUjfSUC4D1Z9wcj7r
Qs2k5MPF3CTxMr534ujLoK40tu6vFee61Sp3hoqBB73FYVra9QLt40r00p5lRnZY5+Pe
EGltQ81xIz1jkV9CI07YpbP9DdoKNd5IOM+tWZJAR4HV/xrptNuE/4RfkJwdITWpRdMb
gSYw==
X-Gm-Message-State: APjAAAXyr/txqzciwDZDaU4t7xbAIsqmPLSMbxcL+bU1qx7BrrMmI+1Q
7mfx1Z5cVUhbDPEetEpjiHvbuffbqDNS6COwByM=
X-Google-Smtp-Source: APXvYqxgHbGIGip39Hg2N/f/cbSQzkDALxgRjeG7Mxolcviryadph8EZ2xIfKtNd4rV583ODlY1hJKay9e35X7wA2x4=
X-Received: by 2002:a9d:38b:: with SMTP id f11mr20849474otf.149.1574719180913;
Mon, 25 Nov 2019 13:59:40 -0800 (PST)
In-Reply-To: <3479c610-17b7-579c-8109-f7f5d237dcc2@cs.ucla.edu>
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2607:f8b0:4864:20::343
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:242722
Archived-At:
Am Mo., 25. Nov. 2019 um 22:03 Uhr schrieb Paul Eggert :
>
> 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.)