Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <e87c1621dfab638670b96f4c205bbef1.squirrel@webmail.klapt.com>
In-Reply-To: <52F2B748.4000402@hristov.com>
References: <e077612e6dd6e128cc0b8042db8d6b1c.squirrel@webmail.klapt.com>
    <52F0E8CF.7090501@hristov.com>
    <0681aaa573a34b3e07e246e7f88efbab.squirrel@webmail.klapt.com>
    <52F10D11.1090703@hristov.com>
    <647013700aff31d909f00714fde3c8d8.squirrel@webmail.klapt.com>
    <52F2B748.4000402@hristov.com>
Date: Thu, 6 Feb 2014 00:39:00 +0100
To: "Andrey Hristov" <php@hristov.com>
Cc: internals@lists.php.net
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] 64 bit RFC, #2 and #3 yes
From: anatol.php@belski.net ("Anatol Belski")

Hi Andrey,

On Wed, February 5, 2014 23:12, Andrey Hristov wrote:
> Anatol,
>
>
>>> There might be more, I gave a glance look at it. I'm curious to see
>>> how much memory real scripts will use with the branch.
>>>
>> In fact, while 64 bit programs take more memory that 32 bit ones, the
>> exact advantage of the 64 bit systems is that the amount of that memory
>> is bigger. So comparing a program on 32 bit system with 2G (without
>> extensions) and the same program on 64 bit system with 8G memory -
>> while the program size itself increases, the relative increase opposing
>> to the system memory is smaller. Significant memory increase is only to
>> expect when using huge amounts of data split into small pieces, say you
>> have millions of string buffers of 3 byte length - in that case it'll
>> need the same amount of pointers which are 4 vs 8 bytes big on 64 bit.
>> Stack
>> variables are of less importance for that.
>
> I meant on 64 bit vanilla PHP vs the branch
I've just took two checkouts I've got at hand (a lot of configure options,
same in each, debug builds), 5.5 and str_size_and_int64 on Linux and made
a simple comparsion. Running php -r 'while(true){usleep(300);}' and
summing private+shared on both. The memory increase is  less than 1%. On
windows the same is about 30% increase, but that's clear as there grows
everything - zval, int and string size. In fact, there's nothing to
compare with on Windows.

Of course, it'll be better to see with real apps. Just got no such tests
(and things like uprofiler or xdebug aren't ported yet). I mean, it might
take more in some cases, clear, but not something completely excessive. As
function arguments go on stack (usually) and are freed after the function
call. Or even they might be stored in registers, that were the same. In
the worst case, if compiler decides to put some of them into the data or
bss section, it will affect the size of the image itself.

That's where we probably will need to pay more attention for
optimizations.  In this context an interesting question were to compare
the 5.x branches by how they increase in memory usage, to say that or
other increase were acceptable.

Andrey, please continue your review. If you think some place is converted
inappropriately, so let's improve it if it. There will be anyway some time
needed for the fine tuning.

Thanks

Anatol