Re: [PHP-DEV] [RFC] Big Integer Support

I agree with Andrea's points , also GMP is also used in ruby 2.1 with good results https://bugs.ruby-lang.org/issues/8796 ps: LibTomMath seems to be used in firebird also On Tue, Feb 3, 2015 at 4:03 PM, Andrea Faulds wrote: > Hi Lester, > > > On 3 Feb 2015, at 08:56, Lester Caine wrote: > > >

Re: [PHP-DEV] [RFC] Big Integer Support

Lester Caine wrote on 04/02/2015 00:49: On 03/02/15 22:35, Andrea Faulds wrote: >>Currently we have a problem with the size of integers, but simply >> >ignoring that there are limits is not the may to fix that problem. >This RFC doesn’t ignore that there are limits. Arbitrary-precision integer

Re: [PHP-DEV] [RFC] Big Integer Support

On 03/02/15 22:35, Andrea Faulds wrote: >> Currently we have a problem with the size of integers, but simply >> > ignoring that there are limits is not the may to fix that problem. > This RFC doesn’t ignore that there are limits. Arbitrary-precision integers > are, naturally, bounded by available

Re: [PHP-DEV] [RFC] Big Integer Support

On 3 February 2015 21:49:28 GMT, Lester Caine wrote: >On 03/02/15 16:44, Andrea Faulds wrote: >> Sure, but I don’t think we shouldn’t cripple the language merely for >the sake of really low-end embedded devices. Also, I’m not convinced >that the overhead, at least in terms of file size, is really

Re: [PHP-DEV] [RFC] Big Integer Support

> On 3 Feb 2015, at 21:49, Lester Caine wrote: > > On 03/02/15 16:44, Andrea Faulds wrote: >> Sure, but I don’t think we shouldn’t cripple the language merely for the >> sake of really low-end embedded devices. Also, I’m not convinced that the >> overhead, at least in terms of file size, is re

Re: [PHP-DEV] [RFC] Big Integer Support

On 03/02/15 16:44, Andrea Faulds wrote: > Sure, but I don’t think we shouldn’t cripple the language merely for the sake > of really low-end embedded devices. Also, I’m not convinced that the > overhead, at least in terms of file size, is really that big of an issue. 'I don’t think we should crip

Re: [PHP-DEV] [RFC] Big Integer Support

On Tue, Feb 3, 2015 at 10:44 AM, Andrea Faulds wrote: > > > On 3 Feb 2015, at 14:49, Lester Caine wrote: > > > > On 03/02/15 14:03, Andrea Faulds wrote: > >> 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 ha

Re: [PHP-DEV] [RFC] Big Integer Support

On 03/02/15 19:59, Martin Keckeis wrote: > Please get this mayor feature finally into the core > In the current century a real 64bit support is not discussable anymore... Martin this has NOTHING to do with getting 64 bit support into core. That has already been achieved by the introduction of

Re: [PHP-DEV] [RFC] Big Integer Support

Am 03.02.2015 17:44 schrieb "Andrea Faulds" : > > > > On 3 Feb 2015, at 14:49, Lester Caine wrote: > > > > On 03/02/15 14:03, Andrea Faulds wrote: > >> 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 m

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Lester, On Tue, February 3, 2015 15:49, Lester Caine wrote: > On 03/02/15 14:03, Andrea Faulds wrote: > >> 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. > > Yes one approach is 'com

Re: [PHP-DEV] [RFC] Big Integer Support

> On 3 Feb 2015, at 14:49, Lester Caine wrote: > > On 03/02/15 14:03, Andrea Faulds wrote: >> 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. > > Yes one approach is 'computers are getti

Re: [PHP-DEV] [RFC] Big Integer Support

On 03/02/15 14:03, Andrea Faulds wrote: > 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. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is n

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Lester, > On 3 Feb 2015, at 08:56, Lester Caine 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 rig

Re: [PHP-DEV] [RFC] Big Integer Support

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 sever

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Lester, > On 2 Feb 2015, at 23:46, Lester Caine wrote: > > Andrea ... I am still unhappy that this is being pushed as the core > 'integer' handling. Further options have appeared for 32bit devices > which are driving me to seriously consider perhaps having to look into a > simple 64bit maths

