🔁 🤑 🔏 Rivertrail：JavaScriptの並行性 🍮 🐠 💂🏼

並行性の使用は、現在では一般的なプログラミング手法です。ただし、すべての言語は2つのタイプに分けることができます。mightとmainで並列処理が使用される言語（Cなど）と、マルチスレッドの楽しさをまだ十分に味わっていない言語です。特に後者にはJavaScriptが含まれます。この迷惑なギャップを埋め、プログレッシブエクスペリエンスの箱を埋めるために、Mozilla FoundationプログラマーであるNick Matsakisのブログからのメッセージの翻訳を提供します。

最近、JSでデータを並列化するツールとしてIntelが提供する製品であるRivertrailを使い始めました。これまでのプロジェクトでは、肯定的な印象しか残していません。初期バージョンはIntelの仕様に結び付けられますが、PJのフレームワーク内で作成された他のプロジェクトと組み合わせることが可能になることを願っています。

ダミー用リバートレイル

以下は、この製品について聞いたことがない人向けの簡単な紹介です。Rivertrailは、アレイを並列処理できる仕様です。仕様の基本は、 ParallelArrayクラスの追加です。これらの配列には、JS配列といくつかの重要な違いがあります。

彼らは変わらない
隙間がない
多次元にすることもできますが、多次元は「正しく」（たとえば、2次元マトリックスでは、列の数は行の数に等しくなります）。

並列配列は、 （）mapや（）reduceなどのかなり多数の高レベル操作をサポートしています。完全なリストは、 Rivertrailの仕様に記載されています。これらのメソッドは引数として関数を取り、通常のJS配列の対応する関数とほとんど同じように機能します。いくつかの重要な違いに加えて：

まず、引数として使用される関数は、常に「純粋」である必要があります。詳細は以下を参照してください。
次に、可能であれば、JSエンジンはこれらの機能を並行して実行しようとします。

純粋な機能

これらは、共有状態を変更しない通常のJS関数です。これは、関数がまったく変更できないことを意味するものではありません。関数自体によって割り当てられたローカル変数とオブジェクトは変更できます。

たとえば、マンデルブロ集合を計算する関数は純粋です：

function mandelbrot(x, y) { var Cr = (x - 256) / scale + 0.407476; var Ci = (y - 256) / scale + 0.234204; var I = 0, R = 0, I2 = 0, R2 = 0; var n = 0; while ((R2+I2 < 2.0) && (n < 512)) { I = (R+R)*I+Ci; R = R2-I2+Cr; R2 = R*R; I2 = I*I; n++; } return n; }

mandelbrot（）はローカル変数のみを変更します。ただし、 sums（）はこの点でより興味深い-関数は入力配列Xの部分和を計算し、出力配列sumに格納します。

 function sums(x) { var sums = [], sum = 0; for (var i = 0; i < x.length; i++) { sum += x[i]; sums[i] = sum; } return sums; }

注意すべきこと-この関数は、ローカル変数だけでなく、ヒープオブジェクトを変更して、値を合計配列に割り当てます。ただし、このオブジェクトは関数自体で強調表示されているため、純粋な関数のままです。実際、特定の例は、Rivertrailの現在のバージョンに存在する多くの制限のために並行して実行されませんが、うまくいけば、これはすぐに変更されることを願っています。

また、 Xが変更され、 Xがローカルに割り当てられないため、純粋とは見なされない関数の例を次に示します。

 x = [1, 2, 3]; function impure() { x[0] += 1; }

並列実行

ParallelArrayの主な魔法は、可能な限り機能を並列に実行することです。この場合、並列処理または実行のシーケンスは、JS自体の実装に依存します。並列実行を目的とした関数は純粋であるという事実は、概念的には常に安全に実行できることを意味します。しかし、これはJSエンジン自体がそれらを実行できることを意味しません。

JSエンジンは多くの隠れた最適化を行いますが、これらの最適化のすべてがスレッドセーフではありません。

これまでのところ、並行して実行される操作のリストはかなり控えめですが、時間が経つにつれて拡張され、理想的には拡張され、純粋な機能が並行して実行できるようになります。

コードが高速であることを確認するには、多くのことを行う必要があります。並列コード実行を保証するには、同じことをする必要があります。それが理由です。

例

 ab = c

