[Top]

高速化手法

目次（高速化）
高速化手法１
高速化手法２
高速化手法３
高速化手法４
高速化手法５
高速化手法６
高速化手法７（一覧）
高速化手法８
高速化手法９
高速化手法Ａ
高速化手法Ｂ

高速化手法５ [先頭 ][手法８]

最近（６／１０、１９９８）、事情があって複数のメーカーのマシン（ワー クステーションサーバークラス）のベンチマークが行なえました。これによっ て筆者の持つプログラムの問題もいくつか明らかになりました（ベンチマークに関わった各社技術陣、ＳＥ等に深く感謝し ます）。

その詳細はここでは事情により述べられないのですが、プログラムの高速化 に関しては非常に有用な情報を得ました。

筆者のプログラムではＭＦＦＴをずっ と使い続けていますが、このＦＦＴ（高速フーリエ変換）部分が、バンド計算 全体の半分以上を占めていたことは大分以前から判っていました。ＭＦＦＴは もともとベクトル計算機であるクレイ用に作られたもので、ベクトル計算機 （スーパーコンピューター）では性能を発揮できますが、ワークステーション のようなスカラーマシンではあまり高速ではないことが容易に想像できます。

今回のベンチマークで、このＦＦＴルーチンを他のライブラリのものに変更 してくれたところがいくつかあり、これによりＦＦＴ部分の計算量が大幅に減 少することが判明しました。正確な数値はここで明かすことはできないのです が、少なくともＦＦＴ部分だけでも数倍高速化されます。全計算量の半分以上 を占める部分が、数倍短縮されれば全体の計算量も大幅に軽減することが可能 となります。

ＦＦＴ部分を替えて、大幅に高速化できたという話は、以前から聞いてはい たのですが、これほど顕著であるとは思ってもい ませんでした。ただ問題は、これで汎用性は落ちてしまうことになります。そ のメーカー、会社独自のライブラリのルーチンを使用した場合、他のメーカー のマシン上での性能向上は保証されません（というより、ソース公開でもして いない限り、他のメーカーのマシン上では使えない）。従って、独自の高速ラ イブラリを用意できないメーカーのマシンを使用している場合は、このような 恩恵には与れないことになります。

擬ポテンシャル＋平面波（ＦＦＴ使用）によるバンド計算で、使用するマシ ン上で高速なライブラリが用意されているようだったら、そのライブラリ上の ルーチンを試してみるのも一考かと思います。あまりお薦めできる手ではない （相手側に多大な負担をかける可能性がある）ですが、今回行なったようなベ ンチマークテストを利用するというのもあります（そうそうそのような機会は ないですが、エンドユーザーにとっては非常に有用な高速化に関しての情報を 得られる可能性が多分にある。またこれだけでは高速化されるという情報しか 得られないです〔その手のライブラリルーチンのソースが公開されている可能 性は皆無に等しいから〕）。

高速化手法６ [先頭 ]

最近（６／１０、１９９８）、多くのワークステーションサーバーがＳＭＰ 対応（Symmetric Multi Processing：要は共有メモリ型のこと）になっていま す。そしてメモリ共有のため、大抵は自動並列化が可能となっています（自動 並列化対応ＦＯＲＴＲＡＮコンパイラが必要）。バンド計算プログラムの高速 化手法として、並列化による方法（[ＶＰＰ]、 [ＳＸ]による並列化参照）は有用な選択肢 の一つです。

ではＳＭＰマシン上での自動並列化はどうでしょうか（共有メモリとすれば ＮＥＣのＳＸも含まれる）？

結論から言うと、現時点では筆者のバンド計算プログラムを、自動並列化さ せて動かしたとしても、ほとんど並列化による高速化の効果はありません。少 ないＣＰＵ数（２個程度）ではむしろ遅くなる 場合すらあります。もっとＣＰＵ数が多くても、８ＣＰＵ並列でも１ＣＰＵの 場合と比べて２倍にすら高速化できません。全く計算プログラム本体に修正を 加えないでの高速化はほとんど望めないと言えます。

これは最近、幾つかのＳＭＰマシンでベンチマークを行なうことができ、そ の結果どのマシンでもソースコードを無修正で自動並列化した場合では、どこ も並列化による効果がほとんど得られなかったことから判明しました（これは あくまで筆者のバンド計算用コードに関しての場合であり、結果です）。

