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 <[email protected]>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
>