On Fri, 20 Jun 2025 at 13:20, Marc Bennewitz <marc@mabe.berlin> wrote:
>
>
> On 19.06.25 18:55, Hans Henrik Bergan wrote:
>
> On Thu, Jun 19, 2025, 18:24 Ben Ramsey <ram...@php.net> wrote:
>>
>> > On Jun 19, 2025, at 11:08, Calvin Buckley <cal...@cmpct.info> wrote:
>> >
>> > On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote:
>> >>
>> >> Hi,
>> >>
>> >> During the discussion about the year 2038 issue it turned out that maybe 
>> >> it's time to drop support for 32-bit of PHP completely.
>> >>
>> >> Based on that I have created an RFC to deprecate 32-bit build in 8.next 
>> >> and drop support for it in 9.
>> >>
>> >> RFC: https://wiki.php.net/rfc/drop_32bit_support
>> >
>> > I think the biggest arguments against this would be:
>> >
>> > - embedded systems; think of PHP in use for i.e. router web UIs. While I
>> > suspect a lot of these are going to be i.e. AArch64/RV64 in the future,
>> > there might be a long tail of existing systems. Of course, how many
>> > would upgrade to PHP 9?
>> >
>> > - WebAssembly; I don't know how widespread the Memory64 proposal is yet.
>> > We're using WebAssembly in the docs pages for runnable examples.
>> >
>> > And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
>> >
>> > The other options include making zend_long always 64-bit and accept the
>> > performance penalty for 32-bit, or making 32-bit best-effort rather than
>> > providing any guarantees.
>>
>>
>> Last night, I was giving some thought to reviving Andrea’s Big Integer 
>> RFC[^1]. This is something I’ve wanted for a long time (especially for my 
>> ramsey/uuid library, among other things).
>>
>> Andrea had a work-in-progress PR[^2]. I’m not sure the current state of it. 
>> It’s from 2014 and was originally written for phpng. I had planned to start 
>> teasing out bits of it into a new branch based on the current master branch 
>> to see how far I could get with it. I wouldn’t mind some help with that, if 
>> anyone’s interested. :-)
>>
>> If we are able to finish what Andrea started, then we would not need to drop 
>> support for 32bit builds.
>>
>> Cheers,
>> Ben
>>
>>
>> [^1]: https://wiki.php.net/rfc/bigint
>> [^2]: https://github.com/php/php-src/pull/876
>
>
>
>
> Smallest ramnode.com VPS has 512MB ram. I would run 32bit PHP on a 512mb ram 
> VPS. I'm not longer a ramnode customer, but I used to be.
> I for one would be sad to see 32bit PHP go.
>
> I have done a quick test on current master with Symfony :
>
> Without OPCache
> x32: mem: 16777216b, t: 0.15017914772034s
> x64: mem: 23068672b, t: 0.072926998138428s
>
> With OPCache
> x32: mem: 4194304b, t: 0.01033878326416s
> x64: mem: 4194304b, t: 0.0080580711364746s
>
> As you can see, with opcache enabled it's taking the same amount of memory. 
> (I don't know why ... did mostly the same setup as the configure-x32 GH 
> action)
>

the php memory allocator allocate large chunks from the OS, checking
the OS-allocated memory doesn't tell the whole story,
it's possible that the actual usage memory between 32/64 non-OPCache was minor,
can you try:

register_shutdown_function(function () {
    var_dump([
        "memory_get_usage(real_usage:false)" =>
memory_get_usage(real_usage: false),
        "memory_get_usage(real_usage:true)" =>
memory_get_usage(real_usage: true),
        "memory_get_peak_usage(real_usage:false)" =>
memory_get_peak_usage(real_usage: false),
        "memory_get_peak_usage(real_usage:true)" =>
memory_get_peak_usage(real_usage: true),
    ]);
});

Reply via email to