Re: [PHP-DEV] [RFC] Big Integer Support

On 02/02/15 23:05, Andrea Faulds wrote: > I’m a little worried that nobody has responded to this yet. Feature freeze is > looming… :( Andrea ... I am still unhappy that this is being pushed as the core 'integer' handling. Further options have appeared for 32bit devices which are driving me to ser

Re: [PHP-DEV] [RFC] Big Integer Support

Hi, > On 28 Jan 2015, at 01:43, Andrea Faulds wrote: > > Hey everyone, > > Anatol (aka welting) has done some excellent work, and a lot more extensions > now build on the bigint branch, even if not all of them are fully ported: > > https://wiki.php.net/rfc/bigint#todo > > This should mean th

Re: [PHP-DEV] [RFC] Big Integer Support

Hey everyone, Anatol (aka welting) has done some excellent work, and a lot more extensions now build on the bigint branch, even if not all of them are fully ported: https://wiki.php.net/rfc/bigint#todo This should mean that testing “real-world applications” for performance is now possible. Th

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Dmitry, > On 15 Jan 2015, at 11:11, Dmitry Stogov wrote: > > BTW: why not to wrap big integers into special IS_OBJECT? > It would keep everything working out of the box (without BIGINT), and would > allow to eliminate more than half of unnecessary changes. > > In the past we made similar de

Re: [PHP-DEV] [RFC] Big Integer Support

> On 15 Jan 2015, at 11:01, Andrea Faulds wrote: > > Hey Dmitry, > >> On 15 Jan 2015, at 07:56, Dmitry Stogov wrote: >> >> ext/session and ext/json are required by most apps. >> Actually I stopped attempts to build it when I saw compilation errors in >> ext/session. >> >> Thanks. Dmitry. >

Re: [PHP-DEV] [RFC] Big Integer Support

BTW: why not to wrap big integers into special IS_OBJECT? It would keep everything working out of the box (without BIGINT), and would allow to eliminate more than half of unnecessary changes. In the past we made similar decision for closures. Thanks. Dmitry. On Thu, Jan 15, 2015 at 2:01 PM, Andr

Re: [PHP-DEV] [RFC] Big Integer Support

Hey Dmitry, > On 15 Jan 2015, at 07:56, Dmitry Stogov wrote: > > ext/session and ext/json are required by most apps. > Actually I stopped attempts to build it when I saw compilation errors in > ext/session. > > Thanks. Dmitry. Oh dear, does ext/session not build? :/ So far I've only built th

Re: [PHP-DEV] [RFC] Big Integer Support

I don't know which ones are supported or not. Of course we need some extension to connect to database mysql, mysqli or pdo_mysql. Thanks. Dmitry. On Thu, Jan 15, 2015 at 11:03 AM, Pierre Joye wrote: > On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov wrote: > > ext/session and ext/json are requi

Re: [PHP-DEV] [RFC] Big Integer Support

On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov wrote: > ext/session and ext/json are required by most apps. Right. The question is: Do you see any other we must have before discussing that any further? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.ph

Re: [PHP-DEV] [RFC] Big Integer Support

ext/session and ext/json are required by most apps. Actually I stopped attempts to build it when I saw compilation errors in ext/session. Thanks. Dmitry. On Thu, Jan 15, 2015 at 10:44 AM, Pierre Joye wrote: > On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov wrote: > > Oh, it's still in draft sta

Re: [PHP-DEV] [RFC] Big Integer Support

On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov wrote: > Oh, it's still in draft state. > Too may extensions are missing ext/seesion, ext/json, ext/pdo. > Only very simple tests may be done now, and they can't predict impact on > real-life applications. We may as well try to help here. This patch

Re: [PHP-DEV] [RFC] Big Integer Support

Oh, it's still in draft state. Too may extensions are missing ext/seesion, ext/json, ext/pdo. Only very simple tests may be done now, and they can't predict impact on real-life applications. Thanks. Dmitry. On Thu, Jan 15, 2015 at 12:54 AM, Andrea Faulds wrote: > > > On 14 Jan 2015, at 19:43, D

Re: [PHP-DEV] [RFC] Big Integer Support

> On 14 Jan 2015, at 19:43, Dmitry Stogov wrote: > > Hi Andrea, > > Where can I get the code? > > Thanks. Dmitry. Hey Dmitry, The bigint-libtommath branch was merged back into the bigint branch since I figured there was no point keeping them separate, even if the LibTomMath backend isn’t

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Andrea, Where can I get the code? Thanks. Dmitry. On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov wrote: > I'm really surprised by the results :) > I'll try to find time for bigint on next week and play with it a bit. > > Thanks. Dmitry. > > > On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds wr

Re: [PHP-DEV] [RFC] Big Integer Support

I'm really surprised by the results :) I'll try to find time for bigint on next week and play with it a bit. Thanks. Dmitry. On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds wrote: > Hey Dmitry, > > > On 23 Oct 2014, at 16:22, Dmitry Stogov wrote: > > > >> I’ve so far been scared to touch the as

Re: [PHP-DEV] [RFC] Big Integer Support

Hey Dmitry, > On 23 Oct 2014, at 16:22, Dmitry Stogov wrote: > >> I’ve so far been scared to touch the asm… but actually, I don’t think it >> could be *that* hard. It’s not doing something especially complex. The >> bigint API looks fairly stable now and I’m unlikely to change it much >> further

Re: [PHP-DEV] [RFC] Big Integer Support

On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds wrote: > Hi! > > > On 23 Oct 2014, at 13:47, Dmitry Stogov wrote: > > > > Hi Andrea, > > > > The synthetic benchmarks are not always reflect the impact on real-life > performance. > > > > Unfortunately, I wasn't able to run any big real-life apps wi

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > On 23 Oct 2014, at 13:47, Dmitry Stogov wrote: > > Hi Andrea, > > The synthetic benchmarks are not always reflect the impact on real-life > performance. > > Unfortunately, I wasn't able to run any big real-life apps with your bigint > branch, because it misses support for commonly used

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Andrea, The synthetic benchmarks are not always reflect the impact on real-life performance. Unfortunately, I wasn't able to run any big real-life apps with your bigint branch, because it misses support for commonly used extensions (ext/session, ext/json, ext/pdo). I ran bench.php and it's a

Re: [PHP-DEV] [RFC] Big Integer Support

> On 22 Oct 2014, at 21:12, Andrea Faulds wrote: > > I ran the script several times, then took the results and put them into Excel > to produce the above table with its averages. > > So common scripts are either unaffected, or will run ever-so-slightly faster. Just to be clear, though, that d

Re: [PHP-DEV] [RFC] Big Integer Support

> On 21 Oct 2014, at 09:35, Dmitry Stogov wrote: > > I expect, it'll make some slowdown for all PHP scripts, independently, if > they use BIGINT or not. > I'll try to take a deeper look into the patch later... > > Could you provide some benchmark results, comparing your patch with master? I f

Re: [PHP-DEV] [RFC] Big Integer Support

> On 21 Oct 2014, at 09:35, Dmitry Stogov wrote: > > Hi Andrea, > > Why don't you use the ability of operator overloading? (it's in the engine > since 5.6). I've already answered this in this thread, but I'll answer it again if I must. > > BIGINT don't have to be completely transparent. If

