Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125625 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 CAE5B1A00BD for ; Wed, 18 Sep 2024 19:09:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726686718; bh=G57UH3I7r+WpBnowHZU5Edy53pIW7SW2Wi+yUk09jzw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ui3GVEO9odrSskqD7g+son0RzUrqorFLwUBjp3ZevCDvaGJyqwd57UlEK4UerA5xI 2tfmFebMzRZJeiCAZ1D4sBGdFy1SECJOniU1f7/9xvin1OEtOHdcZAnNRvTISxdxnm OXaaA2j/9HEpd6NDISF6HYNi0Y4K4l86HFWzJ+iw9SmdFzNk9W+qIOlE1jXRAWsRk5 B4aWDZFVdWDSmamFkGZ5lmktSpHlDtUcY4nenWk5IteXLJr8AeDXDMLrtwVMbbRveV AMPjChxKDMj2o1tYT49uWiMrZVwDClOQRWpUexuVroKMcVurA7OHdlkWs2yBmvW30X Q8HkgKIxGhHwQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7DC95180042 for ; Wed, 18 Sep 2024 19:11:57 +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-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 ; Wed, 18 Sep 2024 19:11:56 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-7093997dffdso24921a34.2 for ; Wed, 18 Sep 2024 12:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726686590; x=1727291390; 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=G57UH3I7r+WpBnowHZU5Edy53pIW7SW2Wi+yUk09jzw=; b=gBWjeypCVq4bThR4VSjCCEvWm3rB8xnopMnJKiDaNDGEc/MMjnHRl6yzPxPmQJf0lV 7t3PNDHNLV+roiiS3i3y1ZFZ0SAc3fGSj6TDhungh9NeBuKC8/9KFqhzMiQDwifMn9Rd 07SXtVOzSR59f6wm7a60sVn80hY3sodpSvjvMUjvlwHL/LGkZVMHQa/ebP8zuqLw/mJ2 MBBHUPDWr5E9eBmwdL+RqIMV8w9ZIwqup80Rz/tPzELZxPwKDcF2LPwp5LFk/nBQKhpf DoD/Cz9FEZuPukiEeOijWZ5cgjduGmedsZfS5hb0uPB/SM8/f7dTY+M5s5ZWEn+uBoRn qSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726686590; x=1727291390; 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=G57UH3I7r+WpBnowHZU5Edy53pIW7SW2Wi+yUk09jzw=; b=iN5+RrGALgQxePWnn+OGxbok+2AHDUOXlh6Dqx80I0viK4eE62QS/SiL2umgvFUtF5 XYqJtyG+CCwdMX1Jn+speQXQlDa3KGVLvXL9KPMjsOw/aUTcx9ToelPIcHsEPVsD5AjR mW3AEq+0p6K5VqAvg/fFcgpfysZDV9Pcab2qvs+oemIwmUtG//btSXMf0SR1K4Wk6EFJ icj5tWCbttXaMAw0quk3pOxQQFiVv/4RwPE4QN5dodcfH5CVKjcbrVthygZLm4Pq5I+j Vcgn3GIJf6sZ0T0E9ZlGEogRHmdD+8kT5BbT+V709SZQVpYckNIV36FDG078lTFMob5J Rmag== X-Forwarded-Encrypted: i=1; AJvYcCUCGyNt+H24kr034VRbZAxWWCxmlrCPj+i3CAhVCMfU3MnEcuytu3x7EN6injLRAwexZL7uCxZ2v0c=@lists.php.net X-Gm-Message-State: AOJu0YxIVC75AaHSMXGm4fPB2ah/QKvdsPzHw7jhyQMSyerQ5bvmNALF 4djKkDZnkTbPKKmBVukcM1XB3eRzazpeYxJblosEwogCiTKyz07L3awwAdGUJka2ielJf9DQRiF +Fp+85AYZH9jjejHSrjGHwDIR6/E= X-Google-Smtp-Source: AGHT+IF9IbPuTBgFefye/Dholh76fzk81pYRu385aO23X9x9UMsEliev71oZ4jXnaLItRD8ttci30kPEdjDScpuUC4Y= X-Received: by 2002:a05:6830:6d09:b0:710:f5bf:c4d8 with SMTP id 46e09a7af769-711094fc678mr13523168a34.3.1726686590247; Wed, 18 Sep 2024 12:09:50 -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: Wed, 18 Sep 2024 13:09:34 -0600 Message-ID: Subject: Re: [PHP-DEV] Zephir, and other tangents To: Adam Zielinski Cc: Mike Schinkel , PHP internals Content-Type: multipart/alternative; boundary="000000000000d9a9a40622698cf1" From: hamiegold@gmail.com (Hammed Ajao) --000000000000d9a9a40622698cf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 18, 2024, 5:16=E2=80=AFa.m. Adam Zielinski < adam.zielinski@automattic.com> wrote: > On Wed, Sep 18, 2024 at 2:39=E2=80=AFAM Hammed Ajao = wrote: > > > Running Wasm and PHP virtual machines together presents several > significant challenges and potential issues: > > =E2=80=A2 Memory Management and Isolation: Each VM has its own memory m= odel and > garbage collection strategy. Data passing between VMs often requires > expensive memory copying. Coordinating garbage collection can lead to > memory leaks or crashes if not handled properly. > > =E2=80=A2 Performance Impacts: Context switching between VMs introduces > overhead, especially with frequent interactions. Interoperability can > create latency due to data serialization and deserialization. > Synchronization issues may arise when one VM needs to wait for the other. > > =E2=80=A2 Security Concerns: Discrepancies between PHP's more permissiv= e > environment and Wasm's stricter sandboxing can create vulnerabilities. Th= e > communication layer between VMs could be exploited for cross-VM attacks i= f > not properly secured. > > =E2=80=A2 Debugging Complexities: Developers must use separate debuggin= g tools > for each VM. Stack traces spanning two execution contexts can be confusin= g > and hard to interpret. > > =E2=80=A2 Compatibility and Maintenance: Independent evolution of PHP a= nd Wasm > VMs may introduce breaking changes, requiring constant updates to the > integration layer. API changes in either environment necessitate > adjustments in the integration code. > > =E2=80=A2 Resource Consumption: Running two VMs simultaneously increase= s CPU and > memory usage. Longer initialization times may impact applications requiri= ng > quick boot times. > > =E2=80=A2 API and Communication Design: Designing efficient and secure = APIs for > inter-VM communication is critical but challenging. Marshaling data betwe= en > PHP and Wasm adds complexity, especially when different programming > languages are involved. > > > > While these are definitely challenges, aren't they largely the same > for most languages intending to support WebAssembly? > > =E2=80=93 Adam > 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) that browsers can run efficiently. 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. 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. Best, Hammed > --000000000000d9a9a40622698cf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 18, 2024, 5:16=E2=80=AFa.m. Adam Zielinski= <adam.zielinski@automattic.com> wrote:
On Wed, Sep 18, 2024 at 2:39=E2=80=AFAM Hammed Aj= ao <hamiegold@gmail.com> wrote:

