From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bignum branch Date: Mon, 16 Jul 2018 12:09:41 -0400 Message-ID: References: <87o9fbbw1t.fsf@tromey.com> <86in5jdj49.fsf@gmail.com> <83wotxaiwi.fsf@gnu.org> <86k1pxmvmx.fsf@gmail.com> <87efg4a9xc.fsf@tromey.com> <83d0voa6fw.fsf@gnu.org> <83va9f8cs5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531757267 9061 195.159.176.226 (16 Jul 2018 16:07:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 16:07:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 18:07:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ff62I-0002Gm-0V for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 18:07:42 +0200 Original-Received: from localhost ([::1]:52710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff64P-00084Y-3p for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 12:09:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff64I-00084R-AZ for emacs-devel@gnu.org; Mon, 16 Jul 2018 12:09:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff64E-00006y-Bf for emacs-devel@gnu.org; Mon, 16 Jul 2018 12:09:46 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff64E-00006p-4F; Mon, 16 Jul 2018 12:09:42 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w6GG9fP5032151; Mon, 16 Jul 2018 12:09:41 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 53E45660E5; Mon, 16 Jul 2018 12:09:41 -0400 (EDT) In-Reply-To: <83va9f8cs5.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Jul 2018 17:40:10 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6330=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6330> : inlines <6750> : streams <1792725> : uri <2674512> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:227462 Archived-At: >> > Yes, we need such wrappers in those cases. Another use case is a >> > 32-bit build --with-wide-int. >> Tho, eventually, bignums should make --with-wide-int redundant. > Only if we allow buffer and string text be referenced by a bignum, I'd have said "when" rather than "if", but otherwise, yes. > and if the performance is comparable with --with-wide-int. Not sure what kind of performance you have in mind: a plain old 32bit build with bignums will almost inevitably be more efficient than one --with-wide-int when dealing with buffers <512MB, but it will just as inevitably be less efficient when dealing with buffers between 512MB and 2GB. > Is it reasonable to expect a comparable performance from native 32-bit > code calculating 64-bit values vs function calls? I think I'd be > surprised. Operations on (small) bignums will be significantly slower than operations of "long long" 64bit integers, yes. How this will impact the overall performance when dealing with buffers between 512MB and 2GB I don't know: these already tend to suffer from various other performance problems and I don't know if one will dwarf the other or if they will make each other more painful. Stefan