Re: [PHP-DEV] [RFC] Big Integer Support

Hi Andrea, Why don't you use the ability of operator overloading? (it's in the engine since 5.6). BIGINT don't have to be completely transparent. If user would like to work with BIGINT, let them crate PHP objects explicitly and then use operator overloading. e.g. Your solution would allows wri

Re: [PHP-DEV] [RFC] Big Integer Support

> On 10 Oct 2014, at 22:33, Andrea Faulds wrote: > > The RFC can be found here: https://wiki.php.net/rfc/bigint > > The patch is, as I mentioned, incomplete. Additionally, there are quite a few > matters left to be decided (see Open Questions). However, I think I should > put this formally un

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 21:47, Stas Malyshev wrote: >> You throw an error. Just as plenty of functions already can’t handle >> ridiculously large integer arguments. > > The problem is, if you function can handle the int range and you checked > for is_int() and everything worked fine - now it's broke

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > You throw an error. Just as plenty of functions already can’t handle > ridiculously large integer arguments. The problem is, if you function can handle the int range and you checked for is_int() and everything worked fine - now it's broken because is_int() no longer implies fixed range and

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 20:46, Rowan Collins wrote: > Just to break this down a bit: > > 1) The RFC should probably aim to make array keys consistent across > platforms. This is currently left as an unanswered question in the RFC, but > it seems natural to include it if the stated aim is to elimin

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/2014 19:53, Lester Caine wrote: On 14/10/14 19:33, Andrea Faulds wrote: On 14 Oct 2014, at 19:29, Lester Caine wrote: If a 64bit build of PHP is using a simple integer key for a BIGINT key from the database, what will be the equivalent on a 32bit build? It may be that we have to add

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:53, Lester Caine wrote: > The real life situation is that databases have used a 64bit integer as > the primary key for records in a table for a long time now. Loading > these records into arrays using the primary key as the array key is a > natural process but as you have i

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:39, Stas Malyshev wrote: >> We already have this danger for another type: boolean. phpng got rid >> of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update >> everything to handle the IS_BOOL change, surely we can update >> everything to handle bigints, too. > > No,

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 19:33, Andrea Faulds wrote: > > On 14 Oct 2014, at 19:29, Lester Caine wrote: > >> If a 64bit build of PHP is using a simple integer key for a BIGINT key >> from the database, what will be the equivalent on a 32bit build? >> >> It may be that we have to add code to the DB drivers to

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > We already have this danger for another type: boolean. phpng got rid > of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update > everything to handle the IS_BOOL change, surely we can update > everything to handle bigints, too. No, it's not the same thing at all. For bool, you still

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:29, Lester Caine wrote: > If a 64bit build of PHP is using a simple integer key for a BIGINT key > from the database, what will be the equivalent on a 32bit build? > > It may be that we have to add code to the DB drivers to ensure that > BIGINT remains a standard string co

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 19:03, Andrea Faulds wrote: >>> I don't see why you'd have two code paths. If you need bigints and they >>> >> are not there, then you just fail, like with any extension your code >>> >> needs and is not installed. If it's there, you just continue working. >>> >> All the code existing n

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 19:11, Stas Malyshev wrote: > Hi! > >> Still, it’s inconvenient. More for developers to worry about. > > I still have no idea why one would need a bigint constant, could you > give an common example where you would do that? The main point is why you should prohibit it. The

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > Still, it’s inconvenient. More for developers to worry about. I still have no idea why one would need a bigint constant, could you give an common example where you would do that? > No, only extensions. It is *completely* transparent to userland. > That’s the whole point. I'm not sure how

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 18:48, Lester Caine wrote: > On 14/10/14 18:25, Stas Malyshev wrote: >> I don't see why you'd have two code paths. If you need bigints and they >> are not there, then you just fail, like with any extension your code >> needs and is not installed. If it's there, you just contin

