Re: [RFC] Big Integer Support

From: Date: Tue, 03 Feb 2015 14:03:56 +0000
Subject: Re: [RFC] Big Integer Support
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-81712@lists.php.net to get a copy of this message
Hi Lester, > On 3 Feb 2015, at 08:56, Lester Caine <lester@lsces.co.uk> wrote: > > 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’t see how it’s “overly heavy”. Bear in mind that several extensions (not just >> ext/gmp) already require GMP anyway. > > libgmp.so is 538.6kb > gmp.so add a further 242.1kb > > 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=63595 Also, the bigint branch doesn’t 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’t actually need GMP anyway. The patch also bundles a lightweight, pure C89 bigint library called LibTomMath which will be built if you don’t ask to use GMP explicitly. It’s nowhere near as fast as GMP, but it’s 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 “pair of 32-bit integers” 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. > > 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’re free to. But I don’t 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/

« previous php.internals (#81712) next »