無修正のままでの自動並列化では駄目ですが、並列化指示行による手動並列化では、高速化の効果が 顕著に現われます（ベンチマークで行なってもらったところがありま す）。自動並列化では一番内側のループが並列化の対象になりますが、バンド 計算プログラムでは最も外側のｋ点に関してのループを並列化対象にすると、 最も効率良く並列化が行なえます（但し、ｋ点数を十分に確保できる場合）。

現段階では、自動並列、手動並列の効果の差や、実際の高速化の度合は事情 によりここでは明かせませんが、手動並列に関してOpenMPなる共通仕様が提案されています （既に利用可能なシステムもあり）。

高速化手法７ [先頭 ]

思いついた方法を、これまで紹介したものを含めて列挙してみます。
  1. より速いマシンを導入する、使えるようにする、借りる。
  2. 並列マシンを導入する、使えるようにする、借りる（要並列対応プログラム、高速化 手法６参照）。
  3. 誰かに速くしてもらう。業者に依頼する（高 いかも）。
  4. ベンチマークテストを利用する（余りいい手ではないが、非常に有効な場合あり） 。
  5. スカラー計算の場合、キャッシュのヒットミスを少なくさせる（すぐ上のベンチマークを利用する手がある）。
    スカラー計算機では、”ストリップマイニング”という手がある（これの使い方は実はよく理解していない^^;）。
    他にループ交換、ループアンローリング（ループの展開）、ループタイリン グ、プリフェッチなどという手がある（詳細は調査中）。これらは、ディレク ティブ（注釈行形式の指示行）としてプログラム内に挿入可能である（システ ムやOSに依存する）。但し、実際の使用には注意が必要である。
  6. ベクトル計算機ではバンクコンフリクトをしないようにする（例：配列定義を１０２４ではなく、１０２５〔２で割り 切れない数にする〕にするなど）。←スカラー計算機でもこの問題は 重要で、パラメーターの値が２の巾乗にはな らないように注意する必要がある。
  7. もっと速いプログラムを入手する（不正入手不可） 、（無断不可）借りる。
  8. 速くなりそうだったら、コンパイラをバージョンアップしてみる（可能なら）。
  9. より速い（主に数値演算）ライブラ リのルーチンを探し出して利用する（ＦＦＴ、対角 化など、高速化手法５参照 ）。
  10. 半導体メモリーの使用（高速化手法１前半参 照）。
  11. 系の対称性を利用（ 高速化手法１後半参照）。
  12. より収束が速いアルゴリズムの採用（最急降 下〔ＳＤ〕法より共役勾配〔ＣＧ〕法など）。
  13. 画期的なアルゴリズム、方法を発見、開発する（難しい）。
  14. 高速化手法３の方法。
  15. 高速化手法４の方法。
  16. 作業用変数を多用して無駄な計算をしないようにする（例：同じ計算を別のとこ ろでやらないようにする。但しメモリーは損） 。
  17. 時間刻み幅等の調節、波動（基底）関数の予測（例：アライアスの方法） 。
  18. 前処理の導入（ＣＧ法、ＳＤ法）。
  19. 共役勾配法（ＣＧ法）では部分対角 化が収束を早めるのに有効（←と言うか必須。新井さ ん情報感謝）。
  20. Lowdinの摂動の導入（おそらく有効なのは電子状態まで）。
  21. 擬ポテンシャルを変える（ＢＨＳからTroullier and Martin型へ、Ultra-soft型へ）。
  22. より収束が速くなるように初期電荷や初期の固有値、波動関数を工夫す る。
  23. 筆者Ｄ論のAppendix Cの方 法
  24. （過去と現在の）電荷密度の混合方法を変える（単純混合から[ブロイ デン法]、[Kerkerの方法]等）。
  25. 大きな系では、バンド間の直交化をしない （Mauri and Galli[6,7]の方法）
  26. コンパイラオプションを駆使する（うまく選 べば速くなる可能性あり）。
  27. 可能ならカーネルパラメーターを最適なものに変更する（共通的に使わ れるマシンでは難しいかも）。
  28. とにかくメモリーを沢山載せたマシンを利用する（スワップ回避のため）。
  29. ディスクアクセスはなるべく避ける。
  30. 小さめのマシンを駆使する（大きなマシンで １週間ジョブ待ちするより、小さな自分専用マシンで１週間で計算できれば、 後者の方が実質的には同等か、より速いことになる）。
  31. 本当に必要な計算だけやる（意外と無駄な計 算をやっていることが多い）。
  32. だらだらと計算せず、事前に良く研究計画を練って計算に臨む（本当はこれが一番効果的^^;）。
  33. 諦める(^^;)。
