これ以上無料のスープはありません

プログラミングの並行性への根本的なシフト



投稿者： 紋章のサッター

翻訳： アレクサンダー・カチャノフ



無料のランチは終わりました：ソフトウェアの並行性への根本的な転換

（ハーブサッターによる）



元の記事へのリンク： www.gotw.ca/publications/concurrency-ddj.htm



翻訳者注 ：この記事では、プロセッサーの開発における現在の傾向の概要と、プログラマーにとってこれらの傾向が正確に意味するものを提供します。 著者は、これらの傾向は基本的であり、現代のすべてのプログラマーが生活に追いつくために何かを再学習する必要があると考えています。



この記事はかなり古いです。 2005年初頭の最初の出版の瞬間から数えると、彼女はすでに7歳です。 翻訳を読むときは、これを覚えておいてください。すでに慣れ親しんでいるものの多くは、2005年にこの記事の著者にとって新しく登場したばかりでした。





最大のソフトウェア開発革命は、OOP革命以来あなたのドアをノックしています。その名前はParallelismです。





この記事は、雑誌「Dr. Dobb's Journal、2005年3月。 この記事の短いバージョンは、2005年2月に「同時実行革命」というタイトルでC / C ++ Users Journalに掲載されました。



更新：プロセッサの成長傾向チャートは2009年8月に更新されました。 新しいデータが追加され、この記事のすべての予測が実現することを示しています。 この記事の残りのテキストは、2004年12月に公開されたため、変更されていません。



無料のスープはすぐになくなります。 これについてどうしますか？ これについて今何をしていますか？



IntelとAMDからSparcとPowerPCまで、プロセッサとアーキテクチャの大手メーカーは、ほとんどの場合、生産性を向上させる従来の可能性を使い果たしました。 プロセッサの周波数とその線形帯域幅を増加し続ける代わりに、彼らは大規模にハイパースレッドおよびマルチコアアーキテクチャに変わります。 これらのアーキテクチャは両方とも、今日のプロセッサにすでに存在しています。 特に、最新のPowerPCおよびSparc IVプロセッサはマルチコアであり、2005年にはIntelとAMDが現在のプロセッサに加わります。 ちなみに、2004年秋に開催されたIn-Stat / MDR Fall Processor Forumの大きなトピックは、多くの企業が新しいマルチコアプロセッサを発表したため、マルチコアデバイスのトピックにすぎませんでした。 2004年がマルチコアの年だったと言っても過言ではありません。



そのため、少なくとも数年前に、汎用デスクトップコンピューター用およびサーバーの下位セグメント用に設計されたアプリケーション（ちなみに、現在販売されているすべてのプログラムの大きなシェアを占めるアプリケーション）のソフトウェア開発の根本的な転換点に近づいています市場で）。 この記事では、ハードウェアの変更方法、これらの変更が突然重要になった理由、並列化革命があなたにどのように影響するか、そして将来どのようにプログラムを書く可能性が高いかについて説明します。



おそらく、無料のスープは1年か2年前にすでに終了したのでしょう。 気づき始めました。

無料のパフォーマンススープ

「アンディがいくら出してもビルはすべてを奪う」（「アンディはギブを奪い、ビルは奪う」）という興味深い言葉を聞いたことがあるでしょう。 （コメント翻訳者-これはIntelの責任者であるAndy GroveとMicrosoftの責任者であるBill Gatesを指します）。 プロセッサの数がどれだけ速度を上げても、プログラムはこの速度を何に費やすかを常に把握します。 プロセッサを10倍高速化すると、プログラムはそれに対して10倍の作業を見つけます（または、場合によっては、同じ作業を10倍効率的に実行できます）。 ほとんどのアプリケーションは、数十年にわたってますます高速に実行されており、新しいバージョンをリリースしたり、コードに根本的な変更を加えたりしなくても、何もしません。 プロセッサの製造業者（まず）とメモリとハードドライブの製造業者（すべて）が次々と、より高速で新しいコンピューターシステムを作成したということです。 プロセッサのクロック速度は、そのパフォーマンスを評価するための唯一の基準ではなく、最も正しいものでもありませんが、それでも多くのことを言っています：500 MHzプロセッサがクロック周波数1 GHzのプロセッサに置き換えられ、その後-2 GHz-新しいプロセッサなど。 そこで、クロック周波数が3 GHzのプロセッサーがごく普通の段階を経ています。



