Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125634 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A7F751A00BD for ; Thu, 19 Sep 2024 20:41:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726778633; bh=CpdJfDhftZTWAk+hoVkueSD8WEc0pj175+X5F5ykCEE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GndhadyYvReSsx7wTEk6k2D5fsQNQClkrhiIqpLCKZf7zylhJHgkJHWXuRTtuyMyO 60rf+T4DV9uESv6Vy14h3mMJfruO+B3IZNKfpAzuEfV5bZzbFvG6pWdQ4j/9Wdt6xg alDepjfJ6xOX9jFZY7PaduDOYUldU7rHYESxHFP1HKMLMSSJPua8GYE12wMBVkdPxi h0fPdt0fqS9Oa4BouW/YDQc4QVJ92s3lujiy+qzanCzHBY3fHzmd3B5I4qxSoy1uDF rlzc5eehQg4Rr/mUcsHboY5XO4ZqjO0eMotp3gU4xrBFkhXYyCT7RV6VUGp5vXnWWh zkp5l6F2OZYZw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 93D71180042 for ; Thu, 19 Sep 2024 20:43:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 19 Sep 2024 20:43:52 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-710d9b33303so800947a34.3 for ; Thu, 19 Sep 2024 13:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726778505; x=1727383305; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CpdJfDhftZTWAk+hoVkueSD8WEc0pj175+X5F5ykCEE=; b=BBl09vAPwokXuaFlpN00l4PEyhzuK8zooXrCdBq1+T/u0E2hdBZY/+YE3iq5g2rvBO yA1PxF/+RUZq6HBC4BCc8zl2MlCqWg7VHDosQ7A0GVUnfwRhNAMwcCKT/S7Q8As5JD0V js38nYd9rPYC3WzTnJxyAwfL2kzbzT75PijC/B1U8Cj47vF5pIud60OR56V6IbNYX4sQ QRp99MaUsQ6eCTxy/JcUosiVZyd09oSBrxpkRhKe8Uqpvacl1QCcJZ0cCXFJoLgh8SJW FKZdJvYpnx38ETZTbwJtZ6vqwVM80FjYWIwHsWnT7bRn06d4XiwB6kGcQrmiNm/hfpyV LdPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726778505; x=1727383305; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CpdJfDhftZTWAk+hoVkueSD8WEc0pj175+X5F5ykCEE=; b=V9sifUEp67BYo9or1Wmb/qLnIhiky2PgpOflKzUUcWdBE4M+HJ3A9CB8d1OSXKQP1U 0CR6DtMB1p0Oiji3PpYZe5QnGLGIDxcHV+9pCfIFKpSTXrKoK59+9coeGYR0pS7D27m5 nvE0TvQIjjA9HSLVaO47lauC3vWGWhcKXP1HWSWIledbQJVfLuAX/P5rg+hbirog9K8w OWW/nbWXV0cqIrGx63VMTk8e4uKfQvBnoBCgNkXekRx8AO+fdvQGHxdy9ZojXFzAbAwA q0Vh1Pf6/voQYCTYXB3zxHSuLu2WReeB/FY9ib5fxG2XiH+uZMRBpl1eo30clt/FMQTH 2iGg== X-Forwarded-Encrypted: i=1; AJvYcCWoqIMG6UKWF1BMwuZJ6kU4jpxRXyhbqQIpagRrDSaxn9mhU1nJ0V5+/P35H8hUdA31kBp0naY7/ak=@lists.php.net X-Gm-Message-State: AOJu0YyA0So3cRVvLCF42lV8zC0ER5Uq7jTT8Y3nxKp6lL5FxeP+Ycwi C+I8sRVxFZFcDU+RXXHKf3UsraZwL1edltMkiEUATKrXtKX9nKmZjJFsCfPxC2kH2jdqqlzP81Z lEYX7v9c00ExLUXfoovde4eSxvRk= X-Google-Smtp-Source: AGHT+IGsfebKaBOJaFml7QBUS/MFBzV0PXdnMyQ+I+iYlUKez9+hA+BKvNlMNI7ff4gb6Gu4nYA+cmrnnU7LJVS3w34= X-Received: by 2002:a05:6830:381a:b0:710:e61c:7a4c with SMTP id 46e09a7af769-71393558282mr109294a34.29.1726778505047; Thu, 19 Sep 2024 13:41:45 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> In-Reply-To: Date: Thu, 19 Sep 2024 14:41:32 -0600 Message-ID: Subject: Re: [PHP-DEV] Zephir, and other tangents To: Dennis Snell Cc: Rob Landers , Adam Zielinski , Mike Schinkel , PHP internals Content-Type: multipart/alternative; boundary="0000000000006635b106227ef3a9" From: hamiegold@gmail.com (Hammed Ajao) --0000000000006635b106227ef3a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2024 at 8:30=E2=80=AFPM Dennis Snell wrote: > > On Sep 17, 2024, at 2:03 PM, Rob Landers wrote: > > > > On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote: > > > To summarize, I think PHP would benefit from: > > > > 1. Adding WASM for simple low-level extensibility that could run on > > shared hosts for things that are just not possible in PHP as described = a > > few paragraphs prior, and where we could enhance functionality over tim= e, > > > > 2. Constantly improving PHP the language, which is what you are solely > > advocating for over extensibility, > Hi Mike, > > I=E2=80=99m Adam, I'm building WordPress Playground [1] =E2=80=93 it's Wo= rdPress running > in the browser via a WebAssembly PHP build [2]. I'm excited to see this > discussion and wanted to offer my perspective. > > WebAssembly support in PHP core would be a huge security and productivity > improvement for the PHP and WordPress communities. > > > To summarize, I think PHP would benefit from: > > > > 1. Adding WASM for simple low-level extensibility that could run on > > shared hosts for things that are just not possible in PHP as described = a > > few paragraphs prior, and where we could enhance functionality over tim= e, > > Exactly this! With WASM, WordPress would get access to fast, safe, and > battle-tested libraries. > > Today, we're recreating a lot of existing libraries just to be able to us= e > them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or a= n > HTTP client [7]. There are just no viable alternatives. Viable, as in > working on all webhosts, having stellar compliance with each format's > specification, supporting stream parsing, and having low footprint. For > example, the curl PHP extensions is brilliant, but it's unavailable on ma= ny > webhosts. > > With WebAssembly support, we could stop rewriting and start leaning on th= e > popular C, Rust, etc. libraries instead. Who knows, maybe we could even > polyfill the missing PHP extensions? > > > 2. Constantly improving PHP the language, which is what you are solely > > advocating for over extensibility, > > Just to add to that =E2=80=93 I think WASM support is important for PHP t= o stay > relevant. There's an exponential advantage to building a library once and > reusing it across the language boundaries. A lot of companies is invested > in PHP and that won't change in a day. However, lacking access to the WAS= M > ecosystem, I can easily imagine the ecosystem slowly gravitating towards > JavaScript, Python, Go, Rust, and other WASM-enabled languages. > > Security-wise, WebAssembly is Sandboxed and would enable safe processing > of untrusted files. Vulnerabilities like Zip slip [8] wouldn't affect a > sandboxed filesystem. Perhaps we could even create a secure enclave for > running composer packages and WordPress plugins without having to fully > trust them. > > Another use-case is code reuse between JavaScript and PHP. I'm sceptical > this could work with reasonable speed and resource consumption, but let's > assume for a moment there is a ultra low overhead JavaScript runtime in > WebAssembly. WordPress could have a consistent templating language. PHP > backend would render the website markup using the same templates and > libraries as the JavaScript frontend. Half the code would achieve the sam= e > task. > > Also, here's a few interesting "WASM in PHP" projects I found =E2=80=93 m= aybe they > would be helpful: > - WebAssembly runtime built in PHP (!) > https://github.com/jasperweyne/unwasm > - WebAssembly runtime as a PHP language extension: > https://github.com/veewee/ext-wasm > - WebAssembly runtime as a PHP language extension: > https://github.com/extism/php-sdk > > [1] https://github.com/WordPress/wordpress-playground/ > [2] > https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php= -wasm/compile > [3] https://developer.wordpress.org/reference/classes/wp_html_processor/ > [4] https://github.com/WordPress/wordpress-develop/pull/6713 > [5] > https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14a= eff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php > [6] https://github.com/WordPress/sqlite-database-integration/pull/157 > [7] > https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/= AsyncHttp/Client.php > [8] https://security.snyk.io/research/zip-slip-vulnerability > > -Adam > > > > Hey Adam, > > I actually went down something like this road for a bit when working at > Automattic. My repo even probably still exists in the graveyard repositor= y=E2=80=A6 > but I had plugins running in C# and Java over a couple of weeks. This was > long before wasm was a thing, and while cool, nobody really could think o= f > a use for it. > > It seems like you have a use for it though, and I=E2=80=99m reasonably ce= rtain you > could get it working over ffi in a few weeks; yet you mention hosts not > even having the curl extension installed, so I doubt that even if wasm ca= me > to be, it would be available on those hosts. > > > There are two major areas I have found that would benefit from having a > WASM runtime in PHP: > > Obviously, being able to run the same algorithms on the frontend and > backend is a huge win for consistency in applications. > I'm not convinced. That's what they said about nodejs(same algos and same language on FE and BE). Except it's not really that consistent because there are several discrepancies between the browser and node runtime. I'll believe it when I see it. > Particularly with text-related algorithms it=E2=80=99s really easy for > inconsistencies to develop due to the features available in each language= s > standard library, as well as due to differences in how each language > handles and processes string. > I can see the appeal of that though. > The other major area is similar, and we=E2=80=99ve seen this with the HTM= L and XML > parsing work recently undertaken in WordPress. > Yeah you could talk about html parsing before 8.4 but with 8.4 we get lexbor (thanks to niels) and that's as good as it gets. Php already has beautiful support for XML though so I'm not sure why you would implement a parser yourself. There are plenty of cases where efficient and spec-compliant operations are > valuable, but these kinds of things tend to cost significantly more in > user-space PHP. > Being able to jump into WASM, even with the overhead of exchanging that > data and running another VM, would very likely result in a noticeable net > improvement in runtime performance. > What exactly do you mean by jump into wasm? Like hand write it? Or you mean jump into a language that can be compiled to wasm? How about debugging at runtime? And if you mean better performance than PHP, while that is likely, it isn't guaranteed. PHP is pretty fast and will be faster for some routines that are optimized by the engine. Wasm will never be as fast as extensions though because with extensions, all you're doing is extending the engine. Same as any internal extension. With wasm you're interoperating with an entirely separate VM. Additionally, it=E2=80=99s a perk being able to write such algorithms in la= nguages > that aid that development through more powerful type systems. > We can agree on that. But I use C++ for my extensions so there's also that. There=E2=80=99s additional value in a number of other separate tasks. Conve= rting > images or generating thumbnails is a good example where raw performance i= s > less of a concern than being able to ensure that the image library is > available and not exposing the host system to risk. > Imo this is where FFI should shine but I'll admit that the current implementation is lacking in both security and functionality. I imagine plenty of =E2=80=9CPHP lite-extensions=E2=80=9D appearing in this= space because > it would give people the opportunity to experiment with features that are > impractical in user-space PHP before fully committing the language itself > to that interface or library. It would extend the reach of PHP=E2=80=99s = usability > because it would make possible for folks, who happen to be running on che= ap > shared hosts, to run more complicated processing tasks than are practical > today. While big software shops and SaaS vendors do and can run their own > custom PHP extensions, there=E2=80=99s not great way to share those gener= ally to > people without the same full control over their stack. > Shared hosting for php gets you the worst possible version of php. Can't recompile to enable any bundled extension, can't install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won't even be able to use? > > However, plugins basically work via hooks/filters. So as long as you > register the right listeners and handle serialization properly, you can > simply run a separate process for the plugin, or call a socket for =E2=80= =9Cremote=E2=80=9D > plugins. > > I don=E2=80=99t see anything stopping anyone from implementing that today= . > > =E2=80=94 Rob > > > I=E2=80=99m excited to see this conversation. I=E2=80=99ve wanted to prop= ose it a number > of times myself. > > Warmly, > Dennis Snell > I actually love wasm, I'm currently in the process of compiling my mini php runtime to wasm (basically a browser only version of 3v4l). I'm not against this for any personal reasons, I'm simply not sure it's the right approach. Cheers, Hammed --0000000000006635b106227ef3a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On= Tue, Sep 17, 2024 at 8:30=E2=80=AFPM Dennis Snell <dennis.snel= l@automattic.com> wrote:

On Sep 17, 2024, at 2:03 PM, Rob Landers <rob@bottled.codes> wro= te:



On Tue, Sep 17, 2024, at 14:57, Adam Zielins= ki wrote:
> To summarize, I think PHP would benefit from:
>
> 1. Adding WASM for simple low-level extensibility that could run = on
> shared hosts for things that are just not possible in PHP as desc= ribed a
> few paragraphs prior, and where we could enhance functionality ov= er time,
>
> 2. Constantly improving PHP the language, which is what you are s= olely
> advocating for over extensibility,
Hi Mike,

I=E2=80=99m Adam, I'm building WordPress Playground [1] =E2=80=93 = it's WordPress running in the browser via a WebAssembly PHP build [2]. = I'm excited to see this discussion and wanted to offer my perspective.<= br>

WebAssembly support in PHP core would be a huge security and productiv= ity improvement for the PHP and WordPress communities.

> To summarize, I think PHP would benefit from:
>
> 1. Adding WASM for simple low-level extensibility that could run = on
> shared hosts for things that are just not possible in PHP as desc= ribed a
> few paragraphs prior, and where we could enhance functionality ov= er time,

Exactly this! With WASM, WordPress would get access to fast, safe, and= battle-tested libraries.

Today, we're recreating a lot of existing libraries just to be abl= e to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6= ], or an HTTP client [7]. There are just no viable alternatives. Viable, as= in working on all webhosts, having stellar compliance with each format'= ;s specification, supporting stream parsing, and having low footprint. For = example, the curl PHP extensions is brilliant, but it's unavailable on = many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on= the popular C, Rust, etc. libraries instead. Who knows, maybe we could eve= n polyfill the missing PHP extensions?

