On Sun, Feb 15, 2015 at 6:42 PM, Leigh <lei...@gmail.com> wrote: > On 15 February 2015 at 13:51, Andrea Faulds <a...@ajf.me> wrote: >>> Extensions "that deal with numbers" are all going to need updating. So >>> probably every extension? >> >> Anything accepting a zval rather than a long through zpp, but the changes >> are quite small in most cases. It’s a much smaller change than, say, what >> phpng did. > > The real-world performance gains of ng are significant. Everything is > a trade-off. Having to change exts because the guys behind ng have > made (potentially) "80% of all websites" faster is acceptable - in my > opinion.
Let be serious here, the zpp changes be for 7 (pls stop calling that ng, it is 7 now :) or for this RFC is irrelevant. An ext wants to support bigint? fine. It can't? Then it will fail or cast with warning or notice. >>> You talk about eventually deprecating ext/gmp and moving it to PECL. >>> Definitely not acceptable. >> >> I *talk* about it. I’m not saying we’ll do it. It’s a future possibility: >> since it would be made largely redundant by large integer support in core, >> we might eventually get rid of it. >> >> I said “might” because it’s not part of the proposal, it is merely a thought. > > The GMP ext offers a lot more than arbitrary precision arithmetic. > There's a slew of functions there that go hand in hand with big ints > and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name > a few. There are applications, both proprietary and open that depend > on these. I'd personally be willing to help bring more functionality > to ext/gmp rather than lose all of these important functions to PECL. Fully agree, gmp allows more. And it should not be removed. While "native" bigint support is really handy and I can see many benefits. Using GMP for other features remain important. >>> Sorry, the fixed size integer data type is far too baked-in and >>> useful. >> >> I could understand your perspective if PHP had modular arithmetic like C and >> such, but it doesn’t. So I don’t understand why it is “far too useful” - >> what usefulness is being lost by extending its range? > > Among other thing the behaviour of overflow and shift operations are > well documented and understood quirks of fixed size integer types. Does that mean it should not be improved? Aka more obvious and less quirky? >>> I don't see any gain from this patch except hidden performance >>> penalties, breaks, and extra work for everyone in maintaining it and >>> other extensions. I'd rather big int usage was kept verbose and >>> conscious. >> >> I see a clear gain: we clean up almost every integer overflow edge case, >> integer overflow handling is more intuitive, we support large integers >> safely on 32-bit, and we don’t require you to use a weird extension that may >> crash the PHP interpreter and DoS your web host in order to do large number >> arithmetic. > > A weird extension? The base library of which you are using to back > your big int implementation. I agree here too. gmp is just fine. I see this RFC as a different thing. Having bigint support in the engine makes sense regardless of gmp. Other languages have it and are very happy with that. It is simply way easier and cleaner to use than relying on an ext (while Nikita's patch for operators overloading for exts makes things better). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