今、私たちは自問します：このレースはいつ終わりますか？ ムーアの法則は指数関数的成長を予測します。 このような成長は永遠に続くことはできず、必然的に物理的な限界に達することは明らかです。結局のところ、光の速度は長年にわたって速くならないからです。 したがって、遅かれ早かれ、成長は鈍化し、さらには停止するでしょう。 （小さな説明：はい、ムーアの法則は主にトランジスタの密度について述べていますが、クロック周波数などの領域でも指数関数的な成長が観察されたと言えます。他の分野では、ストレージ容量の成長など、成長はさらに大きくなりましたが、別の記事のトピック。）



あなたがソフトウェア開発者である場合、デスクトップパフォーマンスの向上をきっかけに長い間リラックスしている可能性が高いでしょう。 何らかの操作を実行している間、プログラムはゆっくり実行されますか？ 「なぜ心配？」とあなたは言います、「明日はもっと速いプロセッサが出てくるでしょうが、一般的にプログラムは遅いプロセッサと遅いメモリのためだけでなく遅くなります（たとえば、呼び出しのために遅いI / Oデバイスのために）データベースへ）。」 正しい思考の列？



本当です。 昨日。 しかし、予見可能な未来については絶対に間違っています。



良いニュースは、プロセッサがますます強力になることです。 悪いニュースは、少なくとも近い将来には、プロセッサのパワーの増加が、ほとんどの既存のプログラムの作業を自動的に加速しない方向に進むということです。



過去30年間、プロセッサ開発者は3つの主要な分野でパフォーマンスを向上させることができました。 それらの最初の2つは、プログラムコードの実行に関連しています。

• プロセッサー速度
• コード実行の最適化
• キャッシュ

クロック速度の増加は、速度の増加を意味します。 プロセッサの速度を上げると、多かれ少なかれ、同じコードをより高速に実行できるようになります。



プログラムコードの実行を最適化するということは、1クロックサイクルでより多くの作業を行うことを意味します。 今日のプロセッサには非常に強力な命令が搭載されており、コード実行のパイプライン化、分岐予測、同じクロックサイクルでの複数の命令の実行、プログラムコマンドの異なる順序での実行（命令並べ替え）。 これらのテクノロジーはすべて、各クロックサイクルから可能な限り圧縮して、遅延を最小限に抑え、サイクルあたりの操作数を増やすために、コードが可能な限り最良かつ/またはできるだけ速く実行されるように考案されました。



異なる順序（命令の並べ替え）とメモリモデル（メモリモデル）での命令の実行に関する小さな余談：「最適化」という言葉で、私は本当にもっと何かを意味したことに注意したいと思います。 これらの「最適化」は、プログラムの意味を変え、プログラマの期待に反する結果をもたらす可能性があります。 これは非常に重要です。 プロセッサ開発者は夢中にならず、人生でハエを害することはありません。通常の状況では、コードを台無しにすることは決してありません。 しかし、過去数年間、各プロセッサのクロックサイクルをさらに絞ることを唯一の目的として、積極的な最適化を決定しています。 ただし、これらの積極的な最適化はコードのセマンティクスを危険にさらすことをよく認識しています。 まあ、彼らはこれを害からやっていますか？ まったくありません。 彼らの望みは、ますます高速のプロセッサを必要とする市場の圧力に対する反応です。 このプレッシャーは非常に大きいため、プログラムの速度がこのように増加すると、プログラムの正確さが損なわれ、動作する能力さえ損なわれます。



最も顕著な2つの例を挙げましょう。データ書き込み操作の順序の変更（書き込みの並べ替え）と、読み取り順序（読み取りの並べ替え）です。 データ書き込み操作の順序を変更すると、このような驚くべき結果につながり、多くのプログラマーを混乱させます。多くのプログラマーは、この機能をオンにすると、書き込まれたプログラムの動作を正しく判断することが難しくなりすぎるため、通常はこの機能を無効にする必要があります。 データ読み取り操作の順列も驚くべき結果につながる可能性がありますが、プログラマーには特別な困難はなく、オペレーティングシステムとソフトウェア製品のパフォーマンス要件により、プログラマーは少なくともある程度妥協してしぶしぶ選択するため、この機能は通常残されます最適化の「悪魔」の少ない。



最後に、組み込みキャッシュのサイズを増やすことは、RAMへのアクセスをできるだけ少なくすることを意味します。 コンピューターのRAMはプロセッサーよりもはるかに遅いため、データをRAMで実行しないように、できるだけプロセッサーの近くにデータを配置することをお勧めします。 最も近いのは、プロセッサ自体が配置されているシリコンの同じ部分にそれらを保存することです。 近年のキャッシュサイズの増加は圧倒的です。 現在、2MB以上の第2レベル（L2）の組み込みキャッシュメモリを備えたプロセッサを使用している人を驚かせることはできません。 （プロセッサのパフォーマンスを向上させるための3つの歴史的なアプローチのうち、キャッシュの成長が近い将来の唯一の有望なアプローチになります。キャッシュの重要性については、以下でもう少し説明します。）