（参考例）
（７／１４、１９９８）ＣＰＵ（ＤＥＣマシン）が２倍程速いマシンを使用 （上記項目１）して、更にＦＦＴをＭＦＦＴ からＤＥＣのＤＸＭＬライブラリのものに替えて更に２倍高速化を実現（上記項目９）、合わせて（相乗的に）４倍の性能 向上を実現（遅いマシン上で、かつＭＦＦＴのままとの比較、大体の値です）。
（５／１３、２００４）（上記項目９）： 今年度新たに機構に導入（機種更新）された、日立のSR11000用に筆者のプロ グラムを少し変更してみました。まず、MFFT→HZFT7M（３次元の複素数に対す る高速フーリエ変換ルーチン、MATRIX/MPP：日立の科学技術計算ライブラリ） とすることにより、MFFT使用時に約137000秒かかっていた筆者のバンド計算プ ログラムの計算時間が、約67350秒に減りました。更に固有値問題のルーチン も同じくMATRIX/MPPのHZES1Mに替えることにより、更に約1000秒時間を短縮で きました。対角化（固有値問題）は、最初の１回目のイタレーションしか行な わないので、時間短縮の効果はFFTほどではありませんでした。それでもその マシン（メーカー）専用のルーチン（ライブラリ）の使用は非常に有効である と言えます。特に通常のバンド計算ルーチンは、FFTを多用するので効果が絶 大となる可能性が高いです。【参考】：日立や富士通の科学技術数値演算ライ ブラリ利用のためのラッピング[ルーチン]

（スカラーチューニングに関する参考ページ）
青山氏によるスカラー・チューニング、並列プログラミングに関する[テキスト]（理研、 情報基盤センター）にある、「スカラーチューニング技法入門」。

高速化手法８ [先頭 ][手法５]

ＦＦＴ部分を取り替えることで、筆者のバンド計算プログラムは大変速くな るを先の高速化手法５でお話したと思います。

今回（６／２５、１９９８）、ベンチマークではなく、筆者自身もＦＦＴの 換装によって高速化を実体験しました。筆者が使用している計算環境にはＤＥ Ｃの計算サーバーがあるのですが、これにはＤＸＭＬ（Digital Extended Math Libraryの略、ＤＥＣ製品）という科学技術計算ライブラリがインストー ルされていました。これには３次元の複素数に対応したＦＦＴルーチンが存在 します。これをＭＦＦＴの代わりに使え るように同僚の新井さんが代替するルーチンを作ってくれました。

以下にそのルーチンを示したいと思います。 

      subroutine c3fft_dxml(c,id,n1,n2,n3,isig)
      implicit real*8 (a-h,p-z), integer (o)
      include '/usr/include/DXMLDEF.FOR'
      complex*16 c(id,n2,n3)
      complex*16, dimension(:,:,:),allocatable :: cnew
      external zfft_3d

      if ( isig .eq. 0 ) return

      allocate(cnew(id,n2,n3))

      if ( isig .eq. -1 ) then
c-------< direct transfromation >----------
         ierr = zfft_3d('C','C','F',c,cnew,n1,n2,n3,id,n2,1,1,1)
      else if ( isig .eq. 1 ) then
c-------< backward transfromation >----------
         ierr = zfft_3d('C','C','B',c,cnew,n1,n2,n3,id,n2,1,1,1)
      endif

      do i3 = 1, n3
         do i2 = 1, n2
            do i1 = 1, n1
               c(i1,i2,i3) = cnew(i1,i2,i3)
            enddo
         enddo
      enddo

      if (ierr .ne. 0) write(*,*) 'zfft_3d called improperly'

      deallocate(cnew)
      
      if (isig .lt. 0) return
C ... Renormalize backward transform 
      scale = dble(n1*n2*n3)
      do  10  i3 = 1, n3
      do  10  i2 = 1, n2
      do  10  i1 = 1, n1
   10 c(i1,i2,i3) = scale*c(i1,i2,i3)

      return
      end
このルーチンの使用によって生じる如何なる障害、不 都合、損害、被害等に関して、製作者の新井、 及び筆者、無機材研は一切責任を負えません。

本ページに掲載を快諾してくれた新井さんに深く感謝します。

