On 20.06.25 14:21, Hans Henrik Bergan wrote:
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_supportI 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/876Smallest 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), ]); });
X64 X32 % t: 0.005423069s 0.014256954s 262% mem: 1127808b 914064b 81% memReal: 4194304b 4194304b 100% peak: 1128696b 914888b 81% peakReal: 4194304b 4194304b 100%As you can see, the memory usage differences aren't that big but it's running much slower probably because of unavailable instruction sets on x32.
Tested on Ubuntu 22.04 with i7-1165G7
OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