いいね なぜ私はこれすべてですか？



このリストの主な意味は、リストされているすべての方向が並列性に関係していないことです。 これらすべての分野でのブレークスルーにより、シーケンシャル（非並列、単一プロセス）アプリケーションと並列処理を使用するアプリケーションの両方が高速化されます。 今日のアプリケーションのほとんどはシングルスレッドであるため、この結論は重要です。これについては、以下で説明します。



もちろん、コンパイラーもプロセッサーに遅れずについていく必要がありました。 新しい命令（MMX、SSEなど）、新機能、新機能の恩恵を受けるために、アプリケーションを再コンパイルし、特定のプロセッサモデルを最低限許容できるものとして選択する必要が時々ありました。 しかし、一般的に、古いプログラムでさえ、最新のプロセッサーからの最新の命令を再コンパイルおよび使用しなくても、古いプロセッサーよりも常に新しいプロセッサーでずっと速く動作しました。



この世界がどれほど美しいか。 残念ながら、この世界はもはや存在しません。

障害、または10 GHzプロセッサが表示されない理由

2年前の私たちにとってのプロセッサパフォーマンスの通常の向上は、壁にぶつかりました。 私たちのほとんどはすでにこれに気づき始めています。



他のプロセッサについても同様のグラフを作成できますが、この記事ではIntelプロセッサのデータを使用します。 図1は、どのIntelプロセッサーが市場に導入されたか、そのクロック周波数、およびトランジスタ数を示すグラフを示しています。 ご覧のとおり、トランジスタの数は増え続けています。 しかし、クロック周波数には問題があります。







2003年の領域では、クロック周波数のグラフは、継続的成長の通常の傾向から急激かつ奇妙に逸脱していることに注意してください。 トレンドをより明確にするために、ポイント間に線を引きました。 成長を続ける代わりに、チャートは突然水平になります。 クロック周波数の増加はますます与えられており、1つではなく、成長経路に対する多くの物理的な障害があります。たとえば、加熱プロセッサー（熱が過剰に発生し、それを放散するのが難しすぎる）、エネルギー消費（高すぎる）、および浮遊電流の漏れです。



簡単な余談：見て、お使いのコンピューターのプロセッサー周波数は？ たぶん10 GHzですか？ Intelプロセッサはかなり前（2001年8月）に2 GHzレベルに達しましたが、2003年以前に存在したクロック周波数の成長傾向が続いた場合、2005年の初めに、周波数が10 GHzの最初のPentiumプロセッサが現れたでしょう。 見回して、見えますか？ さらに、このようなクロック速度のプランさえ誰も持っておらず、そのようなプランがいつ現れるかさえわかりません。



さて、4GHzプロセッサはどうですか？ すでに、周波数が3.4 GHzのプロセッサがありますので、4 GHzはすぐそこにありますか？ 残念ながら、4 GHzにも到達できません。 2004年半ばに、Intelが4GHzプロセッサのリリースを2005年に延期し、2004年秋にこれらの計画を完全に拒否したことを公式に発表したことを覚えているでしょう。 この記事の執筆時点で、Intelは2005年初頭に周波数3.73 GHzのプロセッサを起動することで少し前進する予定です（図1では、周波数成長グラフの最高点です）が、少なくともヘルツの競争は終わったと言えます今日の瞬間。 将来、Intelおよびほとんどのプロセッサメーカーは、他の方法で成長を追求します。それらはすべて、マルチコアソリューションに積極的に移行しています。



いつかデスクトップコンピュータに4GHzプロセッサが表示されるかもしれませんが、2005年には表示されません。 もちろん、Intelの研究所には、より高速で動作するプロトタイプがありますが、これらの速度は、例えば大型の冷却装置の助けを借りて、英雄的な努力によって達成されています。 そのような冷却装置がオフィスに登場することを期待しないでください。また、ラップトップで作業したい飛行機には絶対に期待しないでください。

BSNB：ムーアの法則と次世代プロセッサ

「無料のスープはありません（BSNB）」-R.A.ハインライン、「月は厳しい愛人です」



これは、ムーアの法則がもはや有効ではないということですか？ 最も興味深いのは、答えがノーだということです。 もちろん、指数関数的な進歩のように、ムーア法はいつか機能しなくなりますが、今後数年間は法が危険にさらされないようです。 プロセッサの設計者はもはやクロック周波数を上げることができないという事実にもかかわらず、プロセッサ内のトランジスタの数は爆発的なペースで増え続けており、今後数年間、ムーアの法則による成長は続きます。