このルーチンは、c3fft_dxml(c,id,n1,n2,n3,isig)というサブルーチンを介 して、ＤＸＭＬ用の３次元複素フーリエ変換ルーチンにデータを引き渡してい ます。元々のＭＦＦＴ使用時でのサブルーチン呼び出しは、 

      CALL C3FFT(ZRB,KFT1,KFT1-1,KFT2,KFT3,IWL,IWM,IWN                  
     &          ,0,0,1,IWORK,IERR)
で、ＤＸＭＬ用が、 

      c3fft_dxml(c,id,n1,n2,n3,isig)
です。ZRB -> c、KFT1 -> id、KFT1-1 -> n1、KFT2 -> n2、 KFT3 -> n3、２行目の, 0,0,1の真中の数字 0 -> isigにそれぞれ対応しています。IWL、IWM、IWN、IWORK、IERR、両隣の0と1はＤＸＭＬでは使用しません。

このc3fft_dxmlルーチンは実はFORTRAN90仕 様で使用される命令が使われています。従って、コンパイルはf77ではなく f90で行なう（ＤＥＣの場合）必要がありま す。コンパイルの仕方は、このc3fft_dxmlルーチンを新たに導入したプログラ ムをrevpe_dx.fとして、

f90 -r8 -O5 revpe_dx.f -ldxml

で無事にコンパイルできます。

実際に実行させてみると、大体従来（ＭＦＦＴを使ったもの）のものと比べ て１．５倍以上の高速化が計られています。

このプログラムrevpe_dx.fは、上記c3fft_dxmlのルーチン内のみが FORTRAN90仕様の命令を使っています。これ以外の部分は全て従来通りの FORTRAN77で記述されています。それでも、FORTRAN90仕様のコンパイラである f90でコンパイルしても、何ら問題なく動いています（但し、このプログラム には最新のＤＥＣコンパイラに対して若干 問題があります）。

（７／２、１９９８）更に新井さんはＦ ＦＴＷを使用するとＤＸＭＬより更に高速化することを見い出しました （新井氏による）。ＭＦＦＴと換装するためのルーチン（c3fft_fftw_.c： 〔現在閉鎖中〕）があります。これのフォートランプログラム側からの呼び出 しの仕方は、テストプログラム（fft_test5.F：〔現在閉鎖中〕）を御参照下 さい。いずれも新井さんが製作したものです。

これらの使用によって生じた障害、損害、被害、不都合、 不利益等に関して、新井、及び筆者、物質・材料研究 機構（及び旧無機材研）は一切責任を負えません。

高速化手法９ [先頭]

最近（９／２５、１９９８）、オーダーＮ（O(N)）法が流行りですが、オー ダー１（O(1)）の方法はないのでしょうか？

O(1)ということは、バンド計算では系のサイズ（普通は原子数）に依存しな いで、一定の時間で計算できてしまうことを意味します。筆者は、計算機のア ルゴリズムとしてのO(1)手法は知りませんが、作業量としてはO(1)の方法があ ります。これは昔、日経サイエンスに載っていた手法です。

これは、いろいろな長さの棒があり、その中で最も長い棒を選ぶという作業 です。これは簡単で、これらの棒を手で束ねて、机などの上でトントンと底を 揃えれば、たちどころに一番長い棒が選べてしまいます。

棒の数が両手で束ねられる範囲内で、作業中にしくじらない（理想的な）条 件下であれば、この作業に必要な時間は、棒の本数にほとんど依存しません。 本当にO(1)になっています。
（本当は、棒の数が多くなると、束ねるための作業量、その他が無視できなく なりますが、ここではそれは無視します。）

仮定として、並列計算に対して非常に独立性の高い（通信がほとんど必要な い、例えばｋ点）バンド計算プログラムが存在すれば、ＣＰＵ数が許す範囲内 で計算のオーダーは（ｋ点数に関して）O(1)になります。個々の棒が各ｋ点に 対応し、棒を両手で束ねて、トントンと揃える行為が並列計算に相当します。 実際は、ｋ点に関して如何に独立性が高いと言っても、通信量はｋ点の数が大 きくなれば無視できなくなり（個々の棒ほどには独立でない）、O(1)でなくなっ てしまいます。

先程の棒の話のような、O(1)で計算できるバンド計算手法を考え出すことは 非常に困難であると言えます（O(N)ですら、まだ決定版と言えるようなものは ない）。でも何かうまい手がどこかに隠されているかもしれません。