Re: [PHP-DEV] [RFC] Big Integer Support

On 14 Oct 2014, at 18:25, Stas Malyshev wrote: > Hi! > >> I'm not sure what this would solve. Sure, you could just use objects >> instead of a new type, but both present exactly the same challenges. >> Adding a new type isn't hard in itself. The problem is updating >> everything which handles n

Re: [PHP-DEV] [RFC] Big Integer Support

On 14/10/14 18:25, Stas Malyshev wrote: > I don't see why you'd have two code paths. If you need bigints and they > are not there, then you just fail, like with any extension your code > needs and is not installed. If it's there, you just continue working. > All the code existing now doesn't need b

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > I'm not sure what this would solve. Sure, you could just use objects > instead of a new type, but both present exactly the same challenges. > Adding a new type isn't hard in itself. The problem is updating > everything which handles numbers and their associated tests. This Exactly. Since ob

Re: [PHP-DEV] [RFC] Big Integer Support

> On 14 Oct 2014, at 09:51, Stas Malyshev wrote: > > Hi! > > >> Since I don’t want this to languish as a ‘Draft’ forever, despite the >> patch being incomplete, I am finally putting the Big Integer Support >> RFC “Under Discussion”. >> >> The RFC can be found here: https://wiki.php.net/rfc/bi

Re: [PHP-DEV] [RFC] Big Integer Support