この記事が書かれた以前のトレンドとの主な違いは、いくつかの将来の世代のプロセッサーのパフォーマンスが基本的に他の方法で達成されることです。 そして、これらの新しい、より強力なプロセッサ上の現在のアプリケーションのほとんどは、設計に大幅な変更が加えられない限り、自動的に高速に実行されなくなります。



近い将来、より正確には今後数年間で、新しいプロセッサのパフォーマンスの向上は3つの主な方法で達成され、そのうちの1つだけが前のリストから残っています。 すなわち：

• ハイパースレッディング
• マルチコア
• キャッシュ

ハイパースレッディングは、同じプロセッサで2つ以上のスレッドを並行して実行する技術です。 ハイパースレッドプロセッサは既に市販されており、複数の命令を並行して実行することができます。 ただし、ハイパースレッドプロセッサには、このタスクを実行するためのハードウェア（レジスタなど）が追加されているにもかかわらず、キャッシュ、整数演算用の計算ユニット、浮動小数点演算用のユニットが1つしかありません。単純なプロセッサで利用可能なものを一度に1つ。 ハイパースレッディングにより、合理的に記述されたマルチスレッドプログラムのパフォーマンスが5〜15％向上し、理想的な条件下で適切に記述されたマルチスレッドプログラムのパフォーマンスが最大40％向上すると考えられています。 悪くはありませんが、これは生産性の倍増にはほど遠いものであり、シングルスレッドプログラムは何も勝てません。



マルチコア（マルチコア）は、2つ以上のプロセッサを同じチップに配置する技術です。 SPARCやPowerPCなどの一部のプロセッサは、マルチコアバージョンですでに利用可能です。 2005年に実装されたIntelとAMDによる最初の試みは、プロセッサ統合の程度が互いに異なりますが、機能的には非常に似ています。 AMDプロセッサーは、単一チップ上に複数のコアを搭載しているため、パフォーマンスが大幅に向上しますが、最初のIntelマルチコアプロセッサーは、1つの大きな基板上の2つの共役Xeonプロセッサーのみで構成されます。 このようなソリューションから得られる利益は、デュアルプロセッサシステムの存在から得られるものと同じです（マザーボードは、調整のために2つのチップと追加のマイクロ回路をインストールするために2つのソケットを必要としないため、より安価です）。 理想的な条件下では、プログラムの実行速度はほぼ2倍になりますが、マルチスレッドアプリケーションはかなり適切に作成されています。 シングルスレッドアプリケーションは成長しません。



最後に、少なくとも近い将来、オンダイキャッシュの増加が予想されます。 3つの傾向すべてのうち、これだけがほとんどの既存のアプリケーションの生産性の向上につながります。 すべてのアプリケーションの組み込みキャッシュのサイズを大きくすることは、サイズが速度を意味するという理由だけで重要です。 RAMへのアクセスは高すぎるため、RAMへのアクセスはできる限り少なくしたいと考えています。 キャッシュミスの場合、RAMからデータを抽出するよりも、キャッシュから抽出するよりも10〜50倍時間がかかります。 RAMは非常に高速に動作すると一般に信じられていたため、これは依然として人々にとって驚くべきことです。 はい、ドライブやネットワークに比べて高速ですが、キャッシュはさらに高速です。 アプリケーションが使用するデータの全量がキャッシュされている場合、チョコレートに保存されており、そうでない場合は別のものに保存されています。 そのため、キャッシュサイズが大きくなると、今日のプログラムの一部が保存され、大幅な変更なしで数年間はもう少し命が吹き込まれます。 大恐pression時代に彼らが言ったように、「キャッシュはほとんどありません。」 （「キャッシュは王様」）



（簡単な余談：ここで、「サイズは速度を意味します」というステートメントのデモンストレーションとして、コンパイラーに起こったストーリーがあります。32ビット版と64ビット版のコンパイラーは同じソースコードから作成されます。 32ビットまたは64ビットを作成する必要があります。64ビットプロセッサに多くのレジスタがあり、高速化のための最適化関数もあるため、64ビットプロセッサで64ビットコンパイラをより高速に実行することが期待されていました。コード実行。Sun データはどうですか？64ビットに切り替えても、メモリ内のほとんどのデータ構造のサイズは変更されませんでしたが、もちろん、ポインタは2倍になりました。ポインターのサイズが4バイトではなく8バイトになったため、コンパイラーが処理しなければならないデータの合計サイズが増加しました。データ量の増加は、高速化によりパフォーマンスが低下しただけでした。 プロセッサと追加レジスタの可用性。 この記事の執筆時点では、両方のコンパイラが同じソースコードからアセンブルされており、64ビットプロセッサは32ビットよりも強力であるにもかかわらず、64ビットコンパイラは32ビットコンパイラと同じ速度で実行されています。 サイズは速度を意味します！）



