Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125633 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 312591A00BD for ; Thu, 19 Sep 2024 20:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726776912; bh=oEj6uFQ9si/5WEBNwxf4F8mrARcwT816rN0mA3e5BUM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PJD4egO/+g3+JHjQfSXwkRgykyi/qt3x1zOskdaTTcy9oVIw52q2ettOHXAtceeJ6 J97YlePdgYHoAq3ld4j/cGJo0PbmRVuMMn0PreIkZJBvcE8ab1eSqUWDNwrId7JrdX lp7JYGuSQL2dWq5+gltm8VLyX3/iJOjam2Y6qLy44uv51J35+k/S0+Ny46CQ4d+kMY bbuTaG/OuyNIKRoA1OFA/P8mxfo2zB8Y+jD2jxu/8QxHv5Ma9OYQs4fHiMAahZE7Fu zuhLHrROc73yFwOdTE+zE7mXrwc93Wy2VptR2K/NJ/DdRe82QkB5UUTPsU2zm/F1Tb JdK0g9jlYwi/g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 27DAC180032 for ; Thu, 19 Sep 2024 20:15:11 +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-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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:15:10 +0000 (UTC) Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-710da8668b3so659859a34.1 for ; Thu, 19 Sep 2024 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726776783; x=1727381583; 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=SJ5Qe8okh6fTC//GFqKbOZVbbizbn4VLW5imsDDZXa0=; b=EzKpkcep3/qoARZYvnseNRrAt9vYWu+0i/1JzOxiddpkU77D2dkCrGUBzbfy+2gB3y cZhPFnGIl72s9Gx0HqKHy0DAuwuNwg6tfPSXSim5UR93WBM9wjKOxh8T2rIl5VXY+cXY OdyPg9zAh1Go1/a5uy0AiOeGNSw5TGG5S4VbiPwqkmVXbP/Tc1g/u9FWS/67kX96pdM5 LV5yP8dYEkUOs4nsgB9kOXhf7XO9dy6GJzHzZe7+VRHgfN0/Tim8Z0K6OSeZLMMcH4iF DCEjiHccsqzhZKFQj1vF5WL0GRV01JoKBoc8nHDv2iq8eRfvvM2BqTgSh7Qpa3F2CLAW 3fnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726776783; x=1727381583; 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=SJ5Qe8okh6fTC//GFqKbOZVbbizbn4VLW5imsDDZXa0=; b=EB/Fi+Za+SEBiTbpVOTx4QVHVNVltuEbq5XBHjohJXc2MuftjL1td3dzrVpMjHM5Q/ YAclezQysU7ZFWOWn9PY5vEfDRX7LW1PnDGiKKD8NqzzhOHVgeHcn/aIE2XX7YQSX8zg paczLgfEied2aTpez/x+GzUOBoLaHE7ufVFRFNA5VcNqbhSbGM4lYj1WgUQAmQHXuLy0 if8cIXe69Yqmmhky27lduf/VXNUM45SrfHDLkbARFNyrxaMmVu4I4241fA5My9gLp0sn gT2+7VBKAD/YNPB6VnK2610qBiadJllyngrMysBEenDZrV23HPewwwgCsRgskbels7z9 WSRw== X-Forwarded-Encrypted: i=1; AJvYcCWYNzNU4Eosv2EBvjIyRTUzZfCowoEagYhJFboidn7/ChhIBItJdKzzqf73kBifIwYLhEtu1WgljgY=@lists.php.net X-Gm-Message-State: AOJu0Yw+aQCyeV0m9/5zUF2aMcQNOWxhNtHhs2z1sGeYtcJqjw4MZQFG zH12aLTH4FQU2uhTTaC1WTI7gCQRuH9JoMWA4vXEKQMFNEaoW6uL5KRACsGLvRhAN5eRgkou/8F /Lccj7X0AQcJ5tu3W5bu09I4pegE= X-Google-Smtp-Source: AGHT+IFrVSud+L411rJpbb+nKclmswcyNd1nHian9K/p47xSSjr579sXkckkreQdpihYCkmPrFaYzE+yy4xd/wx9Ook= X-Received: by 2002:a05:6830:6588:b0:710:ec5f:45b9 with SMTP id 46e09a7af769-713923caea2mr728269a34.13.1726776783454; Thu, 19 Sep 2024 13:13:03 -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:12:52 -0600 Message-ID: Subject: Re: [PHP-DEV] Zephir, and other tangents To: Mike Schinkel Cc: Adam Zielinski , PHP internals , Dennis Snell Content-Type: multipart/alternative; boundary="000000000000c8cadb06227e8c86" From: hamiegold@gmail.com (Hammed Ajao) --000000000000c8cadb06227e8c86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 18, 2024, 1:33=E2=80=AFp.m. Mike Schinkel = wrote: > > On Sep 18, 2024, at 3:09 PM, Hammed Ajao wrote: > > Yes and no. The primary goal of WebAssembly is to support > high-performance applications on web pages. The premise is simple: > JavaScript is the only language natively supported by browsers, but > developers want to use various other languages (e.g., C, C++, Rust), > particularly for performance-critical tasks. WebAssembly allows code > written in these languages to be compiled to a universal format (Wasm) th= at > browsers can run efficiently. > > Yeah. That was the original goal. > That is the primary goal. > But to say WASM's domain is limited to browsers is not valid any longer: > I don't know where you got that since I never said anything along those lines. All I did was try to explain to you why browsers need wasm and why it makes sense for them to invest in implementing it. But since you have all those guides and it's so practical, what's stopping you? You'd do a better job of convincing me with a MVP than some random blog posts. This is what we use for chrome/v8: https://github.com/WebAssembly/wasm-c-api/, have fun. - > https://www.webassembly.guide/webassembly-guide/webassembly/webassembly-i= n-the-server > - > https://blog.pixelfreestudio.com/how-to-implement-webassembly-in-server-s= ide-applications/ > - https://medium.com/wasm/webassembly-on-the-server-side-c584f874b4a3 > - https://www.secondstate.io/articles/why-webassembly-server/ > - > https://www.techtarget.com/searchitoperations/news/252527414/Server-side-= WebAssembly-prepares-for-takeoff-in-2023 > > And even: > > - https://docs.docker.com/desktop/wasm/ You mean the feature that's been in beta since 2022? Yeah that's exactly what I'm referring to. If docker and all their money and engineers haven't shipped wasm in 2 years, how long do you think it'll take a bunch of volunteers? > > > However, in the case of PHP, many of the benefits that WebAssembly > brings to other languages are already available through PHP extensions or > FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into > PHP would be a complex undertaking with significant risks, but it wouldn'= t > necessarily provide proportionate rewards, which is the main point I'm > trying to make. > > Many of the benefits, but NOT the most important one for a large number o= f > installations. > The benefit that neither FFI nor extensions can touch is the ability to b= e > run on a managed server. Without that, none of the other benefits of FFI > nor extensions even matter. Full stop. You can't do shit on a managed server, that is not the bar at all. What makes you so sure that wasm will be allowed on managed hosts? What's the incentive for providers to allow it? > > Extensions, which are already implemented in lower-level languages like > C or C++, would still need to be compiled to WebAssembly if the goal were > full compatibility. This might lead us down the path of either creating a > domain-specific language (DSL) for PHP=E2=80=94similar to AssemblyScript= =E2=80=94or simply > leaving it up to the library authors to choose lower-level languages (as = is > currently the case). > > > > In essence, WebAssembly is great for certain scenarios, but PHP has > existing mechanisms that make the addition of a Wasm runtime potentially > redundant for most use cases. > > Partial redundancy is not redundancy. > > WASM's ability to run on a managed server =E2=80=93 assuming it were buil= t-in to > PHP core =E2=80=94 is the critical non-redundant benefit. If you cannot r= un those > "existing mechanisms" then they fact they are redundant does not matter o= ne > iota. > I hear you, you want to run low level code on managed servers. I would approach the problem differently e.g. Creating some kind of directory for `trusted` php extensions, the criteria for what qualifies as `trusted` would be up for discussion. Or maybe we can bundle a small std lib of select extensions with core. Those make a lot more sense to me than adding an entire abstraction layer. Cheers. Hammed. --000000000000c8cadb06227e8c86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



