CPUの性能

パソコンのパフォーマンスのボトルネックがメモリーからCPUに移って久しくなりました。
いまでは、8GBのRAMくらいはふつうに積まれているので、通常の使い方でメモリーを使い切り、仮想メモリに手を出すことはほとんどありません。
メモリー4GBだと時々使い切ってしまいパフォーマンスが悪くなりますが、ほとんどの場合、8GBで足りているでしょう。
それに、ストレージがハードディスクからSSDになり、何十倍も速くなったので、仮想メモリであっても物理メモリーと大差ないかもしれません。
ということで現在のパソコンのパフォーマンスはCPUによって決まるようになってきたと思います。

私のMCAP-CRシミュレータを使用されている数すくない方の一人（Aさんとします）とシミュレーション計算について、お話する機会がありました。
私は、PCの性能は重視していないので、Linuxで６４ビットのGCCを使えば問題ない、と思っています。
そこで、例のシミュレーションプログラムを走らせると、設計するj実用的な計算ケース数では、たいてい１分以内に完了します。
Windows PCを使うと、３２ビットのコンパイラなので、２倍以上計算時間がかかりますが、それでも大したことはありません。

Aさんは、WindowsPCを使われていますが、32ビット版MinGWでコンパイルした実行ファイルを使っても計算は数秒で終わってしまったそうです。
伺ってみると、CPUはAMDの高性能な１２コアとのことでした。
私がAMD E2-7110（４コア x 1.8GHz）のCPUを搭載したLinux機で、15ケースを走らせてみたら20秒で終わってしまいました。
以前Windows7でMinGWコンパイラを使ってデュアルコアｘ1GHzマシンを使っていたのを思い出すと、意外に速いことに驚きました。
Windowsのフリーのコンパイラには、MinGWがあり、Borland C++コンパイラーというのも使えるはずですが、どちらも、インストール後の手動設定が必要なのでふつうは敷居が高いと思います。
WindowsでC++のプログラミングをするには、Windows用の32ビットコンパイラを使うよりは、VMWare等の仮想環境を利用して、そこに64ビットのLinuxを構築し、GCCを使うほうが実行速度が速いです。
Linuxだと、大抵のディストリビューションで、GCCが標準インストールされるし、標準で入っていなくても、コマンドを打ち込むだけでインストールできるので、正直云ってWindowsより敷居がずっと低いと思います。
仕事以外でプログラミングをする人は少数だと思うのでこれでもいいのでしょうけど。

私は、最近は、４コアのCPUを使用することにしています。
２コアだと、Windowsには厳しいし、仮想マシンをインストールすると更に厳しくなるからです。
２コアCPUのノートマシンを使っていたときは、常にCPUが１００％負荷の状態になり心的ストレスがたまったので、いまは４コアが標準です。
８年くらい前のAMD245eの２コアPCを実家の作業場に置いて使っていますが、そちらはデスクトップPC用だけあって、そんなにストレスで困りません。
AMD245eマシンのOSがFedora Core 30 (FC30)なので比較的軽やということもあります。

いま主に使用しているのは、FC30の、CPUは、AMDのE2-7110（４コア）と、FC29の、CPUは、Celeron N3450（４コア）です。
仕事用には、Windowsは、AMD E2-7110搭載のFC30マシンの中の仮想マシンとして使用しています（OEM版のライセンスでは使えないので買い足したリテール版...）。
決して速くはありませんが、困るほど遅いわけではないので、これでいいのでしょう。

PCで、プログラミングのようなクリエイティブな作業をしているときは、殆どがアイドリング状態です。
考えている間はPCに計算させる訳ではないので、CPU時間は決して長くありません。
いざプログラムが走る状態になって、デバグを含め、計算するときに、初めてCPUコアのひとつが１００％負荷に近くなります。
こう考えると、CADソフトのように常時CPU負荷の大きなソフトを使用するのでなければ、高性能CPUのメリットは、享受できません。
でも私の64ビットLinux PCで20秒かかるものを、32ビットコンパイルのWindows PCで数秒で計算してしまうCPUというのは、おそるべき性能なのでしょう。
そういうCPUがあれば、安くなったメモリーを追加すれば流体力学の３次元問題もどんどん解いていけそうです。
いまや大学の研究室でもタイムシェアのメインフレームよりもパソコンで計算するほうが速いのだろうと思います。
こういう環境のほうがいい研究成果を出せるのか、というとそういうわけでもないのですけど。

プログラムを作成する人（職業プログラマというより研究者）は、計算時間を短くするために、アルゴリズムを工夫します。
重複処理を排除して計算ステップ数を減らし、反復計算の場合には、最小回数で収束するようにアルゴリズムを見直します。
また、メモリが不足する場合にはCPU計算でカバーするアルゴリズムにしますが、メモリが十分にあれば、メモリー空間を広く使ってデータアクセスの時間を節約するようにプログラミングします。
たとえば、流体力学の計算をするには、要素数にもよりますが、数千元とか数万元以上の連立線型方程式を解きますが、メモリが高価な時代には、小さく分割して繰り返しでこつこつと解いていたりしましたが、いまでは、メモリがいくらでもというくらい使えるので、メモリ空間に巨大な連立方程式をマップして一気に解くのかもしれません。
そうなると、かつて主流だったFORTRANの配列で対応できそうにありませんが、いまは、メモリーを上手に使うライブラリがあるのでしょう。
Cだとmallocで必要な分だけメモリーをダイナミックに割り当てられるので、いまのFORTRANはそういうことができるのでしょうか？

最近のソフトを見ていると、大した計算をしていなくても処理が遅かったりするので、こうした処理上の工夫は重視していないように思えます。
アルゴリズムを極めたソフトは、処理が必要と思えるところには時間がかかりますが、それ以外は素早いし、フリーズしたかと心配になるようなことはありません。
しかし、フリーズしたかと思わず処理を中断してしまうようなソフトは多いと感じます。
自分のシミュレーションプログラムでさえ、フリーズの心配をしなくて済むよう計算経過を表示するようにしていますが、フリーズしたかと心配させるソフトをつくる職業プログラマーって何だろう？
こういうのは、文化の差なのかなあ？

高速CPUも使ってみたい気がします。
仕事が儲かったら使ってみようと思います。
でもLinuxを使っている自分には、パソコンの高速化って優先順位が低いんですよね。
ということは永遠に無理か．．．