Hello community,
I am reaching out on behalf of the WasmLabs team at the Office of the CTO at VMware.
We have been working on building PHP for WebAssembly, specifically for the wasm32-wasi target. WASI [1] is a system interface that allows WebAssembly to run on the server side by safely being able to access operating system-like features, including files and filesystems, Berkeley sockets, clocks and random numbers [2].
WebAssembly in the server side is experiencing a big growth both in interest and users. There are other programming language interpreters that can be compiled to wasm32-wasi as of today; for example: Python [3] and Ruby [4].
We have patches for PHP 7.3.33 and 7.4.32 at the time of writing. Porting PHP 8.2.0 is work in progress at this time.
In the interest of getting feedback from the PHP community I am providing links to the patches at GitHub. Please, let us know what would be the next step to contribute and continue to maintain this work upstream. We look forward to work with the PHP community.
If you want to try it out, you can download the binaries we are producing in the CI/CD pipeline for 7.3.33 [5] and 7.4.32 [6]. You can use a WASI-enabled WebAssembly runtime such as Wasmtime [7] to run PHP compiled to wasm32-wasi.
Patches: 7.3.33 [8], 7.4.32 [9][10].
Example execution:
$ wasmtime -- --dir ~/php-example php-cgi-7.4.32.wasm ~/php-example/hello/index.php
X-Powered-By: PHP/7.4.32
Content-type: text/html; charset=UTF-8
Hello, world!
We have already presented some of this work at OSS conferences and events like Kubecon and Docker Community days, and have written a few articles providing the background to the port, its limitations and what can currently be accomplished (including running WordPress!). Please find below some links to the talks and articles:
- Porting PHP to WebAssembly using WASI [11]
- Running WordPress with WebAssembly using mod_wasm and Apache [12]
- WebAssembly: Docker without containers! [13]
- mod_wasm: Bringing WebAssembly to Apache [14]: this talk builds on top of PHP 7.3.33 and shows WordPress running with sqlite on top of Apache, thanks to an Apache module (mod_wasm) that is able to execute WebAssembly modules.
- Docker and WebAssembly, better together [15]: this presentation features PHP 7.4.32 and explains a bit of the context of this work.
Thank you,
Rafael Fernández López.
[1] https://wasi.dev/
[2] https://github.com/bytecodealliance/wasmtime/blob/03463458e426d4bd0601ebd82e95b668fc982443/docs/WASI-intro.md
[3] https://docs.python.org/3/whatsnew/3.11.html
[4] https://www.ruby-lang.org/en/news/2022/12/06/ruby-3-2-0-rc1-released/
[5] https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.3.33%2B20221124-2159d1c
[6] https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.4.32%2B20221124-2159d1c
[7] https://wasmtime.dev/
[8] https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/php/php-7.3.33/patches
[9] https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0001-Initial-port-of-7.3.33-patch-to-7.4.32.patch
[10] https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0002-Fix-mmap-issues.-Add-readme.patch
[11] https://wasmlabs.dev/articles/php-wasm32-wasi-port/
[12] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/
[13] https://wasmlabs.dev/articles/docker-without-containers/
[14] https://www.youtube.com/watch?v=jXe8kulUscQ
[15] https://youtu.be/yo30oF1Gflo?t=7361
HI Rafael,
I am happy to here that you guys are working on this. I once thought
of writing such a solution myself for PHP when I learnt it compiled c.
However, I could not manage time. I am positive it will be useful.
NVM< I don't know why Google has marked your email as spam. Likely,
that's why, you have not been responded as yet.
Best
Hello community,
I am reaching out on behalf of the WasmLabs team at the Office of the CTO at
VMware.We have been working on building PHP for WebAssembly, specifically for the
wasm32-wasi target. WASI [1] is a system interface that allows WebAssembly
to run on the server side by safely being able to access operating
system-like features, including files and filesystems, Berkeley sockets,
clocks and random numbers [2].WebAssembly in the server side is experiencing a big growth both in interest
and users. There are other programming language interpreters that can be
compiled to wasm32-wasi as of today; for example: Python [3] and Ruby [4].We have patches for PHP 7.3.33 and 7.4.32 at the time of writing. Porting
PHP 8.2.0 is work in progress at this time.In the interest of getting feedback from the PHP community I am providing
links to the patches at GitHub. Please, let us know what would be the next
step to contribute and continue to maintain this work upstream. We look
forward to work with the PHP community.If you want to try it out, you can download the binaries we are producing in
the CI/CD pipeline for 7.3.33 [5] and 7.4.32 [6]. You can use a WASI-enabled
WebAssembly runtime such as Wasmtime [7] to run PHP compiled to
wasm32-wasi.Patches: 7.3.33 [8], 7.4.32 [9][10].
Example execution:
$ wasmtime -- --dir ~/php-example php-cgi-7.4.32.wasm ~/php-example/hello/index.php X-Powered-By: PHP/7.4.32 Content-type: text/html; charset=UTF-8 Hello, world!We have already presented some of this work at OSS conferences and events
like Kubecon and Docker Community days, and have written a few articles
providing the background to the port, its limitations and what can currently
be accomplished (including running WordPress!). Please find below some links
to the talks and articles:
- Porting PHP to WebAssembly using WASI [11]
- Running WordPress with WebAssembly using mod_wasm and Apache [12]
- WebAssembly: Docker without containers! [13]
- mod_wasm: Bringing WebAssembly to Apache [14]: this talk builds on top of
PHP 7.3.33 and shows WordPress running with sqlite on top of Apache, thanks
to an Apache module (mod_wasm) that is able to execute WebAssembly modules.- Docker and WebAssembly, better together [15]: this presentation features
PHP 7.4.32 and explains a bit of the context of this work.Thank you,
Rafael Fernández López.[1] https://wasi.dev/
[2]
https://github.com/bytecodealliance/wasmtime/blob/03463458e426d4bd0601ebd82e95b668fc982443/docs/WASI-intro.md
[3] https://docs.python.org/3/whatsnew/3.11.html
[4] https://www.ruby-lang.org/en/news/2022/12/06/ruby-3-2-0-rc1-released/
[5]
https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.3.33%2B20221124-2159d1c
[6]
https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.4.32%2B20221124-2159d1c
[7] https://wasmtime.dev/
[8]
https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/php/php-7.3.33/patches
[9]
https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0001-Initial-port-of-7.3.33-patch-to-7.4.32.patch
[10]
https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0002-Fix-mmap-issues.-Add-readme.patch
[11] https://wasmlabs.dev/articles/php-wasm32-wasi-port/
[12] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/
[13] https://wasmlabs.dev/articles/docker-without-containers/
[14] https://www.youtube.com/watch?v=jXe8kulUscQ
[15] https://youtu.be/yo30oF1Gflo?t=7361
On Thu, 22 Dec 2022 at 16:04, Rafael Fernández López rfernandezl@vmware.com
wrote:
Hello community,
I am reaching out on behalf of the WasmLabs team at the Office of the CTO
at VMware.We have been working on building PHP for WebAssembly, specifically for the
wasm32-wasi target. WASI [1] is a system interface that allows WebAssembly
to run on the server side by safely being able to access operating
system-like features, including files and filesystems, Berkeley sockets,
clocks and random numbers [2].WebAssembly in the server side is experiencing a big growth both in
interest and users. There are other programming language interpreters that
can be compiled to wasm32-wasi as of today; for example: Python [3] and
Ruby [4].We have patches for PHP 7.3.33 and 7.4.32 at the time of writing. Porting
PHP 8.2.0 is work in progress at this time.In the interest of getting feedback from the PHP community I am providing
links to the patches at GitHub. Please, let us know what would be the next
step to contribute and continue to maintain this work upstream. We look
forward to work with the PHP community.If you want to try it out, you can download the binaries we are producing
in the CI/CD pipeline for 7.3.33 [5] and 7.4.32 [6]. You can use a
WASI-enabled WebAssembly runtime such as Wasmtime [7] to run PHP compiled
to wasm32-wasi.Patches: 7.3.33 [8], 7.4.32 [9][10].
Example execution:
$ wasmtime -- --dir ~/php-example php-cgi-7.4.32.wasm ~/php-example/hello/index.php X-Powered-By: PHP/7.4.32 Content-type: text/html; charset=UTF-8 Hello, world!We have already presented some of this work at OSS conferences and events
like Kubecon and Docker Community days, and have written a few articles
providing the background to the port, its limitations and what can
currently be accomplished (including running WordPress!). Please find below
some links to the talks and articles:
- Porting PHP to WebAssembly using WASI [11]
- Running WordPress with WebAssembly using mod_wasm and Apache [12]
- WebAssembly: Docker without containers! [13]
- mod_wasm: Bringing WebAssembly to Apache [14]: this talk builds on top
of PHP 7.3.33 and shows WordPress running with sqlite on top of Apache,
thanks to an Apache module (mod_wasm) that is able to execute WebAssembly
modules.- Docker and WebAssembly, better together [15]: this presentation features
PHP 7.4.32 and explains a bit of the context of this work.Thank you,
Rafael Fernández López.[1] https://wasi.dev/
[2]
https://github.com/bytecodealliance/wasmtime/blob/03463458e426d4bd0601ebd82e95b668fc982443/docs/WASI-intro.md
[3] https://docs.python.org/3/whatsnew/3.11.html
[4] https://www.ruby-lang.org/en/news/2022/12/06/ruby-3-2-0-rc1-released/
[5]
https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.3.33%2B20221124-2159d1c
[6]
https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.4.32%2B20221124-2159d1c
[7] https://wasmtime.dev/
[8]
https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/php/php-7.3.33/patches
[9]
https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0001-Initial-port-of-7.3.33-patch-to-7.4.32.patch
[10]
https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0002-Fix-mmap-issues.-Add-readme.patch
[11] https://wasmlabs.dev/articles/php-wasm32-wasi-port/
[12] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/
[13] https://wasmlabs.dev/articles/docker-without-containers/
[14] https://www.youtube.com/watch?v=jXe8kulUscQ
[15] https://youtu.be/yo30oF1Gflo?t=7361
Hello Rafael,
While this is impressive, this looks very similar to
https://github.com/seanmorris/php-wasm in that it compiles the whole
interpreter to WASM.
Something I personally find of rather limited utility, even more so when in
this iteration when the current interpreter already works server side.
Mainly because I don't really see what benefits this gives to the language.
Wouldn't this be just slower than executing the interpreter currently?
I spent some time a couple of months ago thinking about trying to actually
compile PHP code to WASM directly without compiling the whole
interpreter, be that either by only compiling the existing opcodes to WASM
or compiling directly from PHP to WASM. Now, this is clearly several
magnitudes harder as a problem to solved, but is one that seems to have
more benefits than just compiling the interpreter.
Having a lot of the standard library, actually written in PHP, would be a
big benefit here. And would make this project similar to RPython (what PyPy
uses to compile its Python subset into C).
The other issue is that I don't know of a way to run WASM binaries from PHP
at the moment, from a quick search and from what I remembered Tuleap [1]
achieved this by executing the WASM via Rust and using FFI to call the Rust
function from PHP, which looks extremely clunky and something that maybe
should be improved as an orthogonal project.
Best regards.
George P. Banyard
[1]
https://blog.tuleap.org/untrusted-code-execution-in-php-with-ffi-and-webassembly
Hi George!
Thanks for your feedback. Thanks for your patience as it took a bit long to answer, I have been out of office.
Your suggestion for compiling PHP code into WASM is an interesting, complementary approach that could be built independently of this one. While appealing, it will require significant efforts to design and implement, as you have described in your post.
Technically, the approach we chose boils down to adding support for another architecture to which the existing code of the PHP interpreter can be compiled to (such as x86 or Arm) with additional limitations regarding filesystem access, threading, etc. as Wasm standards evolve. Even with all the challenges, this is an approach that is well-defined and easy to understand and it is the one that other major languages such as Python and Ruby have taken to add Wasm support.
We are familiar with https://github.com/seanmorris/php-wasm and we used it in an early proof of concept for running WordPress in the browser ( https://wasmlabs.dev/articles/wordpress-in-the-browser/). This project is different from ours in that it targets browsers, where instead of using WASI, it leverages Emscripten and a JS engine to implement functionality. Our project is intended to run PHP in the server side without the need of a Javascript engine.
Server-side WASM+WASI gives us out-of-the box security as compared to running the PHP runtime directly. So, one can run PHP applications with more security guarantees than running PHP directly on top of a non-sandboxed environment, even in containerized environments.
This approach allows for easier reuse due to WASM’s portability. WASM runtimes are written to support an increasing number of platforms and not just server-side ones but also edge devices. Instead of having to compile the PHP interpreter for multiple triplets one can reuse the same PHP interpreter built for the wasm32-wasi target on any device with a WASM runtime. This way existing PHP applications can be moved to the edge in an even easier way.
Considering reusability, we think investing this effort with PHP is crucial because of the vast adoption of the language. As mentioned earlier, other scripting languages like Python and Ruby have already taken steps in this direction, so their interpreter can be built for the wasm32-wasi target.
Your concerns about performance are valid. However, WASM runtimes are working hard to reach near-native speeds with JIT and AOT optimizations. Thus, WASM performance is only bound to improve in the future. There is also work to be done in our own patch to support opcache, for example. At the end of the day, it all boils down to tradeoffs. This port does not interfere with running PHP in its current form in native environments but allows new scenarios and use cases for those that need it.
Please let us know if this answered some of the questions that you raised. We would also love to hear feedback about other potential use cases or still missing things on which we should focus from PHP developers point of view.
Thank you,
Rafael Fernandez López.
Hi George!
I'm deeply sorry about my previous answer. My email client did something extremely funky with it, I don't know why.
Thanks for your feedback. Thanks for your patience as it took a bit long to answer, I have been out of office.
Your suggestion for compiling PHP code into WASM is an interesting, complementary approach that could be built independently of this one. While appealing, it will require significant efforts to design and implement, as you have described in your post.
Technically, the approach we chose boils down to adding support for another architecture to which the existing code of the PHP interpreter can be compiled to (such as x86 or Arm) with additional limitations regarding filesystem access, threading, etc. as Wasm standards evolve. Even with all the challenges, this is an approach that is well-defined and easy to understand and it is the one that other major languages such as Python and Ruby have taken to add Wasm support.
We are familiar with https://github.com/seanmorris/php-wasm and we used it in an early proof of concept for running WordPress in the browser (https://wasmlabs.dev/articles/wordpress-in-the-browser/). This project is different from ours in that it targets browsers, where instead of using WASI, it leverages Emscripten and a JS engine to implement functionality. Our project is intended to run PHP in the server side without the need of a Javascript engine.
Server-side WASM+WASI gives us out-of-the box security as compared to running the PHP runtime directly. So, one can run PHP applications with more security guarantees than running PHP directly on top of a non-sandboxed environment, even in containerized environments.
This approach allows for easier reuse due to WASM’s portability. WASM runtimes are written to support an increasing number of platforms and not just server-side ones but also edge devices. Instead of having to compile the PHP interpreter for multiple triplets one can reuse the same PHP interpreter built for the wasm32-wasi target on any device with a WASM runtime. This way existing PHP applications can be moved to the edge in an even easier way.
Considering reusability, we think investing this effort with PHP is crucial because of the vast adoption of the language. As mentioned earlier, other scripting languages like Python and Ruby have already taken steps in this direction, so their interpreter can be built for the wasm32-wasi target.
Your concerns about performance are valid. However, WASM runtimes are working hard to reach near-native speeds with JIT and AOT optimizations. Thus, WASM performance is only bound to improve in the future. There is also work to be done in our own patch to support opcache, for example. At the end of the day, it all boils down to tradeoffs. This port does not interfere with running PHP in its current form in native environments but allows new scenarios and use cases for those that need it.
Please let us know if this answered some of the questions that you raised. We would also love to hear feedback about other potential use cases or still missing things on which we should focus from PHP developers point of view.
Thank you,
Rafael Fernandez López.