本当に、キャッシュがボールを支配します。 ハイパースレッディングもマルチコアも、今日のプログラムのほとんどの速度を向上させないためです。



それでは、これらのハードウェアの変更はプログラマにとって何を意味するのでしょうか？ あなたはおそらく答えが何であるかをすでに理解しているので、それについて議論して結論を​​導きましょう。

神話と現実：2 x 3GHz <6GHz

デュアルコアプロセッサが2つの3GHzコアで構成されている場合、6GHzプロセッサのパフォーマンスが得られます。 そう？



いや！ 2つのスレッドが2つの物理的に別々のプロセッサで実行される場合、これはプログラムの全体的なパフォーマンスが2倍になるという意味ではありません。 同様に、マルチスレッドプログラムは、デュアルコアプロセッサでは2倍の速度で動作しません。 はい、シングルコアプロセッサよりも高速に動作しますが、速度は直線的に増加しません。



どうして？ まず、2つのプロセッサのキャッシュの内容を一致させるコスト（キャッシュの一貫性）（キャッシュと共有メモリの一貫した状態）、および他の相互作用のコストがあります。 現在、マルチスレッドアプリケーションを実行する場合でも、2プロセッサまたは4プロセッサのマシンは、シングルプロセッサのマシンよりも2倍または4倍高速ではありません。 いくつかの別個のプロセッサではなく、同じチップ上にいくつかのコアがある場合、問題は本質的に同じままです。



第二に、複数のコアが完全に使用されるのは、2つの異なるプロセス、または同じプロセスの2つの異なるスレッドを実行する場合のみです。



（以前の声明に直面して、通常のユーザー向けのシングルスレッドアプリケーションがデュアルコアプロセッサ上でより高速に実行される実際の状況を想像できます。これは、以前はユニプロセッサマシンのコンピューティングリソースを使い果たしていた何らかのトロイの木馬またはウイルスを実行します。最初のプロセッサに加えて別のプロセッサを購入して、ウイルスとウイルスを有効にするかどうかはあなたに任せます おやん。）



アプリケーションがシングルスレッドの場合、使用するプロセッサコアは1つだけです。 もちろん、オペレーティングシステムまたはバックグラウンドアプリケーションは他のカーネルで実行されるため、ある程度の加速がありますが、原則として、オペレーティングシステムはプロセッサを100％読み込まないため、近隣のコアはほとんどアイドル状態になります。 （または、トロイの木馬またはウイルスがスピンします）

ソフトウェアの重要性：別の革命

90年代後半に、オブジェクトを操作することを学びました。 プログラミングでは、構造プログラミングからオブジェクト指向プログラミングへの移行がありました。これは、過去20年、あるいは30年にわたってプログラミングの最も重要な革命になりました。 最近のWebサービスの出現など、他の革命もありましたが、私たちのキャリア全体では、オブジェクト革命よりも根本的で重要な結果をもたらす革命は見ていません。



今日まで。



今日から、「スープ」の代金を支払う必要があります。 もちろん、主にキャッシュサイズの増加により、パフォーマンスをある程度無料で向上させることができます。 ただし、新しいプロセッサの処理能力の指数関数的成長の恩恵を受けたい場合は、正しく記述された並列化（通常はマルチスレッド）アプリケーションにする必要があります。 すべてのタスクを簡単に並列化できるわけではなく、並列プログラムの作成が非常に難しいため、言うのは簡単ですが、実行するのは困難です。



私はdigりの叫びを聞きます：「並行性？ これはどんなニュースですか！？ 人々は長い間、並列プログラムを書いてきました。」 そうだね。 しかし、これはプログラマの取るに足らないシェアにすぎません。



Simula言語がリリースされた60年代の終わりから、人々はオブジェクト指向プログラミングに関与してきました。当時、OOPは革命を引き起こさず、プログラマーの間で支配していませんでした。 90年代の始まりまで。なんで？革命は主に、さらに複雑なタスクを解決し、より多くのプロセッサとメモリリソースを使用するさらに複雑なプログラムが必要になったために発生しました。大規模プログラムの経済的で信頼性が高く予測可能な開発には、OOPの長所（抽象化とモジュール化）が役立ちました。



並行性も同様です。私たちは、コルーチンやモニターなどのトリッキーなユーティリティを書いた太古から知っています。そして過去10年間で、ますます多くのプログラマーが並列（マルチプロセスまたはマルチスレッド）システムを作成し始めました。しかし、革命、転換点について話すのはまだ早すぎました。したがって、現在、ほとんどのプログラムはシングルスレッドです。