> 2. Constantly improving PHP the language, which is what you are s= olely
> advocating for over extensibility,

Just to add to that =E2=80=93 I think WASM support is important for PH= P to stay relevant. There's an exponential advantage to building a libr= ary once and reusing it across the language boundaries. A lot of companies = is invested in PHP and that won't change in a day. However, lacking acc= ess to the WASM ecosystem, I can easily imagine the ecosystem slowly gravit= ating towards JavaScript, Python, Go, Rust, and other WASM-enabled language= s.

Security-wise, WebAssembly is Sandboxed and would enable safe processi= ng of untrusted files. Vulnerabilities like Zip slip [8] wouldn't affec= t a sandboxed filesystem. Perhaps we could even create a secure enclave for= running composer packages and WordPress plugins without having to fully tr= ust them.

Another use-case is code reuse between JavaScript and PHP. I'm sce= ptical this could work with reasonable speed and resource consumption, but = let's assume for a moment there is a ultra low overhead JavaScript runt= ime in WebAssembly. WordPress could have a consistent templating language. = PHP backend would render the website markup using the same templates and li= braries as the JavaScript frontend. Half the code would achieve the same ta= sk.

Also, here's a few interesting "WASM in PHP" projects I = found =E2=80=93 maybe they would be helpful:
- WebAssembly runtime built in PHP (!)=C2=A0h= ttps://github.com/jasperweyne/unwasm
- WebAssembly runtime as a PHP language extension:=C2=A0<= a href=3D"https://github.com/veewee/ext-wasm" rel=3D"noreferrer" target=3D"= _blank">https://github.com/veewee/ext-wasm
- WebAssembly runtime as a PHP language extension:=C2=A0<= a href=3D"https://github.com/extism/php-sdk" rel=3D"noreferrer" target=3D"_= blank">https://github.com/extism/php-sdk


