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),
]);
});