ところで、誇大広告については、「ソフトウェア開発の分野でもう1つの革命が間近に迫っている」と彼らが何度も発表してきました。原則として、これを言った人は単に新製品を宣伝しただけです。それらを信じないでください。新しいテクノロジーは常に興味深いものであり、有用であることが証明されていますが、最大のプログラミング革命により、数年にわたって市場に出回っているテクノロジーが生み出され、一時的に爆発的な成長が起こるまで静かに力をつけています。これは避けられないことです。革命は、十分に成熟した技術（多くの企業やツールから既にサポートされている）のみに基づくことができます。通常、新しいプログラミングテクノロジが、レーキやグリッチを踏むことなく広く適用されるほど信頼できるようになるまで、7年が経過します。結果としてOOPなどの真のプログラミング革命は、数十年ではないとしても、長年にわたって研ぎ澄まされた技術を生み出しています。ハリウッドでも、一晩でスーパースターになったすべての俳優は、その前に彼が数年間映画を演じていたことがわかります。



並行性は、プログラミングにおける次の大きな革命です。PLO革命と比較できるかどうかについては専門家の意見が異なりますが、これらの論争は専門家に任せましょう。私たちのエンジニアにとって、並列性が規模の点でOOP（予想される）に匹敵すること、およびこの新しいテクノロジーを習得する複雑さと難しさにおいて重要です。

並行性の利点と、それがどれだけ費用がかかるか

並行性、特にマルチスレッドがプログラムの大部分ですでに使用されている理由は2つあります。まず、独立した操作の実行を分離するため。たとえば、私のデータベースレプリケーションサーバーでは、各レプリケーションセッションを独自のストリームに入れるのが自然でした。なぜなら、それらは互いに完全に独立して動作したためです（同じデータベースの同じレコードで動作しなかった場合）。第二に、プログラムが複数の物理プロセッサで実行されるか、もう一方がアイドル状態のときに1つのプロシージャの実行が交互に行われるため、プログラムがより高速に動作するためです。私のデータベース複製プログラムでは、この原則も使用されていたため、プログラムはマルチプロセッサマシン上で適切に拡張されました。



ただし、並行性は支払わなければなりません。明らかな困難はありません。たとえば、はい、ブロックするとプログラムの速度が低下しますが、賢明かつ正しく使用すると、ブロックを使用することで失うよりも、マルチスレッドプログラムの作業を高速化することができます。これを行うには、プログラム内の操作を並列化し、操作間のデータ交換を最小限に抑えるか、完全に破棄する必要があります。



おそらく、アプリケーションの並列化への道の2番目の主な難点は、すべてのプログラムを並列化できるわけではないという事実です。これについては、以下で詳しく説明します。



それにもかかわらず、並列処理の主な難しさはそれ自体にあります。並列プログラミングモデル、つまりプログラマーの頭の中で開発され、彼の助けを借りてプログラムの動作を判断するイメージのモデルは、順次コード実行のモデルよりもはるかに複雑です。



ある時点で並列性の研究に着手する人は誰でも、彼がそれを完全に理解したと信じています。その後、不可解な人種の状況に直面して、彼は突然、完全な理解について話すのは時期尚早であることに気付きます。さらに、プログラマーは並列コードでの作業を学習するため、コードを慎重にテストすれば異常な競合状態を回避できることに気付き、想像上の知識と理解の第2レベルに進みます。しかし、テスト中、実際のマルチプロセッサシステムでのみ発生する並列プログラミングエラーは、単一のプロセッサでコンテキストを切り替えるだけでなく、スレッドが実際に同時に実行され、新しいクラスのエラーを引き起こしてスレッドが実行される通常のマルチプロセッサシステムでのみ発生します。だから、今彼は確かに知っていると思ったプログラマー並列プログラムの作成方法に新たな打撃が与えられます。長時間の集中的なテストでアプリケーションが正常に動作し、クライアントにとって完璧に機能した多くのチームに会いました。ある日、クライアントの1人がマルチプロセッサマシンにプログラムをインストールし、あちこちで不可解な競合状態とデータ破損が発生し始めました。



そのため、最新のプロセッサのコンテキストでは、アプリケーションをマルチコアマシンで動作するためのマルチスレッドアプリケーションに変換することは、プールの横から深い部分にジャンプして泳ぎ方を習得しようとすることに似ています。しかし、たとえあなたのチームが正しい並列コードを書く方法を本当に知っていたとしても、他のトリックがあります：例えば、あなたのコードは並列プログラミングの観点からは完全に正しいかもしれませんが、シングルスレッドバージョンより速く動作しません。通常、これは、新しいバージョンのストリームが互いに十分に独立していないか、共通のリソースにアクセスしていないために発生します。その結果、プログラムの実行は並列ではなく順次になります。繊細さはますます高まっています。



