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.
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.
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.
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.
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
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.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
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.
> > > 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/876Smallest ramnode.com http://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)
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.
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,
BenSmallest 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.072926998138428sWith OPCache
x32: mem: 4194304b, t: 0.01033878326416s
x64: mem: 4194304b, t: 0.0080580711364746sAs 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),
]);
});
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,
BenSmallest 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.072926998138428sWith OPCache
x32: mem: 4194304b, t: 0.01033878326416s
x64: mem: 4194304b, t: 0.0080580711364746sAs 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
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?
While new deployments trend toward 64-bit (e.g. AArch64), there's
definitely a long list of devices — particularly in legacy environments
— still running 32-bit systems. But realistically, how many of these
will ever upgrade to PHP 9? Probably very few. These systems often stay
locked to whatever version was originally shipped, and their vendors are
unlikely to invest in major version bumps.
- WebAssembly; I don't know how widespread the Memory64 proposal is yet.
We're using WebAssembly in the docs pages for runnable examples.
I don't know either. ChatGPT tells :
The Memory64 proposal was formally standardized (Phase 4) in
November 2024, backed by strong votes and endorsement from the WASM
Community Group.It's enabled by default in Firefox 134 and Chrome 133+, with
Safari still working on implementation.Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64
Toolchains including LLVM, Emscripten, Binaryen, WABT support
it; WASI‑SDK has patches in progress
And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
This seems to be for very niche projects in itself already and running
PHP within such is even more niche - if present at all (outside of
"because I can" reasons).
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.
Is int64_t (size of long long 8) available on all systems (like
WebAssembly)?
The downside here, please correct me if I'm wrong, is that this
increases complexity instead of reducing it for how much value?
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?While new deployments trend toward 64-bit (e.g. AArch64), there's definitely a long list of devices — particularly in legacy environments — still running 32-bit systems. But realistically, how many of these will ever upgrade to PHP 9? Probably very few. These systems often stay locked to whatever version was originally shipped, and their vendors are unlikely to invest in major version bumps.
- WebAssembly; I don't know how widespread the Memory64 proposal is yet.
We're using WebAssembly in the docs pages for runnable examples.I don't know either. ChatGPT tells :
The Memory64 proposal was formally standardized (Phase 4) in November 2024, backed by strong votes and endorsement from the WASM Community Group.
It's enabled by default in Firefox 134 and Chrome 133+, with Safari still working on implementation.
Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64
Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI‑SDK has patches in progress
And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
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.Is int64_t (size of long long 8) available on all systems (like WebAssembly)?
The downside here, please correct me if I'm wrong, is that this increases complexity instead of reducing it for how much value?
This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
3v4l.org use 32bit WASM php in production, see it for yourself at
https://3v4l.org/
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?While new deployments trend toward 64-bit (e.g. AArch64), there's definitely a long list of devices — particularly in legacy environments — still running 32-bit systems. But realistically, how many of these will ever upgrade to PHP 9? Probably very few. These systems often stay locked to whatever version was originally shipped, and their vendors are unlikely to invest in major version bumps.
- WebAssembly; I don't know how widespread the Memory64 proposal is yet.
We're using WebAssembly in the docs pages for runnable examples.I don't know either. ChatGPT tells :
The Memory64 proposal was formally standardized (Phase 4) in November 2024, backed by strong votes and endorsement from the WASM Community Group.
It's enabled by default in Firefox 134 and Chrome 133+, with Safari still working on implementation.
Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64
Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI‑SDK has patches in progress
And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
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.Is int64_t (size of long long 8) available on all systems (like WebAssembly)?
The downside here, please correct me if I'm wrong, is that this increases complexity instead of reducing it for how much value?
This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
3v4l.org use 32bit WASM php in production, see it for yourself at
https://3v4l.org/
You misunderstood my sentence as I haven't told something else. My
answer for the niche projects belongs to "... i.e. iSH (which emulates
x86-32 on iOS)."
About WebAssembly I wrote:
I don't know either. ChatGPT tells :
The Memory64 proposal was formally standardized (Phase 4) in November 2024, backed by strong votes and endorsement from the WASM Community Group.
It's enabled by default in Firefox 134 and Chrome 133+, with Safari still working on implementation.
Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64
Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI‑SDK has patches in progress