「WebAssembly」タグの記事が15件件あります

JavaScript Promise Integration (JSPI) APIは、外部機能への_同期的_なアクセスを想定して書かれたWebAssemblyアプリケーションが、実際には_非同期的_に動作する環境でスムーズに操作できるようにします。

WebAssemblyのJavaScript Promise Integration (JSPI) APIに新しいAPIが登場しました。これはChromeリリースM126で利用可能です。変更点、Emscriptenでの使用方法、JSPIのロードマップについて説明します。

JSPIは、逐次処理APIを使用したWebAssemblyアプリケーションが、非同期のWeb APIにアクセスするためのAPIです。多くのWeb APIはJavaScriptのPromiseオブジェクトを基に作成されています。つまり、要求された操作を即座に実行する代わりに、それを実行するPromiseを返します。一方で、WebAssemblyにコンパイルされた多くのアプリケーションは、呼び出し元が完了するまでブロックするAPIが主流のC/C++の世界から来ています。

WebAssemblyのJavaScriptプロミス統合(JSPI) APIがChromiumリリースM123でオリジントライアルに入ります。これにより、あなたやユーザーがこの新しいAPIから受けるメリットをテストできます。

JSPIは、WebAssemblyにコンパイルされたいわゆる逐次コードが_非同期_なWeb APIにアクセスできるようにするAPIです。多くのWeb APIはJavaScriptのPromiseを使用して作成されています。そのため、操作をすぐに実行する代わりに、操作を実行するためのPromiseを返します。操作が最終的に実行されると、ブラウザのタスクランナーがそのPromiseに関連付けられたコールバックを呼び出します。JSPIはこのアーキテクチャにフックして、WebAssemblyアプリケーションがPromiseを返した時点で一旦中断され、Promiseが解決された時点で再開できるようにします。

速さが単なる特徴ではなく、生活の一部である刺激的なV8の世界へようこそ。2023年を締めくくるにあたり、今年達成したV8の印象的な成果を祝う時が来ました。

革新的なパフォーマンス最適化を通じて、V8はWebの進化し続ける景観において可能な限界を押し広げ続けています。今年は、新しい中間層コンパイラを導入し、上位層コンパイラのインフラストラクチャ、ランタイム、ガベージコレクタにいくつかの改善を実施しました。その結果、広範囲で大幅な速度向上が実現しました。

WebAssembly Garbage Collection (WasmGC)に関する最近の記事では、ガベージコレクション(GC)提案が、人気のあるGC言語をWasmでより良くサポートする方法について高いレベルで説明されています。このことでいかに重要であるかがわかります。この記事では、Java、Kotlin、Dart、Python、C#のようなGC言語をWasmに移植するための技術的な詳細に踏み込んでいきます。実際には2つの主なアプローチがあります:

V8 v11.2でWebAssemblyの尾部呼び出しをリリースします！この記事では、この提案の概要を簡単に説明し、EmscriptenでのC++コルーチンの興味深い使用例を示し、V8が尾部呼び出しを内部でどのように処理するかを紹介します。

尾部呼び出し最適化とは？​

ある呼び出しが現在の関数から戻る前に実行される最後の命令である場合、それは尾部位置にあると言われます。コンパイラは、そのような呼び出しを最適化して、呼び出し元のフレームを破棄し、呼び出しをジャンプに置き換えることができます。

これは特に再帰関数にとって有用です。例えば、次のC関数はリンクリストの要素の合計を計算します：

int sum(List* list, int acc) {
  if (list == nullptr) return acc;
  return sum(list->next, acc + list->val);
}

通常の呼び出しでは、これは𝒪(n)のスタック空間を消費します：リストの各要素が呼び出しスタックに新しいフレームを追加します。リストが十分に長い場合、スタックが非常に速くオーバーフローする可能性があります。呼び出しをジャンプに置き換えることにより、尾部呼び出し最適化はこの再帰関数を本質的に𝒪(1)スタック空間を使用するループに変換します：

V8には、WebAssemblyコードを機械コードにコンパイルして実行できる2つのコンパイラが存在します。それは__Liftoff__（ベースラインコンパイラ）と__TurboFan__（最適化コンパイラ）です。LiftoffはTurboFanよりも高速にコードを生成できるため、迅速な起動時間を実現します。一方、TurboFanはより高速なコードを生成できるため、高いピークパフォーマンスが可能になります。

はじめに​

ChromeとEmscriptenによる最近の作業により、WebAssemblyアプリケーションで最大4GBのメモリを使用できるようになりました。以前の制限は2GBでした。そもそも制限があるのは奇妙に思えるかもしれませんが（結局512MBや1GBのメモリ使用を許可するために特別な作業は必要ありませんでした）、実際には2GBから4GBにジャンプする際にはブラウザでもツールチェーンでも特別なことが発生します。この投稿ではそれについて説明します。

現在、.wasm ファイルを生成または操作するためのコンパイラやその他のツールが増えてきています。時には内部を調べたいと思うこともあるでしょう。ツールの開発者である場合や、Wasm を直接対象とするプログラマーであり、生成されたコードが性能やその他の理由でどのように見えるか気になる場合です。

Emscriptenは常に、ウェブやNode.jsのような他のJavaScript環境へのコンパイルを最優先にしてきました。しかし、WebAssemblyがJavaScriptなしで使用され始めると、新しいユースケースが登場し、それに合わせてEmscriptenのJSランタイムに依存しない単独のWasmファイルの生成をサポートするようになりました。この投稿では、その理由が興味深い点について説明します。