[PHP-INTERNALS] [rfc] 64bit usage, actual memory usage using real life apps

Read "more gain" as "less degradation".

I wouldn't be so confident, before seeing the results.
The relative memory consumption increase on phpng is going to be more
significant.

Thanks. Dmitry.

No, I mean more gain.

But it is nice to see that actual numbers are being ignored, we go
from your 8% to a medium increase to something closed to the "measures
margin errors" level, but heh, who cares?
Which won't and can't be seen before phpng is somehow usable and
testable. We are very far away from that.
With the risk to repeat myself, phpng is by far not ready. We have
proven that the impact of the 64bit patch is not significant, from a
memory and performance point of view. The memory results can be seen
here and in the other tests we published. The performance as well, and
we have to keep in mind that it performs equally or better with many
widely used applications.

Now, for what I understand, no matter what we do or provide, you guys
are going to refuse this patch, with absolutely no valid reason but an
hypothetical change that may be ready in a timely manner for php-next.
Given that it is in an acceptable state, both from a stability and API
point of view. This is definitively a bad thing and I am not sure that
will end well for php as a project or language. Or did I miss
something that could tell me that you may actually be more
cooperative?

Cheers,
Pierre

I used memory_get_peak_usage() for measurement. It doesn't provide any
measurement error.
It looks like you measured something else as the absolute numbers are
really different.

you may measure the speed and memory consumption difference between master
and pnphg.
we can't do it for your patch on top of phpng yet, because it's not ready.

+1MB per process is not insignificant taking in account the amount of CPU
cache.

I tried to be cooperative, and discussed this patch with you proposing
taking it into phpng part by part and proving that each part doesn't make
significant harm. You liked agreement for all at once even if it's not
implemented for phpng. Once I saw the memory overhead, I made my decision -
that it's not acceptable.

Anyway, I'll try to be more cooperative :)
but it doesn't mean that I'll take decisions that I don't like.

Thanks. Dmitry.

Alone the ICU update or some other libs will be more than that, just
to put things in relation. I still can't agree with the statement that
this little increment is not acceptable, even less given the very
early stage of phpng. It is also not correct, nor fair, to block this
long due patch because of that, knowing that phpng allows more
improvements.
Thanks, I meant you in the plural form btw :)

Cheers,

Pierre, I don't understand you in the following points:

You argument the size_t for string length is to use well defined C types
and that makes it more safe. But it is only an integer type that can
overflow in the same way any other integer can do. And as Nikita pointed
already the type exists to support ALL possible objects.
In which case it makes it more save?

Why you think the size_t type is more safe for string length but in the
case for class names it's ok to use a smaller type?

If it is so very important on some very very special applications a
compiler switch would be most logical way to go.

I often hear in this thread (and phpng) we do support string length up
to 2GB on 32bit systems already and therefore should increase it for
64bit system to the max possible value.
In my opition it's simply not true in practice because on 32Bit systems
your system can manage max. 2^32bytes and one PHP process isn't the only
process. I think the same argment exits on 64bit system.
So for me we should reduce the max. string length down as nobady can use
2GB strings in PHP regardless what integer type string length will be ;)

Same for class names which shouldn't be possible to be longer than 255.

4% memory increase? Not really.
Please see the links in the other thread, it is very well explained,
much better that what I could do.
Because we already have safety checks for string lengths etc. We also
already had issues related to this area. Take it as a compromise, but
still safe (while phpng may bring its lot of issues too, but that's
expected).

I do not care much about the 2G+ limit, as I said already multiple
times it is a side effect of this patch, not a goal.
255 is not enough, but yes, we do not even need 2G :)


Cheers,

After all the critique, and in all fairness, you certainly deserve a
praise for doing these tests!

As for the figures itself, 5% may not sound much but one shall keep in
mind that modern CPUs hate main memory accesses. Main memory has become
a severe bottleneck for these massive parallel number crunching
monsters. And, the trend seems clear.

Ulf