NiklausWirth教授は正しかった。Pascal言語の作成者、構造化プログラミングテクノロジーの共著者、および1995年のTuring Prize受賞者は、次のように述べています。

「プログラムの速度を落とすのは、コンピューターを高速化するよりもはるかに高速です」

それ以来、この声明はワースの法則と見なされてきました。これは、プロセッサ内のトランジスタの数が1965年頃から2倍になったというムーアの法則を事実上否定します。Wirthが記事「 CallforSlimSoftware 」に書いていることは次のとおりです。

「約25年前、インタラクティブなテキストエディタはわずか8000バイトで、コンパイラは32キロバイトでしたが、最近の子孫はメガバイトを必要とします。この肥大化したソフトウェアはすべて速くなりましたか？いいえ、まったく逆です。1000倍高速なハードウェアがなければ、最新のソフトウェアは完全に使用できなくなります。」

これに異議を唱えるのは難しい。

肥満ソフトウェア

最新のソフトウェアを開発する際の問題は非常に深刻です。ワースは1つの重要な側面を指摘しています：時間。彼は、肥大化したソフトウェアの主な理由は開発時間の不足であると示唆しています。



今日、ソフトウェアの肥満には別の理由があります。それは抽象化です。そして、これははるかに深刻な問題です。開発者が最初からプログラムを作成したことはありませんが、これが問題になることはありません。



DijkstraとWirthは、コードの品質を改善しようとし、構造化プログラミングの概念を開発しました。彼らは危機からプログラミングを取り除こうとしました、そしてしばらくの間、プログラミングは本当の専門家のための本当の技術として見られました。プログラマーはプログラムの品質に気を配り、コードの明快さと効率を高く評価しました。



当時は終わりました。



Java、Ruby、PHP、Javascriptなどの高レベル言語の台頭により、Wirthが記事を書いた1995年までに、プログラミングはより抽象的なものになりました。新しい言語はプログラミングをはるかに簡単にし、多くのことを引き受けました。それらはオブジェクト指向であり、IDEやガベージコレクションなどにバンドルされていました。



プログラマーは生活しやすくなりましたが、すべての費用を支払う必要があります。住みやすいほど、考えることは少なくなります。 90年代半ば頃、プログラマーはプログラムの品質について考えるのをやめ、開発者のロビン・マーティンは彼の記事「ニクラウス・ワースは正しかった、それが問題だ」と書いています。同時に、ライブラリの普及が始まり、その機能は常に特定のプログラムに必要以上のものになっています。



ライブラリは特定のプロジェクト用に構築されていないため、実際に必要な機能よりも少し多くの機能を備えている可能性があります。問題ありません、あなたは言います。ただし、状況はすぐに加算されます。図書館を愛する人々でさえ、車輪を再発明したくありません。これは、いわゆる依存地獄につながります。 Nicola Duzaは、この問題に関する投稿をJavascriptで作成しました。



問題は大したことではないように見えますが、実際にはあなたが思っているよりも深刻です。たとえば、NikolaDusaは簡単なやることリストアプリを作成しました。 HTMLとJavascriptを使用してブラウザで動作します。いくつの依存関係が使用されたと思いますか？ 13,000。13。千。証明。



数字は非常識ですが、問題は拡大するだけです。新しいライブラリが作成されると、各プロジェクトの依存関係の数も増加します。



これは、1995年にNiklausWirthが警告した問題が時間の経過とともに悪化することを意味します。



何をすべきか？



ロビン・マーティンは、始めるための良い方法はライブラリを分割することであると提案しています。最善を尽くす1つの大きなライブラリを構築する代わりに、多くのライブラリを作成するだけです。



したがって、プログラマーは、使用しない機能を無視して、本当に必要なライブラリーを選択するだけで済みます。インストールする依存関係自体が少なくなるだけでなく、使用されるライブラリの依存関係も少なくなります。

ムーアの法則の終わり

