[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) An other advantage IMHO is that 64-bit integers can represent any integer that can - in float format - be distinguished from it's neighbour. Recall that C-double == PHP-float have at least 64-bits, so a mantissa of 64bits. So any number n for which n and n+1 are distingwishable in 64-bit floating point numbers, must fall in the range of 64-bit integers. For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
On Sun, 23 Sep 2001, Andi Gutmans wrote: We should check with the MySQL guys what the performance implications are. I remember they had a contest for the fastest longlong2str() function. I guess this was due to performance problems. We should also at least see if this would cause problems with all sorts of standard functions missing for long long such as strtol(). I guess stroll? It works with me. supporting long long's is more than just changing the type in the zval. I do realize that... Most extensions assume the type is 'long', so that needs to be fixed first. No matter how you look at it, it will be big job to do. In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). But if this would have a major performance penalty, it's something different... I'll time stroll and strtol to see how much slower it is. Anyway, it would be nice if someone with expericence with changing to 8 byte integers could share his experiences... --Jeroen Andi At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote: Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers (fwd)
This subject is being crossposted to [EMAIL PROTECTED] and [EMAIL PROTECTED] This mail was only on engine2 (let's keep everyting at least on phpdev): -- Forwarded message -- Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST) From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Stig Sæther Bakken [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Zend Engine 2] Bumping PHP to support 8byte integers On 23 Sep 2001, Stig Sæther Bakken wrote: [Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... I don't know what you had in mind, but replacing long lval with long long lval will increase the size of _every_ zval from 8 to 12 bytes. That's indeed a big issue, since it requires more memory _and_ cpu (more data to move around). zval.value is an union with: (4byte)long lval (8byte)double dval (8byte)struct str (4byte)*ht (8byte)stuct obj So not more cpu time in moving around, since C does not know it doesn't need to copy the last 4 bytes in the union. The size of zval will remain value+type+is_ref+refcount = 8+1+1+2 = 12. - Stig Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
[Jeroen van Wolffelaar [EMAIL PROTECTED]] In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). Sorry for starting, but this is just nonsense. First of all, today PHP is a scripting language only by categorization, technically it is no more so than Java. Second, performance is important for PHP. 4.0 beats lots of competition because of its performance. We shouldn't even think of jeopardizing that. When I hear this kind of reasoning from people who suggest core changes, I stop listening. Please tell me you were kidding. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
On 23 Sep 2001, Stig Sæther Bakken wrote: [Jeroen van Wolffelaar [EMAIL PROTECTED]] In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). Sorry for starting, but this is just nonsense. First of all, today PHP is a scripting language only by categorization, technically it is no more so than Java. I thought a scripting language is differnt from a non-scripting language in that a scripting language will be compiled at runtime? True, java has a JIT-compiler (Just In Time). But I don't know much about this, so simply correct me if I'm wrong :-) While I do not know what the running definitions these days. There is pure interpreted code, i.e. where no compilation takes place. Then there are interpreted languages which compile into tokens, and interpret the tokens. Then there interpreted languages like java where the compile to token step is executed by the user. Then there are additions to langauges like java where the tokens are just in time compiled into native code. Of course there are compiled languages where source is compiled into native machine code. I'm not sure what category I'd put scripting languages. Something like a shell script is purely interpreted. If we call scripting languages as those which are purely interpreted, then PHP is not a scripting language. Second, performance is important for PHP. 4.0 beats lots of competition because of its performance. We shouldn't even think of jeopardizing that. Performance is important indeed. (originally I said: perfomance is a bit less important _than in DBMS's_, and everybody knows that in DBMS's, performance is extremely important) I expressed myself a bit unhappy, I think - I'm not sure - that the performance impact of slower arithmetic etc on PHP-integers would be neglectible. String manipulation is much more expensive. Also, definitely not ALL integers in the C-code need to be converted to 64bit of course, only those which are (derived from) PHP variables. Most registers for example can remain 32bit. To name one example, the capacity of hashtable and thus max number of entries in it will remain expressed in 32bit integers. But there will be a lot of integers needing to be converted, and again, I don't know the performance inpact. If it are multiple percents, I think it's not an option. PHP is a fairly large system now. It isn't trivial to make changes like this. If one compiles PHP on a 64bit system, then 64bit numbers could come for free. Moving a complex system from a native register width to an artificial construct like long long is always a big deal, a huge regression test would be needed for any reasonable amount of quality control. I spent a lot of time making 16bit Windows programs deal with 32bit numbers and addresses, and before that I spent a lot of time implementing 16bit arithmatic on an 8bit Z80. There are always a huge number of things you would not have expected to happen. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