構造プログラミングからオブジェクト指向プログラミングに切り替えるとき、プログラマはまったく同じ困難を抱えていました（オブジェクトとは何ですか？仮想関数とは何ですか？なぜ継承が必要ですか？そして、これらの「何」と「なぜ」に加えて、最も重要なことは正しいプログラムが構築される理由です彼らは本当に正しいですか？）、それはシーケンシャルプログラミングからパラレルプログラミングに切り替えた場合にも当てはまります（「レース」とは何ですか？「デッドロック」とは何ですか？それは何から来て、どのように回避しますか？どのソフトウェアコンソール？正しいプログラミング構造は確かに正しい理由） - 私たちは、これらすべての「何」と「なぜ」、最も重要なことのほかに、メッセージキュー（メッセージキュー）で友達を作るとしなければならない理由ruktsii私の並列プログラムの一貫性を保つため？



今日のプログラマーのほとんどは、並行性に精通していません。同様に、15年前、ほとんどのプログラマーはOOPを理解していませんでした。ただし、特にメッセージ転送とロックベースのプログラミングの概念を十分に理解している場合は、並列プログラミングモデルを学習できます。その後、並列プログラミングはOOPほど難しくなく、かなり馴染みのあるものになることを願っています。あなたとあなたのチームが再訓練にいくらかの時間を費やす必要があることをただ覚悟してください。



（私は意図的に並列プログラミングをメッセージの受け渡しとロックの概念に減らしました。ロックのない並列プログラムを書く方法があります（同時ロックフリープログラミング）。この方法はJava 5および少なくとも私が知っているコンパイラの1つで最高の言語レベルでサポートされていますC ++。ただし、ロックなしの並列プログラミングは、ロックありのプログラミングよりも学習がはるかに難しく、ほとんどの場合、システムおよびライブラリソフトウェアの開発者のみが必要になりますが、各プログラマーは、そのようなシステムとライブラリーは、それらのアプリケーションから利益を得るために機能します。正直なところ、ロックを使用したプログラミングもそれほど簡単で単純ではありません。）

これはすべて私たちにとって何を意味するのでしょうか？

わかったプログラマーにとってこれが何を意味するかについて話を戻しましょう。



1.すでに取り上げた最初の主な結果は、すでに市場に出始めているプロセッサーの帯域幅を100％使用し、今後数年でスコアを修正する場合、アプリケーションを並列化することです。たとえば、Intelは近い将来、100コアのプロセッサを作成すると主張しています。シングルスレッドアプリケーションでは、このプロセッサの1/100の電力しか使用できません。



はい、すべてのアプリケーション（より正確には、アプリケーションによって実行される重要な操作）を並列化できるわけではありません。はい、コンパイルなどの一部のタスクでは、並行性はほぼ完璧です。しかし、他の人のために、いいえ。通常、反例として、1人の女性が赤ちゃんを産むために9ヶ月かかったとしても、9人の女性が1ヶ月で赤ちゃんを産むことができるという意味ではないという一般的なフレーズを思い出します。あなたはおそらくこのアナロジーにしばしば会ったでしょう。しかし、このアナロジーの欺deに気づいていますか？あなたが再びそれについて言及されるとき、簡単な質問をします：「子供に出産する仕事は定義によって並列化できないというこの類推から結論を出すことができますか？」通常、人々はそれに応じて考えて、すぐに「はい、この問題を並列化することはできません。」しかし、これは完全に真実ではありません。もちろん私たちの目標が一人の子供を産むことである場合、並列化することはできません。しかし、できるだけ多くの子供（月に1人の子供）を産むという目標を設定すれば、完全に並列化できます！ですから、本当の目標を知ることは、すべてをひっくり返すことができます。プログラムを変更するかどうか、およびその方法を決定するときは、この目的の原則を忘れないでください。



