Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer

From: Date: Wed, 14 May 2014 05:57:59 +0000
Subject: Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-74154@lists.php.net to get a copy of this message
Pierre, you developed a patch that will negatively affect every PHP application, just to use "modern" types... it's completely not necessary step for 64-bit support. As I said, I can support only part of your patch related to IS_LONG size. Thanks. Dmitry. On Wed, May 14, 2014 at 8:44 AM, Pierre Joye <pierre.php@gmail.com> wrote: > hi Dmitry. > > On Wed, May 14, 2014 at 12:52 AM, Dmitry Stogov <dmitry@zend.com> wrote: > > Anatol, > > > > We discussed your patch in private and I showed you the big penalty it > > makes... > > We discussed how we could best cooperate to get phpng and this patch > together to ease everyone's work. > > > I really, don't see, what do you like to achieve initiating voting right > > after that. :( > > Moving forward as you rejected the whole idea for no good reason or > based on numbers that cannot be taken as valid as this stage. > > > I've just take a quick look over your initial patch for phpng at > > https://gist.github.com/weltling/a941d8cf6c731640b51f > > > > Actually, I would support only one idea from your patch - make IS_LONG to > > be 64-bit on _WIN64. > > Again. This patch is about clean, safe, standard implementation for > 64bit plaforms and modern compilers, by far not only for windows > (which has one more gain with this patch, portability). It brings a > lot of guards, as well as safe and clean implementations. This is > something we should have done a long time ago. PHP is only of the only > OSS language I know still relying on old types and using integer for > buffer length. This is a bad practice and a well known troubles > source. To reduce it to only windows is hardly a good move. > > > Your zend_size_t related changes, in my opinion, makes little sense and > > actually makes more harm. I recompiled phpng with your patch on Linux > > x86_64 and got the following numbers: > > > > zend_string size increased from 24 to 32 bytes > > HashTable size increased from 56 to 72 bytes > > zend_op_array size increased from 248 to 264 bytes > > zend_class_entry size increased from 512 to 568 bytes > > size of each opcode sizeof(zend_op) from 48 to 56 bytes > > These numbers cannot be taken as valid or seriously at this stage. > Restructuring these structs will certainly reduce the delta. I did not > have the time to analyze phpng possible other improvements but I will > do it soon, and will also check with other people from the compiler > team if we can improve it a bit more as well. > > But rejecting a safe and clean 64bit support for a prototype, even > promising, is wrong, in so many ways. See below. > > > Anyone may recompile phpng (with and without patch) and then get these > > number running > > $ gdb sapi/cli/php > >> p sizeof(zend_string) > > ... > > > > Can you imagine memory consumption difference on a large application? > > More memory usage => more CPU cache misses => worse performance. > > I can imagine a lot of things but at this point phpng is a very good > prototype with promising results. There is a good base idea and a lot > of changes in many places improving performance. However it is very > far away from being ready, APIs are very inconsistent and painful to > use (mix of zend_string and char* usage, remaing or removal which may > not make sense or make the code way too complicated). > > > and what are the advantages? strings and class names > 2GB? > > For me it's too big payment for useless feature. > > I do not think it is that useful for both of us to redo the > discussions about this patch and its goal. It is a necessary step for > 64bit support. It is also very hard to use a prototype, developed for > months privately and still being in very early pre-alpha/testing phase > as argument to reject these changes. However, as I told you, it would > be way better to do both together, for everyone. But you reject the > idea. We have to move forward to php-next and I do not think we can > afford to wait months until phpng is remotely usable or stable (at > least APIs wised). > > In any case, if the 64bit patch is accepted we will support you and > other with phpng as we always do, even before its RFC or proposal, > this is what I call cooperation and teamwork. > > Cheers. > Pierre >

« previous php.internals (#74154) next »