OSがCPU時間を提供できなかったという理由だけで、個々のスレッドが互いに遅れないように設定された並行（つまり、マルチスレッド、並列など）プログラミング言語を誰かが知っているかどうか疑問に思っていました。アセンブリでこれを回避できるかどうかさえわかりません。:P しかし、私は明らかに確信が持てないので、質問です。
プログラムが CPU サイクルにリアルタイムでアクセスする必要があると言っているのではありません。スレッドが同期から外れてはならないということです。また、言語がバイトコードではなくバイナリ実行可能ファイルにコンパイルされるか、単にインタープリターによって実行されると、非常に便利です。
私はそんなことはないと信じています。
その理由は、複数のスレッドが異なるコアで実行される場合にのみ、複数のスレッドを真に並列で実行できるからです。実際、マルチコア プロセッサが登場するまでは、異なるスレッドをまったく同時に実行 (計算) することは技術的に不可能でした。
現代のOSは大量のプロセスを使用するため、スレッドを使用します（少なくともプロセスごとに、スレッドはプロセスの「作業」部分です）。マルチコア プロセッサにもかかわらず、すべての一般的な使用法では、使用可能なコアよりも多くのスレッドがシステム上でアクティブになっています。
これらの行を書いているとき、「たった」8 つの使用可能なコアに対して 357 のスレッドがアクティブになっています。
それがスケジューラの使用目的です。スタベーションを回避し、同時実行の錯覚を与えるために、異なるスレッド間で利用可能な計算時間を共有します。
異なるスレッドが同時に実行され、時々上書きされないことを保証するには、OS のスケジューラを変更する必要があります。これは、可能であれば、少なくとも悪い考えです。
インタープリターの使用は、マルチスレッドアプリケーションを実行する唯一の方法は、同じ問題を持つインタープリタースレッドを作成することであるため、役に立ちません。
異なるスレッドが同期されていることを確認するには、バリアまたはセマフォを使用する必要があります。これは、ユーザーのコンピューターの OS のスケジューラを変更できないためです。
注: HPC アプリケーションでは、研究者はコンテキスト スイッチ (スレッドが実行されている環境を保存して後で復元する操作) で時間を無駄にしないようにします。したがって、利用可能なコアに応じてスレッドを割り当て (通常、OS と I/O 用に 1 つのコアを残します)、他のスレッドを特定のコアに固定します。これは、計算が可能な限り効率的に行われることを保証するのに役立ちます。
ただし、これは同期を保証するものではなく、バリアのような特定のメカニズムの使用が依然として必要になる場合があります。
最新のプロセッサでは、特定の計算が絶対的に既知の速度で進行することを確認することは非常に困難です。
たとえば、キャッシュ ミスを起こしたスレッドは、キャッシュ ヒットを起こした同じスレッドよりも数百サイクル多く必要になる場合があります。そのため、速度はキャッシュの内容に依存します。キャッシュされる内容は、過去にスレッドによって実行された複雑な制御とデータ フローによって異なります。制御されていない遅延の原因はたくさんあります (パイプラインの中断、オペランドに応じた可変長命令の実行、OOO CPU での内部リソースの競合、さまざまなメモリ階層やバスを介した他の CPU へのメモリ遅延、メッセージの送受信時間など)。
したがって、スレッドをまったく同じ速度で進行させるには、ほとんど手に入れることができない膨大な量の制御または先見の明が必要です。(スーパーコンピューティング担当者は、OS をほとんどオフにして、ランダムなタイミングで発生する割り込みなどによるバックグラウンド ノイズを最小限に抑えます。これでも、あまり役に立ちません)。
より良いアプローチは、スレッドが実行した作業が、それを必要とする別のユーザーに利用可能であることを通知することです。シグナリング/待機がめったに発生しない場合は、スレッドの計算作業によって圧倒され、プロセッサが効率的に使用されます。
上記を達成することは依然として困難である。すべての CPU で同じ計算を行う場合(ビッグデータの並列計算など)、それが非常に規則的である場合、全体の速度はかなり類似している可能性があります。それらがすべてロックステップに戻っていることを確認するために、最後にいくつかの（バリア）同期が必要です。
すべての計算をすべての CPU で「同じ」ものとして編成するのはかなり困難です。多くの不規則な (さまざまなサイズの) 計算「グレイン」がある可能性が高くなります。それらを追跡できる場合は、それらを多くのスレッド/CPU に分散し、個々のグレイン間の明示的な同期を利用して全体的に正しく動作させ、新しいグレインを突然アイドル状態の CPU に渡してビジー状態に保つことができます。これは、「ワーク スティーリング」の概念によってうまく実現されます。各 CPU には実行可能な未実行のグレインのプールがあり、可能な限り高速に処理します。穀物は、より多くの穀物を製造する場合があります (不足した場合、計算は終了です!)。CPU のグレインのプールが空になると、他の CPU のプールから作業を盗みます。ワーク スチール スケジューラを構築するのは非常に困難です。彼らは正しくなければなりません。
当社のPARLANSE並列プログラミング言語は、まさにそのような問題を処理するように設計されています。プログラムを表す非常に大きなグラフで実行します。グラフ内の適度な半径のパッチごとに少しの作業が発生する傾向があります。このようなグラフに 100 万個のノードがあると、多くの作業が必要になります。