2.それほど明白ではない結果は、おそらくプロセッサ（CPUバウンド）によりアプリケーションの速度がますます低下することです。もちろん、これはすべてのアプリケーションで発生するわけではなく、これが発生する可能性のあるアプリケーションは明日文字通り遅くなることはありません。それでも、I / Oシステム、またはネットワークやデータベースへのアクセスが原因でアプリケーションの速度が低下した場合、おそらく制限に達しました。これらの分野では、速度はますます高くなっています（ギガビットWi-Fiについて聞いたことはありますか？）そして、プロセッサを加速する従来の方法はすべて使い果たされています。考えてみてください。今は3 GHzでしっかりと立ち往生しています。したがって、プロセッサキャッシュのサイズを大きくしない限り（少なくともいくつかの朗報）、シングルスレッドプログラムは高速に動作しません。この方向でのその他の進歩は、以前ほど大きくありません。たとえば、回路エンジニアがプロセッサパイプラインを仕事で満たし、アイドル状態にならないようにする新しい方法を見つけることはほとんどありません。ここでは、明らかな解決策がすべて発見され、実装されています。市場は、プログラムにより多くの機能を常に要求します。さらに、新しいアプリケーションはより多くのデータを処理する必要があります。より多くの機能をプログラムに導入し始めると、プログラムは並列ではないためプロセッサの能力が不足していることがすぐにわかります。市場は、プログラムにより多くの機能を常に要求します。さらに、新しいアプリケーションはより多くのデータを処理する必要があります。より多くの機能をプログラムに導入し始めると、プログラムは並列ではないためプロセッサの能力が不足していることがすぐにわかります。市場は、プログラムにより多くの機能を常に要求します。さらに、新しいアプリケーションはより多くのデータを処理する必要があります。より多くの機能をプログラムに導入し始めると、プログラムは並列ではないためプロセッサの能力が不足していることがすぐにわかります。



そして、ここには2つのオプションがあります。まず、上記のように、アプリケーションを並行して作り直します。または、最も怠forな場合は、コードを書き直して、より効率的で無駄が少なくなるようにします。 3番目の結論に至ります。3



.効率的で最適化されたコードの重要性は、減少するのではなく、成長するだけです。高レベルのコード最適化を実現できる言語は、第二の人生を迎えます。これを許可しない言語は、競争の新しい条件で生き残り、より効果的で最適化される方法を見つけ出す必要があります。私は長い間、高性能の言語とシステムに対する高い需要があると信じています。



4.最後に、プログラミング言語とソフトウェアシステムは同時実行性を十分にサポートする必要があります。たとえば、Java言語は生まれたときから並行性をサポートしていますが、このサポートでエラーが発生し、マルチスレッドJavaプログラムが正しく効率的に機能するためには、いくつかのリリースで修正する必要がありました。 C ++は、強力なマルチスレッドアプリケーションを記述するために長い間使用されてきました。ただし、この言語の並列性は標準に低下しません（C ++言語のすべてのISO標準では、フローについても言及されておらず、これは意図的に行われました）。したがって、その実装のために、さまざまなプラットフォーム依存ライブラリに頼る必要があります。 （さらに、同時実行性のサポートは完全にはほど遠いです。たとえば、静的変数は一度だけ初期化する必要があり、コンパイラがロックを使用して初期化を示す必要があり、多くのC ++コンパイラがそうしない理由。最後に、C ++にはpthreadやOpenMPを含むいくつかの並行性標準があり、それらのいくつかは暗黙的と明示的の2つのタイプの並行性さえサポートしています。そのようなコンパイラが、シングルスレッドコードを操作して、それをなんとかして並列に変換し、その中から並列化できる部分を見つけることができれば素晴らしいです。ただし、そのような自動化されたアプローチには限界があり、プログラマーによって並列処理が明示的に設定されているコードと比較して、常に良い結果が得られるとは限りません。マスタリーの主な秘密は、ロックを使用したプログラミングであり、マスターするのは非常に困難です。私たちは緊急に、より高度な並列プログラミングモデルを必要としています現代の言語が提供するもの。これについては、別の記事で詳しく説明します。

結論として

まだ実行していない場合は、今すぐ実行します。アプリケーションの設計を注意深く確認し、後でプロセッサの処理能力を必要とするまたは必要とする操作を決定し、これらの操作を並列化する方法を決定します。さらに、今、あなたとあなたのチームは、並列プログラミング、そのすべての秘密、スタイル、イディオムを習得する必要があります。



アプリケーションのごく一部のみが、労力なしで並列化できます。ほとんどの場合、そうではありません。プログラムがプロセッサから最後のジュースを絞り出す場所を正確に知っていたとしても、この操作を並列操作に変えるのは非常に難しいことが判明する場合があります。今それについて考え始めるより多くの理由。暗黙的な並列化を備えたコンパイラーは、部分的にしか役に立ちません;奇跡を期待しないでください;自分で行うよりも、シングルスレッドアプリケーションを並列アプリケーションに変えることはできません。



キャッシュサイズの増加とコード実行の最適化のいくつかの改善により、しばらくの間無料のスープが利用可能になりますが、今日からは春雨とニンジンが1つだけ含まれるようになります。豊富な肉はすべて、追加料金でのみスープに含まれます-追加のプログラマーの努力、追加のコードの複雑さ、追加のテスト。ほとんどのアプリケーションでは、これらの努力が無駄にならないことは安心です。なぜなら、現代のプロセッサの指数関数的な増加を十分に活用できるからです。