But since you have all those guides and it's so practical= , what's stopping you? You'd do a better job of convincing me with = a MVP than some random blog posts. This is what we use for chrome/v8:=C2=A0= ht= tps://github.com/WebAssembly/wasm-c-api/, have fun.


You mean the feature that's been in beta since 2022= ? Yeah that's exactly what I'm referring to. If docker and all thei= r money and engineers haven't shipped wasm in 2 years, how long do you = think it'll take a bunch of volunteers?



> However, in the case of PHP, many of the benefits that WebAssembly bri= ngs to other languages are already available through PHP extensions or FFI = for non-performance-sensitive tasks. Integrating a Wasm runtime into PHP wo= uld be a complex undertaking with significant risks, but it wouldn't ne= cessarily provide proportionate rewards, which is the main point I'm tr= ying to make.

Many of the benefits, but NOT the most important one for a large number of = installations.

The benefit that neither FFI nor extensions can touch is the ability to be = run on a managed server.=C2=A0 Without that, none of the other benefits of = FFI nor extensions even matter.=C2=A0 Full stop.
<= /blockquote>
=C2=A0=C2=A0
Yo= u can't do shit on a managed server, that is not the bar at all. What m= akes you so sure that wasm will be allowed on managed hosts? What's the= incentive for providers to allow it?


> Extensions, which are already implemented in lower-level languages lik= e C or C++, would still need to be compiled to WebAssembly if the goal were= full compatibility. This might lead us down the path of either creating a = domain-specific language (DSL) for PHP=E2=80=94similar to AssemblyScript=E2= =80=94or simply leaving it up to the library authors to choose lower-level = languages (as is currently the case).
>
> In essence, WebAssembly is great for certain scenarios, but PHP has ex= isting mechanisms that make the addition of a Wasm runtime potentially redu= ndant for most use cases.

Partial redundancy is not redundancy.


WASM's ability to run on a managed server =E2=80=93 assuming it were bu= ilt-in to PHP core =E2=80=94 is the critical non-redundant benefit. If you = cannot run those "existing mechanisms" then they fact they are re= dundant does not matter one iota.

I hea= r you, you want to run low level code on managed servers. I would approach = the problem differently e.g. Creating some kind of directory for `trusted` = php extensions, the criteria for what qualifies as `trusted` would be up fo= r discussion. Or maybe we can bundle a small std lib of select extensions w= ith core. Those make a lot more sense to me than adding an entire abstracti= on layer.

Cheers.
Hammed.
--000000000000c8cadb06227e8c86--