> Running Wasm and PHP virtual machines together presents several signif= icant challenges and potential issues:
> =E2=80=A2 Memory Management and Isolation: Each VM has its own memory = model and garbage collection strategy. Data passing between VMs often requi= res expensive memory copying. Coordinating garbage collection can lead to m= emory leaks or crashes if not handled properly.
> =E2=80=A2 Performance Impacts: Context switching between VMs introduce= s overhead, especially with frequent interactions. Interoperability can cre= ate latency due to data serialization and deserialization. Synchronization = issues may arise when one VM needs to wait for the other.
> =E2=80=A2 Security Concerns: Discrepancies between PHP's more perm= issive environment and Wasm's stricter sandboxing can create vulnerabil= ities. The communication layer between VMs could be exploited for cross-VM = attacks if not properly secured.
> =E2=80=A2 Debugging Complexities: Developers must use separate debuggi= ng tools for each VM. Stack traces spanning two execution contexts can be c= onfusing and hard to interpret.
> =E2=80=A2 Compatibility and Maintenance: Independent evolution of PHP = and Wasm VMs may introduce breaking changes, requiring constant updates to = the integration layer. API changes in either environment necessitate adjust= ments in the integration code.
> =E2=80=A2 Resource Consumption: Running two VMs simultaneously increas= es CPU and memory usage. Longer initialization times may impact application= s requiring quick boot times.
> =E2=80=A2 API and Communication Design: Designing efficient and secure= APIs for inter-VM communication is critical but challenging. Marshaling da= ta between PHP and Wasm adds complexity, especially when different programm= ing languages are involved.
>

While these are definitely challenges, aren't they largely the same
for most languages intending to support WebAssembly?

=E2=80=93 Adam

Yes and no. The primary goal of WebAssembly= is to support high-performance applications on web pages. The premise is s= imple: JavaScript is the only language natively supported by browsers, but = developers want to use various other languages (e.g., C, C++, Rust), partic= ularly for performance-critical tasks. WebAssembly allows code written in t= hese languages to be compiled to a universal format (Wasm) that browsers ca= n run efficiently.

Howev= er, in the case of PHP, many of the benefits that WebAssembly brings to oth= er languages are already available through PHP extensions or FFI for non-pe= rformance-sensitive tasks. Integrating a Wasm runtime into PHP would be a c= omplex undertaking with significant risks, but it wouldn't necessarily = provide proportionate rewards, which is the main point I'm trying to ma= ke.
=C2=A0
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. Th= is might lead us down the path of either creating a domain-specific languag= e (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 curren= tly the case).

In essenc= e, WebAssembly is great for certain scenarios, but PHP has existing mechani= sms that make the addition of a Wasm runtime potentially redundant for most= use cases.=C2=A0

Best,<= /div>
Hammed
--000000000000d9a9a40622698cf1--