2005年3月、Herb Sutterは有名な記事「The Free Lunch Is Over」（無料の昼食は終わった）を発表し、オブジェクト指向革命に匹敵するほど大きな並行プログラミング革命を予測しました。この予測の背後にある動機を説明する記事からの短い抜粋を紹介します。
IntelやAMDからSparcやPowerPCまで、主要なプロセッサメーカーとアーキテクチャは、CPUパフォーマンスを向上させる従来のアプローチのほとんどで限界に達しています。クロック速度と直線的な命令スループットをさらに高めるのではなく、彼らは 一斉に ハイパースレッディングとマルチコアアーキテクチャに向かっています。これらの機能はどちらも現在のチップですでに利用可能です。特にマルチコアは、現在のPowerPCおよびSparc IVプロセッサで利用可能であり、2005年にIntelとAMDから登場します。実際、2004年のIn-Stat/MDR Fall Processor Forumの大きなテーマはマルチコアデバイスであり、多くの企業が新しいまたは更新されたマルチコアプロセッサを展示しました。振り返ってみると、2004年をマルチコアの年と呼ぶのはそれほど無理ではありません。
今日、ムーアの法則は永遠に続かないことがわかっています。 こちら
で説明されているように。
同時に、プロセッサメーカーは新しい世代のプロセッサごとにコアを追加し続けています。例えば、 Intel E7 Xeonファミリー は24コアを搭載しています。
Herb Sutterの予測に戻ると、彼は次のように言っています。
並行処理は、私たちがソフトウェアを書く方法における次の大きな革命です。
そして
アプリケーションは、継続的な指数関数的なCPUスループットの向上を最大限に活用したいのであれば、ますます並行処理が必要になるでしょう。効率性とパフォーマンスの最適化は、減るのではなく増えていくでしょう。
彼の予測から13年後、並行処理は本当に私たちのソフトウェアの書き方に革命をもたらしたのでしょうか？それとも、この革命が展開するのをもう数年待つ必要があるのでしょうか？
マルチスレッディングとマルチコアシステムでの作業は容易ではなく、多くの開発者が大きな課題に直面していることがわかっています。開発者フォーラムをざっと見ると、次のようなフィードバックが見られます。
I am a fairly good programmer, my boss is also a fairly good programmer. Though he seems to underestimate some tasks such as multi-threading and how difficult it can be (I find it very difficult for anything more than running a few threads, waiting for all to finish, then return results).
The moment you start having to worry about deadlocks and race conditions, I find it very difficult, but the boss doesn't seem to appreciate this - I don't think he has ever come across this. Just slap a lock on it is pretty much the attitude.
So how can I introduce him, or explain why he might be underestimating the complexities of concurrency, parallelism, and multi-threading? Or maybe I am wrong?これはまさにHerb Sutterが彼の記事で指摘したことです。
今日のプログラマーの大多数は並行処理を理解していません。ちょうど15年前のプログラマーの大多数がまだオブジェクトを理解していなかったように。しかし、並行プログラミングモデルは習得可能であり、特にメッセージベースとロックベースのプログラミングに固執すれば、一度理解すれば、それはオブジェクト指向よりもそれほど難しくなく、うまくいけば同じように自然になれるでしょう。準備を整え、あなた自身とチームのために、トレーニングと時間への投資を見込んでおいてください。
開発者は現在、並行処理の利点を認識しているのでしょうか？プロジェクトは並行処理を最大限に活用するように設計されているのでしょうか？それとも、効率的な並行コードを設計するために依然としてエキスパートが必要なのでしょうか？ 革命はここにあるか？
はい、革命はここにありますが、それは開発者だけによって推進されたものではありませんでした。それは数年前に新しいプログラミング言語、そして確立された言語向けの新しいライブラリや標準とともに始まりました。開発者は、並行処理を最大限に活用しやすくする言語を必要としています。低レベルAPIだけに依存するのは通常悪い考えであり、多数のバグやその他の問題をもたらす可能性があります。
Rust、Go、Clojureは、並行処理を念頭に設計されたモダンな言語の例です。
これがRustのスローガンです。
Rust は、非常に高速に動作し、セグメンテーションフォールトを防ぎ、 スレッド安全性を保証する。
システムプログラミング言語です。
Clojureは動的な汎用プログラミング言語で、スクリプト言語の親しみやすさとインタラクティブな開発を、 マルチスレッドプログラミングのための効率的で堅牢なインフラストラクチャ。
と組み合わせています。
これらの新しい言語は人気を集めていますが、C、C++、Java、C#などの確立された言語と競合するのは依然として困難です。しかし、これらの確立された言語は、長年にわたって、開発者が並行処理を活用して効率的な並行コードを書くのに役立つ機能やライブラリを獲得してきました。これはHerb Sutterが彼の記事で指摘したことです。 プログラミング言語とシステムは、並行処理をうまく扱うことをますます強いられるでしょう。。
例えば、Microsoft® .NET Framework 4は、利用可能なすべてのCPUコアを利用してアプリケーションコードを並列に実行し、C#プログラムのパフォーマンスを向上させる並列プログラミングモデルを導入しました。.NET Frameworkの新しいバージョンごとに、マルチコアプログラミングを容易にする機能が追加されました。
C++について、Herb Sutterは当時、並行処理の標準化されたサポートがまったくないと指摘していました。
C++言語は長い間、高負荷なマルチスレッドシステムをうまく書くために使用されてきましたが、並行処理の標準化されたサポートがまったくありません（ISO C++標準はスレッドにさえ言及しておらず、それは意図的です）。したがって、通常、並行処理は必然的に、移植性のないプラットフォーム固有の並行処理機能やライブラリを使用して実現されます。（また、しばしば不完全でもあります。例えば、static変数は一度だけ初期化される必要があり、通常はコンパイラがそれらをロックでラップする必要がありますが、多くのC++実装はロックを生成しません。）
幸いなことに、2011年に始まったC++ルネサンスは、開発者にマルチスレッドおよびマルチコアプログラミングを容易にする多くの便利な機能を提供してきました。
要約すると、革命はすでにここにあります。新しいプログラミング言語の設計と、確立された言語への新機能の追加の両方においてです。あとは開発者がこれらの機能を探索し、効果的に使用する番です。心配しないでください。並行プログラミングは以前ほど怖くはありません。
最終的に、Herb Sutterは正しかったのです。彼の長年の専門知識を考えれば、それはほとんど驚くべきことではありません。彼はまた、2011年以降、C++11標準から始まる便利な並行処理機能の開発に大きく貢献してきました。