FAQ
hi,

So here are the first numbers:


  peak mem usage:

Wordpress master: 24.33Mb
Wordpress str_size_and_int64: 25.72Mb
delta 5.4%

Symfony master: 26.59Mb
Symfony str_size_and_int64: 27.19Mb
delta 2.2%

Drupal master: 23.46MB
Drupal str_size_and_int64: 24.60Mb
delta 4.63%

There is indeed more memory used but it is less than one could expect
and very acceptable given the benefits provided by the patch.

Also we may see more gains if class/variable/etc names use int32
instead of size_t, as Stas pointed out it makes little sense in this
case and the implementation is much safer than any other areas in the
core (or other extensions).

I feel confident that we can even get better results with phpng, once
we get the time to actually merge the 64bit patch and do further
analyzes while stabilizing phpng.

I have to ask anyone to actually look at these numbers and the
benefits (see the other thread "on memory usage with the 64bit patch,
and interpretation of various numbers").

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org

Search Discussions

  • Dmitry Stogov at May 15, 2014 at 6:09 am

    On Thu, May 15, 2014 at 3:33 AM, Pierre Joye wrote:

    hi,

    So here are the first numbers:


    peak mem usage:

    Wordpress master: 24.33Mb
    Wordpress str_size_and_int64: 25.72Mb
    delta 5.4%

    Symfony master: 26.59Mb
    Symfony str_size_and_int64: 27.19Mb
    delta 2.2%

    Drupal master: 23.46MB
    Drupal str_size_and_int64: 24.60Mb
    delta 4.63%

    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.

    Also we may see more gains if class/variable/etc names use int32
    instead of size_t, as Stas pointed out it makes little sense in this
    case and the implementation is much safer than any other areas in the
    core (or other extensions).
    Read "more gain" as "less degradation".

    I feel confident that we can even get better results with phpng, once
    we get the time to actually merge the 64bit patch and do further
    analyzes while stabilizing phpng.
    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.

    I have to ask anyone to actually look at these numbers and the
    benefits (see the other thread "on memory usage with the 64bit patch,
    and interpretation of various numbers").

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at May 15, 2014 at 6:21 am

    On Thu, May 15, 2014 at 8:09 AM, Dmitry Stogov wrote:
    On Thu, May 15, 2014 at 3:33 AM, Pierre Joye wrote:

    hi,

    So here are the first numbers:


    peak mem usage:

    Wordpress master: 24.33Mb
    Wordpress str_size_and_int64: 25.72Mb
    delta 5.4%

    Symfony master: 26.59Mb
    Symfony str_size_and_int64: 27.19Mb
    delta 2.2%

    Drupal master: 23.46MB
    Drupal str_size_and_int64: 24.60Mb
    delta 4.63%

    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.

    Also we may see more gains if class/variable/etc names use int32
    instead of size_t, as Stas pointed out it makes little sense in this
    case and the implementation is much safer than any other areas in the
    core (or other extensions).

    Read "more gain" as "less degradation".
    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?
    I feel confident that we can even get better results with phpng, once
    we get the time to actually merge the 64bit patch and do further
    analyzes while stabilizing phpng.

    I wouldn't be so confident, before seeing the results.
    Which won't and can't be seen before phpng is somehow usable and
    testable. We are very far away from that.
    The relative memory consumption increase on phpng is going to be more
    significant.
    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
  • Dmitry Stogov at May 15, 2014 at 8:56 am

    On Thu, May 15, 2014 at 10:20 AM, Pierre Joye wrote:
    On Thu, May 15, 2014 at 8:09 AM, Dmitry Stogov wrote:

    On Thu, May 15, 2014 at 3:33 AM, Pierre Joye wrote:

    hi,

    So here are the first numbers:


    peak mem usage:

    Wordpress master: 24.33Mb
    Wordpress str_size_and_int64: 25.72Mb
    delta 5.4%

    Symfony master: 26.59Mb
    Symfony str_size_and_int64: 27.19Mb
    delta 2.2%

    Drupal master: 23.46MB
    Drupal str_size_and_int64: 24.60Mb
    delta 4.63%

    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.

    Also we may see more gains if class/variable/etc names use int32
    instead of size_t, as Stas pointed out it makes little sense in this
    case and the implementation is much safer than any other areas in the
    core (or other extensions).

    Read "more gain" as "less degradation".
    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?

    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.

    I feel confident that we can even get better results with phpng, once
    we get the time to actually merge the 64bit patch and do further
    analyzes while stabilizing phpng.

    I wouldn't be so confident, before seeing the results.
    Which won't and can't be seen before phpng is somehow usable and
    testable. We are very far away from that.
    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.

    The relative memory consumption increase on phpng is going to be more
    significant.
    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.
    +1MB per process is not insignificant taking in account the amount of CPU
    cache.

    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?
    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.

    Cheers,
    Pierre
  • Pierre Joye at May 15, 2014 at 9:45 am

    On Thu, May 15, 2014 at 10:56 AM, Dmitry Stogov wrote:

    +1MB per process is not insignificant taking in account the amount of CPU
    cache.
    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.
    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?

    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 :)
    Thanks, I meant you in the plural form btw :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Marc Bennewitz at May 15, 2014 at 6:51 pm

    On 15.05.2014 01:33, Pierre Joye wrote:
    hi,

    So here are the first numbers:


    peak mem usage:

    Wordpress master: 24.33Mb
    Wordpress str_size_and_int64: 25.72Mb
    delta 5.4%

    Symfony master: 26.59Mb
    Symfony str_size_and_int64: 27.19Mb
    delta 2.2%

    Drupal master: 23.46MB
    Drupal str_size_and_int64: 24.60Mb
    delta 4.63%
    Even 4% is very big if you provide a high performance web application.
    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.

    Also we may see more gains if class/variable/etc names use int32
    instead of size_t, as Stas pointed out it makes little sense in this
    case and the implementation is much safer than any other areas in the
    core (or other extensions).

    I feel confident that we can even get better results with phpng, once
    we get the time to actually merge the 64bit patch and do further
    analyzes while stabilizing phpng.

    I have to ask anyone to actually look at these numbers and the
    benefits (see the other thread "on memory usage with the 64bit patch,
    and interpretation of various numbers").
    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.
    Cheers,
  • Pierre Joye at May 15, 2014 at 8:35 pm

    On Thu, May 15, 2014 at 8:50 PM, Marc Bennewitz wrote:

    Even 4% is very big if you provide a high performance web application.
    4% memory increase? Not really.
    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.

    Also we may see more gains if class/variable/etc names use int32
    instead of size_t, as Stas pointed out it makes little sense in this
    case and the implementation is much safer than any other areas in the
    core (or other extensions).

    I feel confident that we can even get better results with phpng, once
    we get the time to actually merge the 64bit patch and do further
    analyzes while stabilizing phpng.

    I have to ask anyone to actually look at these numbers and the
    benefits (see the other thread "on memory usage with the 64bit patch,
    and interpretation of various numbers").

    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?
    Please see the links in the other thread, it is very well explained,
    much better that what I could do.
    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?
    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 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 ;)
    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.
    Same for class names which shouldn't be possible to be longer than 255.
    255 is not enough, but yes, we do not even need 2G :)


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ulf Wendel at May 15, 2014 at 9:12 pm

    Am 15.05.2014 01:33, schrieb Pierre Joye:
    There is indeed more memory used but it is less than one could expect
    and very acceptable given the benefits provided by the patch.
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 14, '14 at 11:33p
activeMay 15, '14 at 9:12p
posts8
users4
websitephp.net

People

Translate

site design / logo © 2018 Grokbase