Design: pThreads任意のETA？

次の数四半期のある時期は、おそらく誰もが言うことができるほど正確です。 ただし、問題を提出するために問題トラッカーを予約してください。

このプロジェクトにはメーリングリストやその他のフォーラムがないため、問題追跡システムは、設計プロセスについて質問できる唯一の場所です。 人々が質問できる場所があることは価値があるので、私は人々が質問をするために問題追跡システムを使い続けることを勧めます。

@sunfishcode 、十分に公平ですが、そのようなリストを作成することをお勧めします。 課題追跡システムがその代わりになるとは思いません。

w3公開リストがあります。 ただし、トラフィックはそれほど多くありません。 私が信じているIRCもありますか？ ある時点でウェブサイトに掲載されていたと思いますが、ウェブサイトのコミュニティセクションで両方が直接リンクされていればいいのですが。 私は問題を開きますが、あなたが誰もが一般にリンクされていることを「公開」することを好む方法がわかりません

ここでの手順：

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

私たちは人々にgithubを使うように指導してきました。 誰もがそれを好きというわけではありませんが、多くの場所よりも1つの場所にある方が良いです。

こんにちは@ rossberg-chromiumそしてタイムリーな回答に感謝します。

ただし、問題を提出するために問題トラッカーを予約してください。

@jfbastienが指摘したように、標準的な方法でそれを行うのに最適な場所のように思われるので、ここで尋ねました。
さらに、スレッドのサポートは、webAssemblyの成功または失敗となる設計機能です。
ロゴのコンテキストや「Javaに実装されていないのはなぜですか」よりも、問題として提起されていると思います。

私が間違っている場合は、共有メモリ/スレッドの実装に従う場所を教えてください。
それはオープンなプロセスでなければならないので、私は言いたいです。

--R

@RobertoMalatestaスレッドは非常に重要であることに同意しますが、WebAssemblyの最小限の実行可能な製品にスレッドを詰め込むよりも、スレッドを正しくすることが重要でした。 私たちの推論は単純です：asm.jsはこの機能なしで成功を収めています。

スレッドは、いくつかの重要なアプリケーションにとって間違いなくメイクまたはブレイク機能ですが、すべてのアプリケーションに適しているわけではありません。 GC、ゼロコストの例外処理、保証された末尾呼び出しなどについても同じことが言えます。

MVPを選択するということは、最初の立ち上げ時に全員を満足させるわけではないことを意味します。 また、すべてを設計、仕様化、実装する前に、WebAssemblyを使用する人もいることを意味します。

そうは言っても、私たちは多かれ少なかれJavaScriptSharedArrayBufferアプローチをWebAssemblyに採用することを期待しています。 私たちの多くは、最初からその仕様に関与してきました。 これにより、C ++に似た低レベルの機能に加えて、futexのようなAPIが追加されます。 逐次一貫性よりも多くのメモリ順序で成長する余地があります。 そのための正式なメモリモデルを作成するための進行中の作業があります。

SABはTC39の「ステージ4」にあります。つまり、SABは完了し、出荷の準備ができており、使用する準備ができています。 WebAssemblyに採用するのはそれほど難しくないと思います。

@jfbastien洞察に満ちた情報をありがとう。

そうは言っても、私たちは多かれ少なかれJavaScriptSharedArrayBufferアプローチをWebAssemblyに採用することを期待しています。（...）
SABはTC39の「ステージ4」にあります。つまり、SABは完了し、出荷の準備ができており、使用する準備ができています。 WebAssemblyに採用するのはそれほど難しくないと思います。

すごい。 私は、単にスレッド化に飢えている多くのC ++コードでそれをキックタイアしたいと思っています。
私は定期的にWebWorkersをTS / JSアプリケーションに使用しており、私はそれらのファンではないと言わせてくれますが、最初のスタートとして使用することもできます。

スレッドは非常に重要ですが、WebAssemblyの最小限の実行可能な製品にスレッドを詰め込むよりも、スレッドを正しくすることが重要でした。 私たちの推論は単純です：asm.jsはこの機能なしで成功を収めています。

MVPが迅速に脱出する必要性（スタックベースに移行するためにASTを削除する理由だったと思います）と、さらなるステップを計画するために必要な注意を完全に理解してください。

スレッドは、いくつかの重要なアプリケーションにとって間違いなくメイクまたはブレイク機能ですが、すべてのアプリケーションに適しているわけではありません。 GC、ゼロコストの例外処理、保証された末尾呼び出しなどについても同じことが言えます。

