Re: Re: 64bit and phpng, votes and plans

Hello internals! I was following this 64 bit stuff from the get go, and been monitoring the PHPNG stuff as it was announced, so I think I have a pretty clear picture of what's happening. At least I belive so :) And I'm a userland developer, so I'm not into compilers and low-level C stuff, just have the basic understanding and principles at hand. So, to the point of my message. I have a question that is nugging me for weeks now about the 64 bit stuff and how 64 bit processors are handling things. There is no debate that a 64 bit pointer or integer takes double the memory than a 32 bit one, and actually direct comparation gives us a frightening answer - it's doubled! In reality 10 years later we know that it's not that bad (it's common knowlege). My main question is - isn't 2 32 bit integers, stuck into one 64 bit register, handled slower than 2 64 bit integer each occupying it's own register? I'm concerned with the fact, that some of you are so fixated on the memory consumption aspect without any regard to the CPU cycle part of the equasion. It was pointed out by Pierre, and largely ignored, by the vocal advocates for the PHPNG, that despite the change of many 32 bit types to 64 bit it not just didn't degrade the performance (hello, 64 bit processors, no? They by design are more efficient with 64 bit than with 2 32 bit numbers stuck into a 64 bit register), but actually improved it. IMPROVED THE PERFORMANCE. This is logical, this is what you expect optimizing for 64 bit mode. And because of the PHP 5.4 memory reduction (interned strings, if i'm not mistaken?) memory growth is almost non-existent. A 2% to 5% increase in memory usage agains 5.5 after a 30% to 70% memory usage drop in 5.4 is, from my point of view, a drop in the ocean. And PHPNG is a PoC at this point: not optimized, no advanced features implemented, etc. Hell, it's a JIT engine, maybe after initial release you will find a way to minimize thouse ZVAL structures in a way, that it will cut down the memory usage on them much more that you have introduced with 64 bit patch with those size_t types. The future proofing side was mentioned only a few times and I actually want to point this out - memory is growing like crazy - DDR4 is already being shipped, server platforms for DDR4 are being introduced this summer. First DDR4 modules are already surpasing the DDR3 capacity with ease. And data amounts, we are handling in our PHP applications, also grows a lot. Yes, I agree that an array of 2^64 bit elements probably will not be handled by PHP anytime soon, but did you concider the fact that an array's key, indexed by an ID column from the database, can easilly be bigger than 32 bit unsigned integer (I tend to put 64 bit integers as my primary keys these days)? Will it error out if you use a 32 bit array length integer or should you actually use a 64 bit one in this case? At least no one is objecting that we need > 4GB file support. For me, as a userland developer, this future proofing and concictensy, with the slight performance speedup, is much more important that a 2 to 5% memory usage increase. And PHPNG, when actually done and optimized, will bring much more improvement than cutting down this 64 bit patch in half. Most of us have memory to spare on our servers, especially when running a nginx + php-fpm setup. And those, who have memory problems, probably use wrong tool for the job (or poorly designed software). The history shows, that PHP had it's major problems with half-baked solutions or cut down implementations due to politics and obsessive behaviour over some parts of it. I though PHP had it's share of trouble with register_globals and many other bad decisions and now, at least from my point of view, another bad decision is forced on, this time by the Zend itself (at least it looks that way). For god's sake - you make a JIT for PHP. Implement god damn typehints for scalars and optimize the memory usage with JIT optimizations, but leave the room for the manouver for the future. Think also about the extensions - from their point of view using a consistent type is much easier across the board. My 0.02$, thanks.