From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bignum branch Date: Mon, 16 Jul 2018 21:06:01 +0300 Message-ID: <83k1pv8392.fsf@gnu.org> 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 X-Trace: blaine.gmane.org 1531764244 11389 195.159.176.226 (16 Jul 2018 18:04:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 18:04:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 20:04:00 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 1ff7qp-0002q4-Qc for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 20:03:59 +0200 Original-Received: from localhost ([::1]:53096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff7sw-00008Z-Gb for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 14:06:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff7si-00006K-CV for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:05:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff7sf-0006dF-8M for emacs-devel@gnu.org; Mon, 16 Jul 2018 14:05:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff7sf-0006dB-4N; Mon, 16 Jul 2018 14:05:53 -0400 Original-Received: from [176.228.60.248] (port=1409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ff7se-0002DS-IQ; Mon, 16 Jul 2018 14:05:52 -0400 In-reply-to: (message from Stefan Monnier on Mon, 16 Jul 2018 12:09:41 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:227474 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 16 Jul 2018 12:09:41 -0400 > > > 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. Between 512MB and 2GB is what I had in mind. > > 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. That's what I'd expect as well, and so I don't think --with-wide-int will die too quickly. I personally need to use buffers larger than 0.5GB all the time on my daytime job.