残念ながら、トランジスタの小型化は永遠に続くことはできず、物理的な限界があります。おそらく遅かれ早かれ、ムーアの法則は機能しなくなるでしょう。これはすでに起こっていると言う人もいます。過去10年間で、個々のプロセッサコアのクロック速度と電力は、以前のようにすでに成長を停止しています。



彼を埋葬するには時期尚早ですが。シリコンマイクロエレクトロニクスに取って代わることを約束する多くの新しい技術があります。たとえば、Intel、Samsung、およびその他の企業は、カーボンナノ構造（ナノワイヤー）に基づくトランジスターやフォトニックチップを実験しています。





トランジスタの進化。イラスト：サムスン



しかし、一部の研究者は異なるアプローチを採用しています。彼らは、将来のソフトウェアの効率を劇的に改善するためのプログラミングへの新しいシステムアプローチを提案しています。したがって、プログラムの肥満に関するNicklaus Wirthの観察に照らして、ムーアの法則がどれほど素晴らしく聞こえても、プログラムの方法によってムーアの法則を「再開」することが可能です。しかし、この傾向を逆転させることができたらどうでしょうか？

ソフトウェアアクセラレーションテクニック

最近、Scienceは、マサチューセッツ工科大学（CSAIL MIT）のコンピューターサイエンスおよび人工知能研究所の科学者による興味深い記事を発表しました。それらは、計算をさらに加速するための3つの優先分野を強調しています。

• 最高のソフトウェア。
  
  
• 新しいアルゴリズム;
  
  
• より最適化されたハードウェア。

科学的研究の筆頭著者であるCharlesLeisersonは、ソフトウェア論文の肥満を確認しています。彼は、トランジスタを小型化することの利点は非常に大きいため、プログラマーは何十年もの間、実行を高速化するのではなく、コードを書きやすくすることを優先することができたと言います。より高速なコンピューターチップが常にソフトウェアの肥満を補うため、非効率性は許容できます。



「しかし、今日では、機械学習、ロボット工学、仮想現実などの分野でのさらなる進歩には、小型化ではもはや提供できない膨大な計算能力が必要になります」とLeiserson氏は言います。 「これらのテクノロジーの可能性を最大限に活用したいのであれば、コンピューティングへのアプローチを変える必要があります。」



ソフトウェアの部分では、これが非効率の原因であるため、過剰な機能を備えたライブラリを使用する戦略を再検討することが提案されています。著者は、コードの記述速度ではなく、プログラム実行の速度を上げるというメインタスクに集中することを推奨しています。



多くの場合、パフォーマンスは実際に何千倍も向上する可能性があり、これは誇張ではありません。例として、研究者は2つの4096×4096行列の乗算を引用しています。彼らは、最も人気のある高レベル言語の1つとしてPythonを実装することから始めました。たとえば、Python2での4行の実装を次に示します。

for i in xrange(4096):
for j in xrange(4096):
for k in xrange(4096):
C[i][j] += A[i][k] * B[k][j]

コードには3つのネストされたループがあり、ソリューションアルゴリズムは学校の代数カリキュラムに基づいています。



しかし、この素朴なアプローチは、計算能力には非効率的であることがわかりました。次の表に示すように、最新のコンピューターでは、約7時間実行されます。





より効率的なプログラミング言語への移行により、コード実行の速度がすでに劇的に向上しています。たとえば、JavaプログラムはJavaより10.8倍速く実行され、CプログラムはJavaよりさらに4.4倍速く実行されます。したがって、PythonからCに切り替えると、プログラムの実行が47倍速くなります。



そして、これは最適化の始まりにすぎません。実行されるハードウェアの特性を考慮してコードを作成すると、速度をさらに1300倍にすることができます。この実験では、コードは最初に18個のCPUコアすべて（バージョン4）で並行して実行され、次にプロセッサキャッシュ階層（バージョン5）を使用し、ベクトル化（バージョン6）を追加し、バージョン7で特定のAdvanced Vector Extensions（AVX）命令を適用しました。最新の最適化バージョンコードの所要時間はわずか0.41秒で、7時間ではありません。つまり、元のPythonコードの60,000倍以上高速です。



