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