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