さらに、AMD FirePro S9150グラフィックカードでは、同じコードがわずか70ミリ秒で実行され、汎用プロセッサで最も最適化されたバージョン7の5.4倍、バージョン1の360,000倍高速です。



アルゴリズムの観点から、研究者は、新しい問題領域の調査、アルゴリズムのスケーリング、および最新のハードウェアをより有効に活用するためのそれらの適応を含む3つのアプローチを提案します。



たとえば、マトリックスをさらに10％乗算するStrassenのアルゴリズムは、コード番号7の最速バージョンを高速化します。他の問題については、新しいアルゴリズムによってさらにパフォーマンスが向上します。たとえば、次の図は、1975年から2015年の間に最大フローの問題を解決するためのアルゴリズムの効率の向上を示しています。新しいアルゴリズムはそれぞれ、文字通り数桁の計算速度を向上させ、その後数年でさらに最適化されました。





N = 10でグラフ上の最大流量の問題を解決するためのアルゴリズムの効率¹²の頂点とM = N ^11の縁



したがって、アルゴリズムを改善することもムーアの法則を、プログラム「エミュレート」に寄与する。



最後に、ハードウェアアーキテクチャの観点から、研究者はハードウェアを最適化して、より少ないトランジスタで問題を解決できるようにすることを提唱しています。最適化には、より単純なプロセッサの使用と、GPUがコンピュータグラフィックスに適合しているなど、特定のアプリケーションに合わせたハードウェアの作成が含まれます。



「特定の領域に合わせた機器は、はるかに効率的で、使用するトランジスタがはるかに少ないため、アプリケーションを数十倍または数百倍速く実行できます」と、研究論文の共著者であるTaoSchardl氏は述べています。 「より一般的には、ハードウェアの最適化は、並列使用のためにチップ上に追加の領域を作成することにより、並列プログラミングをさらに刺激します。」



並列化の傾向はすでに見られます。図に示すように、近年、コア数の増加だけでCPU性能が向上しています。





1985年から2015年までの個々のコアとシングルおよびマルチコアプロセッサのSPECintパフォーマンス。ベースユニットは198580386DXマイクロプロセッサです



データセンターの運営者にとって、ソフトウェアのパフォーマンスのわずかな改善でさえ、大きな経済的利益につながる可能性があります。当然のことながら、GoogleやAmazonなどの企業は現在、独自の専用CPUを開発するためのイニシアチブを主導しています。最初にリリースされたGoogleTPUテンソル（ニューラル）プロセッサとAWSGravitonチップがAmazonデータセンターで実行されています。



時間の経過とともに、効率で競合他社に負けないように、業界のリーダーに他のデータセンターの所有者が続く可能性があります。



研究者は、過去に、汎用プロセッサでの爆発的なパフォーマンスの向上が、特殊なプロセッサの開発の範囲を制限していたと書いています。現在、そのような制限はありません。



研究の共著者であるチャールズ・ライザーソン教授は、次のように述べています。 「それはまた、プログラマーがソフトウェア、アルゴリズム、ハードウェアを個別に見るのではなく、それらがどのように組み合わされているかをよりよく理解する必要があることを意味します。」



一方、エンジニアはCPUパフォーマンスをさらに向上させることができるテクノロジーを実験しています。これらは、量子コンピューティング、3Dレイアウト、超伝導マイクロ回路、ニューロモーフィックコンピューティング、シリコンの代わりにグラフェンを使用することなどです。しかし、これまでのところ、これらのテクノロジーは実験段階にあります。



CPUのパフォーマンスが実際に向上しなくなった場合、私たちはまったく異なる現実に直面することになります。おそらく、私たちはプログラミングの優先順位を本当に再考する必要があり、アセンブラーのスペシャリストは金で彼らの重みの価値があるでしょう。

---

広告

強力なサーバーが 必要ですか？当社は、AMD EPYC CPU、最大3.4GHzのCPUコア周波数を備えた仮想サーバーである壮大なサーバーを提供しています。最大構成は誰にでも印象的です-128CPUコア、512 GB RAM、4000 GBNVMe。