int64 proposal is still in draft for very long time.
Do you provide support for all other unrelated proposals when you offer
your own?
Lets think how to integrate them. I propose doing it in two steps
(measuring the performance and memory consumption difference).
If the degradation is going to be invisible, I won't object.
Thanks. Dmitry.
On Tue, May 6, 2014 at 9:43 AM, Pierre Joye <[email protected]> wrote:
> On Tue, May 6, 2014 at 7:27 AM, Dmitry Stogov <[email protected]> wrote:
>
> > I really, don't see a lot of sense in using ZTS and didn't like to spend
> our
> > time.
>
> Well, it is not a taste matter and we all have to take care of issues
> on platforms/sapis we do not use daily.
>
> >> >> Also one thing is totally missing, and is also caused by something
> >> >> that becomes a common case, the 64bit support as it should be has
> been
> >> >> totally ignored. That makes Anatol work to keep the 64bit branch
> >> >> almost useless. My take on it is that we should either:
> >> >>
> >> >>
> >> >> - move your patch to this branch and then merge to master
> >> >> - merge the 64bit branche then this patch
> >> >
> >> >
> >> > I afraid both ways aren't going to be simple.
> >>
> >> Rght, but again, I really do not feel comfortable to ask Anatal or my
> >> team to redo all the work. This would be very bad.
> >
> >
> > I see your point. Please, look from mine.
> > Just compare the sizes of diffs between branches.
> > We won't be able to care about unstable development branches...
>
> It is stable as far as we can tell and has been working constantly
> since we proposed it. Tests results are public and very positive.
> Thing is that every individual here is not alone on working on php,
> care has to be taken.
>
> > We may help, with reimplementation of int64 patch, but actually we come
> to
> > ask help ourselves.
> > I hope we will found some compromise. It can't be a problem if our goals
> are
> > not opposite :)
>
> We have the same goals :) While performance is a lower priority to me
> than clean code and maintainability in the long run. But both
> performance and ease of maintainability can be achieved together.
>
> >> > 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.
>
> Err, even Linux has a not so good 64bit implementation. We rely on
> single compiler behavior and 20 years old types described by many
> leading developers as hacks. PHP is one of the only OSS projects I
> know still relying on these types or using int for buffer size. I am
> not willing to tell you what you should care about but this is
> definitively an area that deserves more attention.
>
> >> > 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.
>
> There are part of the same changeset. They are even deeply related.
>
> >
> > 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.
> >
> > Lets apply the first part first.
>
> I have to disagree here, the patch contains both changes and will be
> proposed together. I do not see an appealing reason to split them for
> a minimal gain from a memory usage point of view. The importance and
> gains brought by these changes are too important. The "new" RFC and
> patch are ready, it will be proposed soonish. If accepted, let see
> what is the best way to make your patches work with it, we can help
> here with the moves anyway :)
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>