JITコンパイラがタイプaを分析し、たとえば、プロパティbが常に特定のオフセットで格納されていると判断した場合、単一のアセンブラー命令でコードを最適化できます。しかし、コンパイラがコードの解析に失敗すると、最悪の場合、インタープリターが呼び出され、さまざまなハッシュテーブル、プロトタイピングツリーなどで作業します。ここで、 ab = cがスレッドセーフかどうかを理解する必要があります。ここではすべてが単純です。保存命令は、保存先のメモリにアクセスできるスレッドが1つだけであるという前提の下で安全です。機能の「純度」の保証です。インタプリタが数千行ではないにしても数百行のコードに触れる場合、これを解決するのはより困難になります。

もちろん、どのコードが効果的にコンパイルされるかを知ることは勝利ではありません。次の記事では、今日の並列実行を保証するいくつかのことについて説明し、この分野での将来の予測をいくつか示します。

並列実行モデル

Rivertrail Mozillの使用モデルは、Intelのプロトタイプとは若干異なります。これは、OpenCLでJSをコンパイルするプラグインです。ネイティブ実装では、4つの異なる方法でコードを実行できますが、現時点では最初の2つしか利用できません。

順次。スタンバイモード。 forループの記述または高レベルの配列メソッドの使用と同等です。このモードは、ナイトリービルドで動作し、場合によってはAuroraでも動作します。コンソールでvar x = new ParallelArray（[1、2、3]と入力してみてください
マルチコアモード 。このモードでは、デフォルトで動作します。マルチコアモードは、システム内のコアごとに1つのスレッドを配布します。各ワーカースレッドは、関数の並列コピーで動作します。今後数か月のうちに、このモードのより機能的なバージョンを期待しています。
ベクトル化モード。 マルチコアのように見えますが、違いがあります-各ワーカースレッドはSSE命令を使用して、一度に複数の配列要素を処理します。これは、マルチコア後の計画に残っています。
GPU これはベクトル化モードの実行の単なる変形ですが、コードのベクトル化はCPUではなくGPUで機能します。多くの技術的な違いがあります。一方では、ベクトル化はハードウェアのGPUによって処理され、コンパイラは特別な命令を使用する必要がありません。一方、一部のプラットフォームでは、CPUとGPU間でメモリをコピーするために一生懸命働く必要があります。

説明されているモードのうち、最も一般的なものはシリアルと見なすことができます-純粋な機能に適用できます。マルチコアは非常に用途が広く、現在サポートされている操作に制限される純粋な関数を操作するときに使用できます。

ベクトル化とGPUモードはさらに制限されます。 GPUがデータの移動などに特定の制限を課す一方で、コードをパックおよびアンパックせずにSSE命令に変換できる関数に対してのみベクトル化を使用することは理にかなっています。

パフォーマンスについて一言

いくつかのデータがあるので

プロファイリングはまだ完了していません
まだ詳細なテストはありません
計算の最適化も失敗しました

少なくとも、ここではHypertheadingを使用してクアッドコアラップトップに設定されたMandelbrotを計算した結果を示します。

seq-順次モードのランタイム

par-並列モードでの同じ数のスレッドのランタイム

ratio-シーケンシャルモードの時間とパラレルの時間の比（seq / par）。より多くの、より良い。

スレッド	シーケンス（ミリ秒）	パー（ミリ秒）	比率（Seq / Par）
1	2976	2515	1.18
2	2952	1782	1.65
4	2964	1417	2.09
8	2880	1149	2.50
16	2891	1109	2.60

明らかに、これらの値は改善できます。生産性が直線的に向上すれば素晴らしいことです。そして、これを達成するのは難しいとは思わない、楽観的だ。

ところで、シリアルモードのデータは、パラレルモードのParallelArrayではなく、アレイに基づいたJS実行を使用してここで取得され、コードは、JITが使用されたことを確認するためにしばらく機能しました。 JITの使用に関する機器のチェックは行われませんでした（そのため、「適切なプロファイリングは行われなかった」と言います）。

PJについて

JavaScriptを並行して実行するための以前のアイデアを聞いたことがある人もいるかもしれませんが、それらは「PJ」（Parallel Java Script）と呼ばれていました。これはすべて計画中ですが、PJ APIで一部のRivertrailメカニズムを使用することも可能です。そして、これまでのところ、この問題の障害となる理由は見られません。現在の主なことは、マルチコアモードでサポートされている関数セットを拡張することです。

要約する

データの結合（並行性）はJSにもたらされます（少なくともFirefoxで）。実装されたAPIは、並行性を使用してJSをプログラミング言語の最前線に置くことができます。これは非常に使いやすく、シリアル化された実行を保証します。 PJは決定的な実行も保証しますが、Rivertrailは（）reduceなどの関数のために保証しません。これを誇る言語はほとんどありません。

翻訳と編集を手伝ってくれたvikky13に感謝します。

Rivertrail：JavaScriptの並行性