筆者が思うに、現在考えられているO(N)法では、その行き着く先は、結局古典分子動力学計算のような気がするので すが、どうなんでしょう？
つまり、例えば基底関数をより局所的なものにして、全体の基底関数の増え 方を原子数の１次で増えるようにするのは、遠くの原子（とその周りの電子） との相互作用をどんどん（近傍に向かって）切断していく訳で、その究極の姿 は、２体間ポテンシャル、つまり古典的な分子動力学法だと言えないでしょう か。

少なくとも、現行の通常の第一原理 バンド計算手法の持つ計算精度を全く落さないで、O(N)計算を実現することは 土台無理なような気がします。

（１０／７、１９９８）これに関して、電総研の川本さんからの指摘（ＢＢ ＳのO(1) or O(N)計算の項目）がありました。

高速化手法Ａ [先頭]

これに関しての詳細は、”とても最近に、やらかした計算上のバグ、失 敗”[ページ]の、[レポート９／１８]を参照して下さい。

結果として、【高速でないフーリエ変換＋３次元の実空間ユニットセルに対 する体積積分】が、『逆空間での逆格子ベクトルGに関する一重のルー プ計算』に帰着します。逆空間での計算だけになるので、通常のバンド計算の 最後（計算が収束した段階）で処理することが可能となります（速くなるし、 これで効率も良く〔わざわざ別途計算する必要がない〕なる）。

正に解析的な手法に勝る、数値計算手法なし（本当に全くないかは不明）、 と言えます。

高速化手法Ｂ [先頭]

ここでは計算プログラムコードそのものに手を加えずに高速化することにつ いて考えてみたい。（１）高速化対象であるプログラムが既にきゅうきゅうに 高速化（のための改良、修正）されている。（２）当該プログラムに対する改 良、変更、修正を行ないたくない（或いは行なえない）。（３）とにかく簡単 な方法で高速化したい。というような場合、以下のような手段が考えられる （８／２３、２０１１）。
より速いアルゴリズム、手法等に導入は、プログラムの大幅な修正、改良が 必要となるので、ここでは扱わない（人任せなら別）。
”簡単な方法”と言っても、それは人の持つ知識・能力やその置かれた環境 でまちまちである。知識はないが、金（予算）や人手がある、金はないが人手 はある、金も人手もないが知識はある、など様々な状況によって、何が簡 単な手であるかは変わってくる（と思う）。

以下の項目は、これまで言及した高速化手法と重複するものがある。
  1. より速いマシンで実行させてみる。
  2. コンパイラのオプションを工夫してみる。
  3. 別のコンパイラを使ってみる。
  4. より高速な科学技術計算ライブラリの利用（例：FFT）。←この場合、計 算プログラムに（若干の）変更、修正が必要な場合がある。
  5. 自動並列化
  6. 利用出来るマシンの数を増やす。←クラスターにするという意味ではな い。
  7. 人手を増やす。
  8. 高速化を業者等に依頼する（有償）。←最早簡便な手段とは言えないが、 自分自身はコードに触らないで済む。
  9. 作業の分担や処理手順の効率化。
  10. より柔らかい擬ポテンシャルを使用する。←平面波数を減らす（＝精度 は落ちる）。
  11. 収束を速めるために、入力パラメータ、条件を最適化する。
  12. より速い第一原理計算コードを利用する。
  13. いろいろな人と議論、相談してみる。
  14. 可能ならコンパイラのバージョンアップを行なう。
  15. PCのクロックアップを試みる（推奨はしない）。
  16. メモリを一杯積む。
  17. エネルギーカットオフを小さくする（←平面波＋擬ポテンシャルの場合）。
  18. その他
（１）より速いマシンを使えば、その分計算も速くなる。計算が遅いと感じ た環境で使用しているマシン（コンピュータ）より２倍速いマシンなら、単純 に２倍速く結果が出せる。つまり元の環境で１２時間かかっていたとしたら、 ６時間で終ることとなる。勿論、マシンの速度以外は全て同じ条件としての話 である。当然、より速いマシンを使えるようにするための努力（或いは労力、 資金力）は必要である。速いマシンが、そこらに自由に使えるような形で転がっ ていることは、まずあり得ないからである。

