From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Bignum performance (was: Shrinking the C core) Date: Wed, 16 Aug 2023 06:36:30 +0200 Message-ID: References: <87bkfartof.fsf@localhost> <175cf474-29c8-a482-072e-0de784ac59e8@gmail.com> <87o7jaqc31.fsf@localhost> <2d419e12-9239-de3e-47d0-38815a00025f@gmail.com> <87cyzqq7sx.fsf@localhost> <875y5gh075.fsf@dataswamp.org> <87zg2spcxo.fsf@localhost> <87o7j8ey0y.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NSzfM8VnuECEeZQV" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27404"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 16 06:37:38 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qW8Hp-0006uX-Vl for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Aug 2023 06:37:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qW8Gs-00044n-S9; Wed, 16 Aug 2023 00:36:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qW8Gq-00044c-IU for emacs-devel@gnu.org; Wed, 16 Aug 2023 00:36:36 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qW8Gn-0000Yq-PM for emacs-devel@gnu.org; Wed, 16 Aug 2023 00:36:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nundwMLzBItp8tLZfba0HuFpV9/oNLH8qNb5NWLcX4U=; b=VGy9ebYKdDmJ8BbZQe6gtOOKpE sN6xUG0xPq7CqTQPE5vgZ7p009sVztSvvT1lnKmx7XaQnsuTXRbK826QmG2/A/CKcWX01XuMuAmeA zu0hsOn+JeH64Avs3VmRUeUPtCHIasZ7TPDgd2qYPpsdMcFfTS2ja8sz9ZO0b/BySpOffu6GemEpH BosAzl95vvuOL63sHWx1MLdwCH+rxrv65FpA8GCZIJ4IOT+/kf6nLVqlCFpHi7dSfNowP68tJKsrJ 5Vgw0We3gxq2HAD8T7jMdOVPpFHSbfuXEMAOUl50oUiTjY/8SzF9q2PcEae64KKgw7R3TaRmn2r0j v3Qrap9Q==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1qW8Gk-0001iN-OF for emacs-devel@gnu.org; Wed, 16 Aug 2023 06:36:30 +0200 Content-Disposition: inline In-Reply-To: <87o7j8ey0y.fsf@dataswamp.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308791 Archived-At: --NSzfM8VnuECEeZQV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 16, 2023 at 12:33:33AM +0200, Emanuel Berg wrote: > Ihor Radchenko wrote: >=20 > > Yes, but when CBCL is orders of magnitude faster, it > > indicates something conceptually wrong in the algo. >=20 > Indeed, I'll remove it, thanks. >=20 > But my CL skills aren't at that level so someone else added > it. A strange optimization indeed, that breaks the code. It only breaks the code if you "don't know what you are doing". See, without the optimization the code will have, at each and every arithmetic operation, to check "Hmm... Is this thing going to overflow? Hm. It might, so better use bignums. Phew, it didn't, so back to fixnums". Now we know that modern CPU architectures have a hard time with conditional statements (pipeline stalls, cache mispredictions, all that nasty stuff). So this "Hmm..." above is costing real money. Even in cases you won't need it, because things ain't gonna overflow. The compiler tries to do a good job of looking into calculations and deciding "this incf down there won't ever push us over the fixnum limit, because we know we are starting with a number below 10". But the programmer sometimes has more knowledge and can prove that things won't overflow, ever. Or that, should things overflow, it won't matter anyway. It's for those cases that this kind of optimizations are made. C, by the way, always runs in this mode. Unsigned integers will silently wrap around, that's documented behaviour. Signed integers will do whatever their thing is (technically this is called "unspecified behaviour". Perhaps you wanted just to compute fib modulo some big power of two? Then your program was correct, after all... Cheers --=20 t --NSzfM8VnuECEeZQV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZNxSSAAKCRAFyCz1etHa Rs4lAJ45yDNeSAkbOa3DwJW0b0e5HiRaeQCcDZuZ3E+bDFI/8c5qE+BHc5bgy2A= =EVPz -----END PGP SIGNATURE----- --NSzfM8VnuECEeZQV--