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. >> 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. >> 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. >> 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. DoS against libgmp is really stretching it here. Yes you can cause all kinds of horrible crashes if you try and do something ridiculous, but that's why you have a programming language that gives you everything you need to sanitise inputs to prevent it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
