Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81712 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6747 invoked from network); 3 Feb 2015 14:04:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Feb 2015 14:04:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.208 imap2-3.ox.privateemail.com Received: from [192.64.116.208] ([192.64.116.208:55075] helo=imap2-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 73/2E-20608-255D0D45 for ; Tue, 03 Feb 2015 09:04:06 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id EFC258C007D; Tue, 3 Feb 2015 09:03:59 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at imap2.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap2.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Kueme29B-G6p; Tue, 3 Feb 2015 09:03:59 -0500 (EST) Received: from oa-res-26-240.wireless.abdn.ac.uk (oa-res-26-240.wireless.abdn.ac.uk [137.50.26.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 5642D8C0057; Tue, 3 Feb 2015 09:03:58 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: <54D08D50.5050407@lsces.co.uk> Date: Tue, 3 Feb 2015 14:03:56 +0000 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: <1C2ED70C-72A0-4513-A134-5DAE4CCA5B3D@ajf.me> References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <54D00C40.8060907@lsces.co.uk> <54C5DC93-9600-4EE2-BF06-7BF10FC6AD5C@ajf.me> <54D08D50.5050407@lsces.co.uk> To: Lester Caine X-Mailer: Apple Mail (2.2070.6) Subject: Re: [PHP-DEV] [RFC] Big Integer Support From: ajf@ajf.me (Andrea Faulds) Hi Lester, > On 3 Feb 2015, at 08:56, Lester Caine wrote: >=20 > On 02/02/15 23:50, Andrea Faulds wrote: >>> Since a clean 64bit build of PHP does not need anything other than >>>> 'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds = with >>>> an overly heavy solution is just not right! >> I don=92t see how it=92s =93overly heavy=94. Bear in mind that = several extensions (not just ext/gmp) already require GMP anyway. >=20 > libgmp.so is 538.6kb > gmp.so add a further 242.1kb >=20 > You will have to elaborate on what else is reliant on it for a normal > PHP build. cURL and other things that use GnuTLS: = https://bugs.php.net/bug.php?id=3D63595 Also, the bigint branch doesn=92t require ext/gmp to be enabled. > I've only JUST installed any of it on the development machine > to get those sizes and gmp extension is not yet enabled. Well, you don=92t actually need GMP anyway. The patch also bundles a = lightweight, pure C89 bigint library called LibTomMath which will be = built if you don=92t ask to use GMP explicitly. It=92s nowhere near as = fast as GMP, but it=92s liberally-licensed, lightweight, etc. > THAT just seems rather heavy to just support a pair of 32bit integers > that the database extension has already loaded and is handling as a > single object ... on a 32bit platform. Even just a =93pair of 32-bit integers=94 requires a significant effort. = You need to bundle some sort of library to deal with it. >>>> 'longint' only needs an >>>> extension to provide it, which can then be replaced by properly = crafted >>>> code for devices that already have 256bit and better maths = capability >>>> anyway. >> GMP provides high-performance, optimised SIMD assembly = implementations for most platforms. >=20 > Yes GMP does have some ARM support, but it may not be the most = economic > solution. ARM does have it's own more compact libraries for the same > functionality and replacing the 780kb gmp option by something smaller > should be an option, rather than making the rest of the core dependent > on it. If you wish to go to the hassle of adding a bigint backend specifically = optimised for ARM, you=92re free to. But I don=92t consider 0.25MB extra to be such a problem in practice. = The PHP binary is already huge, and every system running PHP will have = ample memory. Thanks. -- Andrea Faulds http://ajf.me/