（２）コンパイラのオプションによって計算が速くなることがある。最も効 果があるのは最適化を上げることである。-O1から-O3に上げれば、コンパイル 後の計算が速くなる。ただ最適化を上げると計算が正しく実行されなくなるこ とがあるので注意が必要。他にも、-xSSE4.2（←Intelのコンパイラにあるオ プション）というオプション付きでコンパイルすると計算が速くなる。筆者の 場合、１、２割程速くなった。ただ、このオプションは特定のCPU上のみで有 効なので、どの場合にもＯＫという訳ではない。他にもコンパイラのオプショ ンを調べると、いろいろと高速化に貢献しそうなものが見つかるはずである。 中には精度を犠牲にして、その分高速化を図るものもあるので気を付けて利用 する必要がある。

（３）コンパイラにもいろいろなものがあるので、可能なら他のコンパイラ でコンパイル＋実行して速度や計算結果を比較することも有用である。高速化 出来たり、デバッグの役に立つことがある。

（４）擬ポテンシャル＋平面波による第一原理計算手法では、FFT（高速フー リエ変換）ルーチンをより高速なものに変えることにより、２、３割（或いは それ以上）の高速化が達成される場合がある。ただこのようなライブラリ部分 の変更は、プログラムコードそのものに手を加え（修正、変更を加え）なけれ ばならないことがある。
サブルーチン群のことろに、FFTなど のライブラリを”かませる”ルーチンを提示している。これは筆者が当初から 使っていたMFFTルーチンから、他のFFTルーチンを使う時、プログラム本体に は手を加えず、この”かませた”ルーチン内で新しいFFTルーチンに対処する ようにした。ただこれでも”かませる”べき部分を新たに用意しておく必要が ある。
FFT以外にも対角化（固有値問題）関連や特殊関数の部分を他のより速いも のに換装することで、高速化が実現出来る場合がある。ただ高速化の効果は、 多くの場合で数％から１割程度くらである。対角化（固有値問題）に関しては、 それがプログラム実行時間に占める割合いが大きければ、より大きな（高速化 の）効果が期待出来る。

（５）自動並列化は、第一原理計算プログラムにおいては、ほとんど効果が ないものと思われる。以前、筆者は自身のプログラムで試してみたが、全く効 果がなかった。実行時ではなく、プログラムを解析してOpenMP等の並列化指示 行を自動で挿入してくれるソフトもあるが、これも試した限りは、全く役に立 たなかった。プログラムによっては効果を発揮するものもあるかと思うが、第 一原理計算（バンド計算）関連のプログラムの構造は、一般に非常に複雑、大 規模なので、残念ながら効果はほとんど期待出来ないと考えられる。 （６）実行可能なマシンの数が増えれば、単純に実行すべき計算の数を増や せるので、計算によって達成される研究自体の進行速度を速めることが出来る。 ただマシン数を増やせば、それだけ単位時間に処理、解析すべき計算の結果の 数も増えるので、自分自身の研究処理能力を越える状況になることは避けるべ きである。
もし扱うべき第一原理計算プログラムが、並列処理に対応していれば、マシ ン数を増やすことにより、その分高速化が可能である。特に、１台→２台、２ 台→４台という数が少ない間は、数を増やす効果は大きい。勿論、複数の独立 したマシンによる並列計算（いわゆるクラスター）では、それなりの並列環境 の構築と維持、管理が必要となる。

（７）人手が増えれば、研究の作業分担を効率良く行なえれば、研究全体の 進行速度を速めることが出来る。ただこれは程度問題であり、際限なく人員の 数を増やしても意味がないし、そもそもそんなことをすれば余計に効率が悪く なるはずである。

（８）有償で専門の業者等に高速化を依頼することが可能である。この時、 業者等によって計算プログラムそのものに手を加えられるが、当の本人はそれ に直接的な関与を全くしないものとする。高速化が本当に実現されるかは、当 該業者等に実力や、払うべき料金等に強く依存するものと思われる。更に、速 くなったが、正しい結果を与えなかったら元も子もない訳で、それなりのリス ク（危険）が伴う。

（９）最早、計算プログラムとは直接関わりがなくなっているが、研究全体 の作業効率を上げるような対策や、より有用なソフト（解析ソフト、作図ソフ ト、文書処理ソフトなどなど）を導入すれば、研究全体としての進行速度を上 げることが出来る（かもしれない）。