emscriptenの長年のユーザーとして、私はWebAssemblyがJavascriptアプリケーションスタックの制限からより切り離されていることを望んでいます。

Wasmは、1）最高のパフォーマンスを目指し、2）ソケット、メモリ/スレッド、GDI、fsにPosix / Unix / BSD標準を提供する必要があります。 そうすれば、それは、統合されたターゲットプラットフォームとしてモバイルデバイスに、そしてクラウド展開可能なアプリケーションをめぐって競合するサーバーに埋め込むことができる、OSのような薄いレイヤーになります。

これは長期的な未来に向かっている方向ですか、それとも私はボートを完全に逃していますか？

あなたの仕事にもう一度感謝します、

ロベルト

Wasmは、LLVMなどのコンパイラがユーザーアクセス可能なメモリに配置する必要があるものからローカルを分離する方法のために、いくつかのスタック制限から確実に切り離されています。

スレッドを使用すると、特にワーカーベースでない場合は、より多くのパワーを得ることができます。

そうは言っても、あなたの正確なアイデアについてもっと詳しく知るのは良いことです。 ユースケースは何ですか、C ++でどのように回避し、wasm実装はどのようにそれを行いますか？

私はあなたがすべての答えを思い付くとは思わない！ 今頭に浮かぶのはまさに。 Fwiw C ++には、スタック制限に関するいくつかの提案があります。 SG14サブグループをチェックしてください。

詳細が低くて申し訳ありませんが、私は👶🌯の下にいます。 後でもっとよく答えます！

詳細がわからなくてすみません、私は：baby :: burrito：の下にいます。 後でもっとよく答えます！

あなたは赤ちゃんブリトーの下にいますか？ 笑

@qwertie

あなたは赤ちゃんブリトーの下にいますか？ 笑

文字通り、包まれた赤ちゃん。

こんにちは@jfbastien 、

あなたの正確なアイデアについてもっと詳しく知るのは良いことです。 ユースケースは何ですか、C ++でどのように回避し、wasm実装はどのようにそれを行いますか？

一般的に、私の使用例はシミュレーションソフトウェアの構築です。計算の部分では、C ++、C / OpenCL、およびGPUテクノロジのおかげで、制限はマシンのみになります。

フロントエンドでは、スタックHTML5 + CSS + Javascript + Typescriptが、中規模から大規模の複雑なアプリケーションを開発するための有効で実証済みのポータブルな方法であることが証明されています。

_ JS Webスタック（ Typescriptのような構造化言語が追加されている）は最近非常に優れているため、ほとんどのアプリケーションでemscriptenに頼ったりwasmを試したりする必要はありません。_

私は、高レベルの目標とWebアセンブリのユースケース、さらには非Web埋め込みドキュメントについてもほぼ完全に同意します。

_ W ebAssemblyは、より高速に（ネイティブCアプリの骨に加えて、たとえば5％のオーバーヘッドで）より多くのメモリをより自由に使用し、ポート/ソケットを完全に実装できる場合、（少なくとも私にとっては）関連するテクノロジーになります通常のOSと同じようにスレッドを実行できます。_

Wasmマシンは、サイズが非常に滑らかで、高速で予測可能である必要があるため、GCに固執しないでください。GCはITのポンジースキームです。手​​遅れになり、サイクルが失われるまで、債務を負い、割り当てを気にしません。 。 さらに、高性能のwasmコアマシンがあれば、その上にGCを構築できます。

滑らかにするために、Javascriptから徐々に切り離していきます。 任意の言語のネイティブコンパイラを使用している場合、スクリプトは必要ありません。とにかく、CソースでコンパイルするだけでDuktape / Lua /その他を埋め込むことができます。

Mozillaサイトのどこかで、wasmネイティブDOM操作の実装に関するドキュメントを見ました。DOM操作は本質的にシーケンシャルであり、HTML5 / CSS / JSスタックの最も時間のかかる側面の1つであるため、あまり有用ではないと思います。超高速のマルチスレッドwasmを作成するのは、DOMの変更をシリアル化してキューで待機させるためだけです。そうすると、すべてのパフォーマンスが失われ、C / C ++を使用するよりもTypescriptをトランスパイルする方が適切です。 この場合、私は直接OpenGLアクセスを好みます（最初はいくつかのWebGL実装で、次にOpenGLネイティブで）。 グラフィックカードにアクセスすると、オーバーヘッドが小さいかまったくないGPU / CUDA機能を提供するのに役立ちます。
（これを確認しに行って、これに取り組む問題＃273を取得しました）