-Adam



Hey Adam,

I actually went down something like this roa= d for a bit when working at Automattic. My repo even probably still exists = in the graveyard repository=E2=80=A6 but I had plugins running in C# and Ja= va over a couple of weeks. This was long before wasm was a thing, and while= cool, nobody really could think of a use for it.

It seems like you have a use for it though, = and I=E2=80=99m reasonably certain you could get it working over ffi in a f= ew weeks; yet you mention hosts not even having the curl extension installe= d, so I doubt that even if wasm came to be, it would be available on those = hosts.

There are two major areas I have found that would benefit from having = a WASM runtime in PHP:

Obviously, being able to run the same algorithms on the frontend and b= ackend is a huge win for consistency in applications.

I'm not convinced. That's what they s= aid about nodejs(same algos and same language on FE and BE). Except it'= s not really that consistent because there are several discrepancies betwee= n the browser and node runtime. I'll believe it when I see it.
=C2=A0
<= div>Particularly with text-related algorithms it=E2=80=99s really easy for = inconsistencies to develop due to the features available in each languages = standard library, as well as due to differences in how each language handle= s and processes string.

I= can see the appeal of that though.


The other major area is similar, and we=E2=80=99ve seen this with the = HTML and XML parsing work recently undertaken in WordPress.

Ye= ah you could talk about html parsing before 8.4 but with 8.4 we get lexbor = (thanks to niels) and that's as good as it gets. Php already has beauti= ful support for XML though so I'm not sure why you would implement a pa= rser yourself.