（１０）平面波＋擬ポテンシャルによる計算プログラムでは、より柔らかい 擬ポテンシャル（切断半径を長くしたもの）を使用することにより、必要な平 面波を少なくすることが出来る。その分、必要な計算時間を短くすることが出 来る（厳密には速くなった訳ではない）。勿論、この場合、計算精度を犠牲に していることとなる。それを気にしなくてよい場合には有効な手である。

（１１）入力パラメータや計算条件を工夫して、より収束を速くすれば実質 的な高速化に相当することが実現出来る。ここで言う収束に関しては、” 収束するとは？”参照。

（１２）プログラム自体に手を加えないという意味では、この手もありかと 思うが、新たに第一原理計算コードを導入、実行させて結果を得るためには、 それなりの労力（時には有償である場合もある）が必要であり、そう”簡単” な話ではない。そもそも何をもって”速い”のかについても考える必要がある。 新たに導入した計算コード（導入に必要な時間、労力もある）の結果が、これ までの計算結果と矛盾したり、整合しない場合（物事はそうすんなり行かない ことが多い）、どう対処するか？。そのような場合、解決するまでに消費する 時間、労力などを考慮した上で、速い、遅いを判断する必要がある。
このような事態は、”（１２）”だけでなく、他の項目でも考慮する必要が ある。

（１３）業者に有償で相談、依頼するという意味でなく、同僚や研究仲間、 或いは学会、その他の会合の時に、いろいろな人に相談、議論することである。 一個人の持っている知識、発想力は、個人差はあれ限られているので他の人の 知識、意見は貴重な助けとなることがしばしばある。如何にして計算を速くさ せるかというのは、第一原理計算に携わっている者なら、割と切実な話であり、 多くの者が何らかの知見、情報を持っているはずである。その人にとってはあ まり役に立たない情報でも、他の人にとっては（その人の置かれた環境では） 有用であることもあるので、とにかく議論、相談してみることである。

（１４）使っているコンパイラがバージョンアップしていたら、アップデー ト（更新）すると、実行速度が速くなることがある。劇的ということはないが、 数％程度速くなることはある。

（１５）第一原理計算プログラムを実行させているマシンが普通のPCなら、 クロックアップなどにより、当該マシンの実行速度を上げられる可能性がある。 勿論、このような改造を行なうと保証対象でなくなるし、改造（チューンアッ プ）が行なえるのは通常個人所有のPCに限られる。また計算結果が正しく得ら れる保証もなくなる（←結果に対する検証が必要となる）。共同利用下にある スパコンをクロックアップしてくれと言っても、無理である（この手のスパコ ンは、賃貸借契約や保守契約によって運用されているので、クロックアップな どは保証、契約対象外なはず）。

（１６）メモリを一杯積むと（使えるようにすると）若干速くなる可能性が ある。特に、メモリ不足で、HDDへの書き込み（メモリスワップ）等が多数発 生している場合、実行速度は極端に遅くなる。そのためメモリ増設で不足が解 消されると、実質的にとても速くなったように見える場合がある。

（１７）エネルギーカットオフを小さくすることは、使用する平面波（基底 関数）の数を減らすことを意味する。当然、これにより計算精度は落ちる（精 度との兼ね合いで、慎重に判断する必要がある）が、使用するメモリは減り、 計算時間が短縮（正確には計算終了までの時間が短くなる）出来る。

以上、いくつかの簡単に行なえそうないくつかの高速化の手法を挙げた。計 算プログラムコードに一切手を付けないならば、コンパイラのオプションを工 夫して何とかするしかない。ただこの手だけでは、１、２割速くなればそれは 大変うまくいったと思うべきであろう。若干コードに手を加える可能性がある が、特にFFT部分を換えると大変速くなる可能性がある（２、３割以上速く出 来るかもしれない）。速いマシンで動かせば当然、その分速くなる。ただ速い マシンはその分、価格が高くなるので資金力がなければ導入困難である。
簡単かつ楽して高速化を実現することは、例えばちょうどその計算環境に合っ た高速化可能なコンパイラオプションが見つかった（存在する）とか、ちょう ど予算が当たってお金がある時というような状況でないとなかなか難しかった りする。

最初の前提から外れるが、やはり本当に高速化を図るなら、第一原理計算プ ログラムコードで使用されるアルゴリズム、手法を（より高速なものに）抜本 的に変えることや、大規模並列計算に対応させる（例：MPIによる並列化）こ とが特に有効である。

[先頭][総目次 ][最初に戻る][ 付録、雑感][雑感２][Top]