すべてのベンダーや独立系企業が小さなwasmマシンを共有することで、さまざまなOS、バージョン、アーキテクチャに対応するツールチェーンが少なくとも4つあるモバイル開発の悪夢を解決できます。
グラフィック機能と入力機能は異なる場合がありますが、1つのwasmに開発してから、機能APIにクエリを実行したり、同じアプリケーションを別のアプリストアにデプロイしたりすることもできます。
長期的には、サーバーアプリケーションでも同じであり、機能（DB接続プロトコルとプール、イエローページシステム、メッセージングプロトコルとシステムなど）について何らかの合意に達し、JEEプラットフォームのように標準仕様にパックします。 （多くの概念的な作業は、過去20年間ですでにレイアウトされています）。

私はあなたがすべての答えを思い付くとは思わない！ 今頭に浮かぶのはまさに。 Fwiw C ++には、スタック制限に関するいくつかの提案があります。 SG14サブグループをチェックしてください。

確かにやります。

ご理解とご協力をよろしくお願いいたします。

ロブ

小さな追加として、スレッドが実装されている場合、スタックサイズを任意に大きくすることができれば、またはその代わりに、少なくとも64MBに設定できれば素晴らしいでしょう。 これは、私のユースケースが2つのスレッドを使用するアプリケーションであり、非メインスレッドにはかなり大きなスタックが必要なためです。

@jjpeは、このリポジトリではなく、wasmを対象とする特定のツールチェーン（emscriptenなど）のリクエストになります。これは、wasmプラットフォーム自体に関するものではなく、ツールチェーンの実装またはABIの選択の問題であるためです。 （たとえば、https：//github.com/kripken/emscripten/で問題を開くことができます）

以前のメッセージで提案したことのいくつかは、最新のWASI提案に含まれているようです。
見る：
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

交差指。

--R

FWIW現在の状況では、Chromeはバージョン74でwasmスレッドのサポートを出荷しており、Firefoxにはまだ出荷されていない実装があり、Emscriptenにはpthreadsのサポート（https://emscripten.org/docs/porting/pthreads.html）があります。 wasmが利用可能になりました。

（また、WASIはシステムコールAPIであり、特定のwasm埋め込みまたはツールチェーンがスレッド/アトミックをサポートするかどうかにほぼ直交します）。

ChromeとFirefoxのスレッドAPIの使用方法に関するドキュメントはありますか？

それは一種の組み合わせです。 ブラウザのwasmエンジンは、wasm仕様（https://github.com/WebAssembly/threads/tree/master/proposals/threads）のthreads / atomics拡張機能を実装しており、共有されたwasmメモリをインスタンス化できます。 Webでは、Webワーカーを作成し、postMessageを介してメモリ（および関連するwasmモジュール）をワーカーに送信できます。 次に、ワーカー（およびメインスレッドまたは別のワーカー）の共有メモリを使用してモジュールをインスタンス化し、インスタンスがメモリを共有します。 仕様提案の概要（https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md）には小さな例がありますが、他の例はわかりません。

こんにちは@dschuffと上記の答えに感謝します。
以前のメッセージでは、pthreadだけでなく、wasmをよりカーネルに進化させるという望ましい進化について言及していました。2010年以降、emscriptenをフォローして使用している人の中には、それを真の画期的なテクノロジーと見なしている人もいます。
https://github.com/WebAssembly/design/issues/992#issuecomment-285055578を参照してください。

emscriptenが発表されてから9年後、wasmの発表からほぼ5年後、wasmを実行可能なサーバーテクノロジーに変換することはほとんど進んでいません。

残念ながら、ポータブルアプリの標準が必要であり、それを実現する最善の方法は、POSIXスレッドとBerkeley Sockets +自己完結型の安全な仮想ファイルシステム（ユーザーを含む）を使用して小さなカーネル（BSD / Linuxのような）を実装することでした。とグループで十分です）。 私はH.Spencerの古いことわざに固執します：「UNIXを理解していない人はそれを再発明することを非難されます」。

私はまだ信仰を保ちたいので、WASIは正しい方向への一歩です。

--R

PS：2010 emscriptenは、ほとんどの企業で使用されている、言及できない、殺せないブラウザであり、FirefoxとSafariの本体が（少なくともそれらのエンジンで）浮かんでいる不滅のブラウザで動作するため、依然として揺らいでいます。