Hi! > Since I don’t want this to languish as a ‘Draft’ forever, despite the > patch being incomplete, I am finally putting the Big Integer Support > RFC “Under Discussion”. > > The RFC can be found here: https://wiki.php.net/rfc/bigint This introduces new type, IS_BIGINT. However, given that GM

Re: [PHP-DEV] [RFC] Big Integer Support

On 12/10/14 02:15, Rowan Collins wrote: > On 11/10/2014 10:13, Lester Caine wrote: >> BIGINT is the SQL99-compliant 64-bit signed integer type > > It's a matter of context. In C, and therefore in related discussions > (which includes the internals of PHP), integers are referred to as > "short" (fo

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/2014 10:13, Lester Caine wrote: BIGINT is the SQL99-compliant 64-bit signed integer type It's a matter of context. In C, and therefore in related discussions (which includes the internals of PHP), integers are referred to as "short" (for 16-bit), "long" (for 32-bit) and "long long"

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/2014 20:39, Lester Caine wrote: it will not fix the problem that was ORIGINALLY being discussed Your assuming that Andrea's RFC is a response to that particular discussion, rather than simply assuming that it's a valid discussion in its own right. It's perfectly possible to have tw

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/14 19:22, Johannes Schlüter wrote: > But that's bikesheding, if we like we can call it also > yellow-blue-striped birds with red dots. Please discuss the contents not > the painting. Thanks. I AM discussing the content ... it will not fix the problem that was ORIGINALLY being discussed it

Re: [PHP-DEV] [RFC] Big Integer Support

On Sat, 2014-10-11 at 17:05 +0100, Lester Caine wrote: > BIGINT is a cleanly defined concept and something we have had to cope > with for some time since PHP does not support 64 bit integers cleanly. > Now that 64 bit builds support a clean 64 bit integer, the problem > arises that 32 bit builds wi

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/14 14:36, Pierre Joye wrote: > > On Oct 11, 2014 4:14 PM, "Lester Caine" > wrote: >> >> On 11/10/14 01:18, Andrea Faulds wrote: >> >>> >> What you want is 64-bit data handling. This is arbitrary-bit > data handling. It’s not a “wrong approach”. >> >> > >> >> >

Re: [PHP-DEV] [RFC] Big Integer Support

On Oct 11, 2014 4:14 PM, "Lester Caine" wrote: > > On 11/10/14 01:18, Andrea Faulds wrote: > >>> >> What you want is 64-bit data handling. This is arbitrary-bit data handling. It’s not a “wrong approach”. > >> > > >> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit > >> > plat

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/14 01:18, Andrea Faulds wrote: >>> >> What you want is 64-bit data handling. This is arbitrary-bit data >>> >> handling. It’s not a “wrong approach”. >> > >> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit >> > platforms? BIGINT is a fix length number not a variable

Re: [PHP-DEV] [RFC] Big Integer Support

On 11 Oct 2014, at 00:40, Lester Caine wrote: >> What you want is 64-bit data handling. This is arbitrary-bit data handling. >> It’s not a “wrong approach”. > > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit > platforms? BIGINT is a fix length number not a variable one …

Re: [PHP-DEV] [RFC] Big Integer Support

On 11/10/14 00:28, Andrea Faulds wrote: > > On 10 Oct 2014, at 23:20, Lester Caine wrote: > >> Is this the right approach to implement BIGINT? >> I don't see the use of GMP to implement something as simple as native 64 >> bit numbers on 64 bit platforms as the right base. > > Um, we already hav

Re: [PHP-DEV] [RFC] Big Integer Support

On 10 Oct 2014, at 23:20, Lester Caine wrote: > Is this the right approach to implement BIGINT? > I don't see the use of GMP to implement something as simple as native 64 > bit numbers on 64 bit platforms as the right base. Um, we already have this since the 64-bit patch. > All we are missing

Re: [PHP-DEV] [RFC] Big Integer Support

On 10/10/14 22:33, Andrea Faulds wrote: > Since I don’t want this to languish as a ‘Draft’ forever, despite the patch > being incomplete, I am finally putting the Big Integer Support RFC “Under > Discussion”. > > The RFC can be found here: https://wiki.php.net/rfc/bigint > > The patch is, as I