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