There are plenty of cases where efficient an= d spec-compliant operations are valuable, but these kinds of things tend to= cost significantly more in user-space PHP.
<= /div>
Being able to jump into WASM,= even with the overhead of exchanging that data and running another VM, wou= ld very likely result in a noticeable net improvement in runtime performanc= e.

What exactly do you mean by jump into wasm? Like hand write= it? Or you mean jump into a language that can be compiled to wasm? How abo= ut debugging at runtime? And if you mean better performance than PHP, while= that is likely, it isn't guaranteed. PHP is pretty fast and will be fa= ster for some routines that are optimized by the engine. Wasm will never be= as fast as extensions though because with extensions, all you're doing= is extending the engine. Same as any internal extension. With wasm you'= ;re interoperating with an entirely separate VM.
Additionally, it=E2=80=99s a perk being able to write suc= h algorithms in languages that aid that development through more powerful t= ype systems.

We can agree on that. But I use C++ for my extensions so ther= e's also that.

There=E2=80=99s additional value in a number of other sep= arate tasks. Converting images or generating thumbnails is a good example w= here raw performance is less of a concern than being able to ensure that th= e image library is available and not exposing the host system to risk.

Im= o this is where FFI should shine but I'll admit that the current implem= entation is lacking in both security and functionality.


I imagine plenty of =E2=80=9CPHP lite-extensions=E2=80=9D appearing in = this space because it would give people the opportunity to experiment with = features that are impractical in user-space PHP before fully committing the= language itself to that interface or library. It would extend the reach of= PHP=E2=80=99s usability because it would make possible for folks, who happ= en to be running on cheap shared hosts, to run more complicated processing = tasks than are practical today. While big software shops and SaaS vendors d= o and can run their own custom PHP extensions, there=E2=80=99s not great wa= y to share those generally to people without the same full control over the= ir stack.

Shared hosting for php gets you the worst possible version of ph= p. Can't recompile to enable any bundled extension, can't install a= ny new extensions, so how exactly would you approach this? Wasm bundled wit= h the engine by default? Or some kind of opt in mechanism that shared hoste= rs won't even be able to use?



However, plugins basically work via hooks/fi= lters. So as long as you register the right listeners and handle serializat= ion properly, you can simply run a separate process for the plugin, or call= a socket for =E2=80=9Cremote=E2=80=9D plugins.

I don=E2=80=99t see anything stopping anyone= from implementing that today.

=E2=80=94 Rob

I=E2=80=99m excited to see this conversation. I=E2=80=99v= e wanted to propose it a number of times myself.

Warmly,
Dennis Snell=C2=A0

= I actually love wasm, I'm currently in the process of compiling my mini= php runtime to wasm (basically a browser only version of 3v4l). I'm no= t against this for any personal reasons, I'm simply not sure it's t= he right approach.

Cheers,
Hammed
= --0000000000006635b106227ef3a9--