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 a...@ajf.me wrote:
Hi Lester,
On 3 Feb 2015, at 08:56, Lester Caine
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 integers
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
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
On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk 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
Hi Lester,
On 3 Feb 2015, at 08:56, Lester Caine les...@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
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 'computers
Am 03.02.2015 17:44 schrieb Andrea Faulds a...@ajf.me:
On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk 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
On 3 February 2015 21:49:28 GMT, Lester Caine les...@lsces.co.uk 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
On 3 Feb 2015, at 21:49, Lester Caine les...@lsces.co.uk 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
On Tue, Feb 3, 2015 at 10:44 AM, Andrea Faulds a...@ajf.me wrote:
On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk 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
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
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 RAM
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
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
Hi Lester,
On 2 Feb 2015, at 23:46, Lester Caine les...@lsces.co.uk 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
Hi,
On 28 Jan 2015, at 01:43, Andrea Faulds a...@ajf.me 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
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.
On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov dmi...@zend.com 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,
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 pierre@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov dmi...@zend.com wrote:
On 15 Jan 2015, at 11:01, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 15 Jan 2015, at 07:56, Dmitry Stogov dmi...@zend.com 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.
Hi Dmitry,
On 15 Jan 2015, at 11:11, Dmitry Stogov dmi...@zend.com 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
Hey Dmitry,
On 15 Jan 2015, at 07:56, Dmitry Stogov dmi...@zend.com 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
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,
Hi Andrea,
Where can I get the code?
Thanks. Dmitry.
On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov dmi...@zend.com 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
On 14 Jan 2015, at 19:43, Dmitry Stogov dmi...@zend.com 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
On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov dmi...@zend.com 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.
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 a...@ajf.me wrote:
On 14 Jan 2015, at
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 pierre@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov dmi...@zend.com
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 a...@ajf.me wrote:
Hey Dmitry,
On 23 Oct 2014, at 16:22, Dmitry Stogov dmi...@zend.com wrote:
I’ve so far been
Hey Dmitry,
On 23 Oct 2014, at 16:22, Dmitry Stogov dmi...@zend.com 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
On 22 Oct 2014, at 21:12, Andrea Faulds a...@ajf.me 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,
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
Hi!
On 23 Oct 2014, at 13:47, Dmitry Stogov dmi...@zend.com 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
On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds a...@ajf.me wrote:
Hi!
On 23 Oct 2014, at 13:47, Dmitry Stogov dmi...@zend.com 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
On 21 Oct 2014, at 09:35, Dmitry Stogov dmi...@zend.com 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
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.
?php
function
On 21 Oct 2014, at 09:35, Dmitry Stogov dmi...@zend.com 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
On 10 Oct 2014, at 22:33, Andrea Faulds a...@ajf.me 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
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 GMP
On 14 Oct 2014, at 09:51, Stas Malyshev smalys...@sugarcrm.com 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:
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
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
On 14 Oct 2014, at 18:25, Stas Malyshev smalys...@sugarcrm.com 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
On 14 Oct 2014, at 18:48, Lester Caine les...@lsces.co.uk 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
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 it
On 14 Oct 2014, at 19:11, Stas Malyshev smalys...@sugarcrm.com 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
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 now doesn't need
On 14 Oct 2014, at 19:29, Lester Caine les...@lsces.co.uk 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
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
On 14/10/14 19:33, Andrea Faulds wrote:
On 14 Oct 2014, at 19:29, Lester Caine les...@lsces.co.uk 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
On 14 Oct 2014, at 19:53, Lester Caine les...@lsces.co.uk 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
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 les...@lsces.co.uk 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
On 14 Oct 2014, at 20:46, Rowan Collins rowan.coll...@gmail.com 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
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
On 14 Oct 2014, at 21:47, Stas Malyshev smalys...@sugarcrm.com 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
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 (for
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 one …
“Bigints”
On Oct 11, 2014 4:14 PM, Lester Caine les...@lsces.co.uk 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
On 11/10/14 14:36, Pierre Joye wrote:
On Oct 11, 2014 4:14 PM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk 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 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
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 (for
Good evening,
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 mentioned, incomplete. Additionally,
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
On 10 Oct 2014, at 23:20, Lester Caine les...@lsces.co.uk 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
On 11/10/14 00:28, Andrea Faulds wrote:
On 10 Oct 2014, at 23:20, Lester Caine les...@lsces.co.uk 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
On 11 Oct 2014, at 00:40, Lester Caine les...@lsces.co.uk 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
67 matches
Mail list logo
