Re: phpng: Refactored PHP Engine with Big Performance Improvement

Hi Anatol, i agree that coordination from beginning would make some thing easier, but I hardly believe we would able to do the PoC in short time with endless discussions. Lets take what we have now. I understand what you are not glad to do the same work once again. I make take some part of this work, if we come to agreement. According to performance, I wouldn't believe to anything except tests. and it's why I propose to start with the part that can't make any harm. Thanks. Dmitry. On Tue, May 6, 2014 at 11:20 AM, Anatol Belski <anatol.php@belski.net>wrote: > On Tue, May 6, 2014 07:27, Dmitry Stogov wrote: > > >>> Anyway, I think 64-bit integer support on Windows64 makes full sense > >>> and it's possible to add it into "phpng" right now. > >> > >> Again, it is by far not only a windows change, even if Windows is the > >> platform with the most visible change from a user point of view. > >> > > > > OK. Win64 is enough for this patch. I wouldn't care about others, because > > I > > even don't know the names. > > > > > >>> I'm not so sure about size_t string length. > >>> > >> > >> It is hardly imaginable to release php 6 with strings length still > >> using integer. The memory consumption has been shown to be minimal > during > >> the discussions about the 64bit support. Or did I miss some important > >> new information? > >> > > > > I wouldn't mix size_t string length with 64-bit support. These are two > > independent changes. int64 would make 64-bit PHP version behave more or > > less consistent with minimal cost. > > > > size_t string length will increase memory consumption and memory traffic > > for the cases that no one web application will use (2GB strings). I'm > > trying to save (or even improve) memory consumption, because I know how > it > > may affect performance because of CPU cache misses. > > > just two cents about the size_t part. > > The possible memory increase on 64 bit is unproportional to the increase > of the available memory on the 64 bit system itself. While it's less then > 4bg on 32 bit systems, it's usually at least 8gb or more on a 64 bit > system (otherwise there were no reasons to use a 64 bit machine IMHO). So > from this POV it's almost uncritical. Furthermore, the big part of that > will be going on the image size, not on the heap (on linux zval didn't > increase). > > Regarding the possible performance issue you mentioned - yes, it can be as > well, but not worse as it is. However as discussed before, the usage of > the mem types like size_t and ptrdiff_t is mentioned by CPU manufacturers > as a good thing to do as apart from cache it'll lead to more optimal > memory and registers usage. The same is about the other cases like usage > of right data types in the loops, security with the string lengths coming > as 64 bit int from the user space, pointer casts to int instead of > ptrdiff_t, etc. This topic was and is on the plate and was just defered to > the time the int64 patch were accepted. One can see what exactly the > bottle necks are using the tools from the CPU manufacturers like AMD and > Intel. That is definitely an outstanding task which were far in advance > now if the int64 patch were in 5.6 now. > > More on memory usage is that right now many memory structures can be > optimized for better alignment which would decrease their allocated sizes. > Of course that has to be revisited again in the new patches. But that > could free an amount of memory. > > IMHO it's much more important to do a clean start now with both patches > and drive them to the top. That's why we should have coordinated our works > on that which would save our efforts on merging it and allow a better > result from the start on. > > Best regards > > Anatol >