2009Q3導入事例

Gaussian09 C01オンサイト導入に際して
G09 C01 EM64T-Legacyと
G09 C01 EM64T-SSE4.2での
性能の違いと役割の違いを考察
(2011.12.19 - 2012.1.4)

Gaussian09のバージョンがB01からC01へと更新され、
併せてSSE4.2に対応した新しいバイナリが追加された

　2011年10月に、Gaussian09のバージョンがB01からC01へと更新されました。この更新での重要な点が、Gaussian09のx86系プロセッサ用バイナリーに新種の製品が追加されたことです。

元・継続的・実用的　Gaussian09 B01 EM64T-Legacy版 (以下、G09 B01 EM64T-Legacy)
新・継続的・実用的　Gaussian09 C01 EM64T-Legacy版 (以下、G09 C01 EM64T-Legacy)
新・革新的・先進的　Gaussian09 C01 EM64T-SSE4.2版 (以下、G09 C01 EM64T-SSE4.2) (Nehalem対応)

　通常のバージョンアップではバイナリーの継続性と実用性が重視されるため、バイナリー分岐による新種の追加はありません。ところが今回のバージョンアップでは、バイナリーの継続性と実用性を重視したG09 C01 EM64T-Legacy版と、そこから分岐・独立し革新性と先進性を重視しSSE4.2命令セットに対応したG09 C01 EM64T-SSE4.2版が追加され、２種類のバイナリーが製品化されました。これは通常のバージョンアップとは異なることです。(正確にはAMD版もありますが、これは広義のEM64T-Legacyとみなしています)

　両者の位置づけを整理すると、継続性と実用性を重視したG09 C01 EM64T-Legacy版は、動作環境の変化に影響されることなく、安定した計算環境の提供を長期にわたって実現することを目標としているようです。

　これに対して、革新性と先進性を重視したG09 C01 EM64T-SSE4.2版は、将来を見据えて革新的かつ先進的な開発を目標としているようです。そのため現在はSSE4.2命令セットに対応しているだけですが、将来はSandy Bridgeアーキテクチャに対応するためAVX命令セットにも対応する可能性があるとみています。

　今回のGaussian09のアップグレードでバイナリーを２種類に増やしたことの意図は、x86のアーキテクチャの更新を意識し、将来への展開を目指した結果のようです。

どちらのバイナリーを購入するかが問題

　x86系のGaussian09で新しく追加されたバイナリーは、独立した製品のため価格が別に設定されています。そのためGaussian09のライセンスを新たに購入したりバージョンアップする場合は、どのバイナリーを購入するのかを決めなければなりません。

　ではどちらを購入すれば良いのでしょうか。素直に考えると、革新的かつ先進的なG9 C01 EM64T-SSE4.2版の方が良いように思えます。しかし、今回のGaussian09のバージョンアップでは、実用的なG09 C01 EM64T-Legacy版をお勧めします。先進的なG09 C01 EM64T-SSE4.2版は試験的な運用が適当だと考えます。

バージョンアップの時期は何時が良いのか

　またG09 B01からG09 C01へのアップグレード時期の選択も重要です。Gaussian09のような巨大なプログラムは、バージョンアップされたからといって、それを直ぐに本運用で使用できません。バージョンアップした時点では発覚しなかった不具合が、運用中に発覚することも多いからです。そのため一般的には次のようなアップデートのスタイルが採用されます。

・バージョンアップから一定の検証期間を置いて (約半年程度) アップグレードする
・複数のサイトでのテスト結果を確認したうえでアップグレードする
・次のマイナーリビジョンアップ (C02) を待ち、バグが解消されてからアップグレードする

　今回のGaussian09のアップグレードは２つのアップグレードが混在した変則的なものになっています。そのため、開発の負荷が増大するため慎重なアップグレードが求められます。

「SSE」ついて説明

　ここで少しわき道にそれ、この文章のキーワードとなっている「SSE」ついて説明します。ご存じのようにSSEとはx86系アーキテクチャで使われている命令セットのことです。SSEはPentiumIIIの時代から使われ続け、アーキテクチャの更新に対応して継続的にバージョンアップされてきました。最新のSSEはNehalem世代のプロセッサに対応した「SSE4.2」になっています。このようにSSEは10年以上にわたって使われ続けている息の長い命令セットです。

　一方で、計算機がさらに高速化するためには、どこかの時点で計算機のアーキテクチャを根本的に刷新する必要があります。それはすなわち命令セットの刷新であり、命令セットの継続性が切断されるということでもあります。そしてちょうど今が大刷新の時期にあります。

　具体的には、PentiumIIIからNehalemアーキテクチャに至るまでは128bit幅の演算器を使うSSE命令セットの時代でした。そして次が、Sandy Bridgeアーキテクチャ以降で使う256bit幅の演算器を使う「AVX」命令セットの時代になります。今がその移行期です。

　幸い、Sandy Bridgeアーキテクチャには下位互換モードが備わっていて、SSEに対応したアプリケーションでもSandy Bridge上で動作します。しかし、SSEに対応したアプリケーションはSandy Brigeが持つ本来の性能を発揮させられないため、アプリケーションは高速化しません。もしアプリケーションを高速化したければAVX命令セットに対応させるひつようがあります。

　ところが、アプリケーションの開発者は開発環境 (命令セット) の変化を嫌います。なぜなら、開発環境が変化するとその影響で計算結果が変わることがあり、変わってしまった計算結果が正しいことを保障するためその精度を確認する必要があるからです。しかし、Gaussian09のような巨大なプログラムでは、これらの作業は膨大な量になるため、アプリケーションの開発者は開発環境の変化を嫌うのです。アプリケーションの開発者が計算機に望むことは、計算速度の向上はハードウェアと開発環境の開発だけの閉じた空間の中で実現し、アプリケーションの開発者に新たな負担をかけないで欲しいということです。

　しかし、命令セットレベルからの根本的な刷新をもたらすアーキテクチャ大変更が行われるとなると、アプリケーションの開発者も開発環境のアップグレードを受け入れざるを得ません。そして、アプリケーションの開発者が新しい命令セットや開発環境を受け入れると、そこから何年にもわたる移行に伴う開発が始まります。

　Gaussian09のx86系バイナリが、実用版のG09 C01 EM64T-Legacyと、先進版のG09 C01 EM64T-SSE4.2の双方を製品化した理由は、この長い開発期間を乗り越えるための策と考えられます。

　実用版バイナリーであるG09 C01 EM64T-Legacyを必要とするのは一般ユーザです。また一般ユーザがAVXを採用しSandy Brdgeに対応した次世代バイナリーを本格的に利用する時期はまだ先のことだと思います。

　また先進版バイナリーであるG09 C01 EM64T-SSE4.2を必要とするのは開発系のユーザだということになります。

HPCクラスタ計算機とGaussian09ライセンスの新規導入

　このような状況のもと、あるお客様がGaussian09用に、HPCクラスタ計算機とGaussian09ライセンスを新規に一括導入されました。お客様が導入されたシステムは次のような構成です。

HPC Cluster System:
- Server: HPC-ProServer DPeR710 n-node
- CPU: Intel Xeon X5690 (3.46GHz) 2cpu 12core
- Memory: 96GB (12x8GB/1333MHz/DDR3/LV)
- OS: RedHat EL5.6
- HDD (sys): 146GB/2.5inch/10krpm/SAS x2(RAID1)
- HDD (scr): 300GB/2.5inch/10krpm/SAS x4(RAID0/XFS)

Host System:
- Server: HPC-ProServer DPeR610
- Strage: HPC-ProStrage
- GbE
- EIA-Rack

Support:
- HPC Technial Support: in house setup and onsight setup
- System Support: 3y onsight support, 3y technical support

Software:
- AP: Gaussian09 C01 sourcecode sight licence (and all binary licence)
- Dev: Intel fortran, c/c++, mkl
- Scheduler: SGE

　お客様が導入されたGaussian09 C01のライセンスはソースコード・サイトライセンスです。このライセンスは新規導入の時に限って、Gaussian09のソースコード・ライセンス以外に、希望する全てのバイナリーコードが提供されるというサービスが付帯しています。お客様はこのサービスを利用して、Gaussian09 C01のソースコードの他にG09 C01 EM64T-Legacy版バイナリーと、G09 C01 EM64T-SSE4.2版バイナリーなどを導入されました。

　お客様が選択されたプロセッサはX5690 3.46GHz 6-coreです。Gaussian09はCPU性能律速型アプリケーションですから、そのスループット性能はCPUクロック速度とコア数の積に比例して増加します。X5690 3.46GHz 6-coreはシリーズ中で最も理論性能が高いプロセッサであり、Gaussianに最適のプロセッサです。しかも、クロック速度が高いため並列処理オーバーヘッドの影響を最も受けにくいプロセッサでもあります。

　各計算機に搭載するメモリ容量は96GBです。Gaussian09はアウトコア処理をするため、大規模計算を実施する場合でも、必要とするメモリ容量は少なくてかまいません。そのためこのシステムは、コアあたり8GB、システム全体で96GBのメモリ構成です。

　各計算機に搭載するスクラッチディスクは1.2TBのRAID0構成です。Gaussian09はアウトコア処理をするため、高速・大容量なスラッチディスクを搭載する必要があります。そのためこのシステムでは、300GB 2.5inch 10krpm SAS HDDを４個用いてRAID0を構築し、それを各ノードに搭載することで高速なアウトコア処理を実現しています。なおスクラッチディスクはI/O激しく消耗が速いのでオンサイト保守サービスは必要不可欠です。

　本格的なGaussian09用クラスタを構築するためには高機能なジョブスケジューラの導入が必要です。高機能なジョブスケジューラを搭載したHPC計算機はシステム全体の資源管理をジョブスケジューラに自動処理させることで、投入されたジョブに対して最適なリソースを自動割り当てできます。この計算機にも本格的なジョブスケジューラが導入され、適切に設定されています。

　優れたHPCクラスタを構築するためには、本格的な管理サーバとファイルサーバの搭載が必要です。本計算機システムはそれらを搭載しています。システム環境の構築と設定にも万全を期しています。

　本格的なHPCクラスタの構築には高度なHPCクラスタ構築技術が必要です。弊社のシステムは、HPC計算機専門工場にてシステム構築を行い、オンサイトセットアップによる迅速な導入と運用開始、３年間のHPC技術支援サービス、３年間の翌営業日オンサイト修理サポートなどを実施し、高い安定稼働を実現しています。このサービス品質によってシステム管理者が不在のサイトでもGaussian09用のHPCクラスタを安心して導入していただけます。

Gaussian09用クラスタ計算機の構築方法

　お客様に納めたGaussian09用クラスタの構築の実際をお伝えします。構築工程は大きく前半と後半に分かれます。前半は弊社工場での作業であり、後半はお客様の事業所でのオンサイト作業です。

　弊社工場での最初の工程は計算機本体の構築です。計算機を構成する各コンポーネントが弊社の工場に到着すると、それをラックに搭載し配線を完成させます。次にOS、ネットワーク、ストレージ環境などをインストールし基本設定を完成させます。さらにシステム全体の負荷試験によって不具合箇所を洗い出し、検出された不具合箇所を交換・修理し、安定動作する計算機システムを完成させます。

　次の工程はシステム環境の設定です。OS、ネットワーク、開発環境、並列処理環境、ストレージ、アプリケーション、ジョブスケジューラなどを出荷基準に準じてインストールし、さらに細かなカスタマイズ設定を施し、動作確認試験までの工程をさせます。これで弊社工場でのシステム構築作業は完了です。完成したシステムはHPCクラスタ専用の搬送台車に搭載し、お客様の設置場所まで安全に輸送します。

　次の工程はオンサイト作業になります。精密機器輸送専用のトラックで搬送された計算機は、指定場所まで搬送台車に乗せたままで運び据え付けます。

　据え付けが終わると、システムをお客様のサイトのネットワークに接続し、ネットワーク情報設定の確認、ジョブスケジューラ設定の確認、ファイルサーバ設定の確認、アプリケーションの動作確認などを行い、システムの据え付け作業を完了させます。ここまでの作業によって基本システムの導入は完了です。

オンサイトでのGaussian09の動作確認

　Gaussian09のようにライセンス管理が厳しいアプリケーションはオンサイトでのインストールが必要になります。特に今回は最近アップグレードされたGaussian09 C01ですから注意が必要です。Gaussian09は冒頭でもお伝えしたように、実用版のG09 C01 EM64T-Legacyと、先進版のG09 C01 EM64T-SSE4.2の２種類のバイナリーの中から一つを選択しなければなりません。そのためインストール作業の最初の課題は、２種類のバイナリーの中からどちらを使うのかを決めるということです。そのため、基本的な動作確認テストを行いました。

　最初にテストしたバイナリーは先進版のG09 C01 EM64T-SSE4.2の方です。テスト方法は、Gaussian09に添付されているテストインプットファイルを用いて、シリアル処理、２並列処理、４並列処理、８並列処理、１２並列処理を実施し、正常にジョブ投入できるか、動作に不具合はないか、期待した性能が得られるかなどを確認しました。

　先進版のG09 C01 EM64T-SSE4.2をテストすると、シリアル処理と低い並列度での処理では妥当な性能が得られました。ところが、並列度を高くすると期待した性能が得られなくなることがわかりました。

　なぜこのようなことが現場で簡単に判断できるのかというと、弊社にはこれまで多数のGaussian09システム構築の際に得られた膨大なテスト結果データが揃っていて、それと目の前で実施したテスト結果を比較すると、システムが正常動作しているか否かが簡単に判断できるのです。

　次の表は、過去に取得したX5680 3.33GHz 12-core機による旧実用版のG09 B01 EM64T-Legacyのテスト結果と、今回のX5680 3.33GHz 12-coreでの先進版のG09 C01 EM64T-SSE4.2を動作させて収得したテスト結を比較したものです。表には各機種による各並列度での"elapsed time"を記載しています。

　表をみると、旧実用版のG09 B01 EM64T-Legacyが、先進版のG09 C01 EM64T-SSE4.2に更新したことによる性能向上率は、クロック速度の向上率である4%を差し引くと、シリアル処理で6%、２並列処理で7%、４並列処理で1%の高速化がみられます。この並列度までの性能向上率は妥当な結果です。ところが並列度が向上し、８並列処理では-18%、１２並列処理では-32%の、マイナスの性能向上率になってしまいました。先進版のG09は並列処理に問題があるようです。

識別番号	# 2	# 6	# 2から # 6の性能向上率	クロック速度の向上率4%を差し引いた真の向上率
計算機	(過去のデータから引用) DPeR710 CPU:X5680 Mem:48GB	DPeR710 CPU:X5690 Mem:96GB
G09バイナリ	旧実用版 G09 B01 EM64T-Legacy	先進版 G09 C01 EM64T-SSE4.2
並列度	elapsed time (s)	elapsed time (s)
クロック速度	3.33GHz	3.46GHz	104%	4%
1	2576	2335	110%	6%
2	1321	1189	111%	7%
4	698	680	103%	1%
8	396	465	85%	-18%
12	304	428	71%	-32%

　この問題の原因を推測すると次の４つの理由が考えられます。

・ Gaussian09 C01にバグがある可能性がある
・システム設定でミスをしている可能性がある
・並列通信ボトルネックが発生している可能性がある
・ SSE4.2の並列動作に問題がある可能性がある

　この４つの原因の可能性を絞り込むため、さらにテストを追加しました。テストはXeon X5690機において実用版のG09 C01 EM64T-Legacyを用いてシリアル処理から１２並列処理まで動作させるというものです。その結果を次の表に記載し、旧実用版の結果と比較します。

識別番号	# 2	# 4	# 2から # 4の性能向上率	クロック速度の向上率4%を差し引いた真の向上率
計算機	(過去のデータから引用) DPeR710 CPU:X5680 Mem:48GB	DPeR710 CPU:X5690 Mem:96GB
G09バイナリ	旧実用版 G09 B01 EM64T-Legacy	実用版 G09 C01 EM64T-Legacy
並列度	elapsed time (s)	elapsed time (s)
クロック速度	3.33GHz	3.46GHz	104%	4%
1	2576	2332	110%	6%
2	1321	1211	109%	3%
4	698	640	109%	3%
8	396	356	111%	7%
12	304	274	111%	7%

　表を見ると驚いたことに、実用版のG09 C01 EM64T-Legacyは並列度が高くなっても期待どおりの性能を発揮していました。このことから次ことがわかりました。

・ Gaussian09 C01にバグがある可能性がある ⇒ バグはなかった
・システム設定でミスをしている可能性がある ⇒ 設定ミスはなかった

　さらにこの比較によって、実用版のG09 C01 EM64T-Legacyは、旧実用版のG09 B01 EM64T-Legacyよりも実質的に3%から7%も性能が向上していることがわかりました。特に１２並列での7%の実質性能の向上は高く評価できます。このテストからG09 B01からG09 C01へのバージョンアップは性能面でも効果が高いことがわかりました。

　すると残る原因は次の２つに絞られます。

・並列通信ボトルネックが発生している可能性がある
・ SSE4.2の並列動作に問題がある可能性がある

　この２の原因は先進版のG09 EM64T-SSE4.2のバイナリに関係しているようです。そこで次の表では、同じ計算機の上で、実用版のG09 C01 EM64T-Legacyと、先進版のG09 C01 EM64T-SSE4.2版を比較します。

識別番号	# 4	# 6	# 4から # 6の性能向上率	コメント
計算機	DPeR710 CPU:X5690 Mem:96GB
G09バイナリ	実用版 G09 C01 EM64T-Legacy	先進版 G09 C01 EM64T-SSE4.2
並列度	elapsed time (s)	elapsed time (s)
クロック速度	3.46GHz	3.46GHz	100%	２並列までは順調だが４並列から相対的な性能劣化が始まっているプロセッサ内部での複数コアの並列動作に疑問が出る
1	2332	2335	100%
2	1211	1189	102%
4	640	680	94%
8	356	465	77%
12	274	428	64%

　表を見ると先進版のG09 C01 EM64T-SSE4.2の問題であることは明らかです。先進版では、１個のプロセッサで１個のコアを使う場合は妥当な性能が得られています。さらに２個のプロセッサでそれぞれ１個づづのコアを使い２個コアで並列計算をする場合も妥当な性能が得られています。

　ところが４並列になって、２個のプロセッサ上でそれぞれ２個づづのコアを使い４個コアで並列計算をする場合になると性能低下が始まります。このことから、各プロセッサ上で複数のコアを動作させるような使い方になると、プロセッサ内部でなんらかの競合が発生し、それが並列処理ボトルネックを引き起こしているようです。さらに、各プロセッサで使用するコア数が増えるに従って競合が厳しくなり性能向上率が低下しているようです。

　上記の表によって、１個のプロセッサ上で２個以上のコアが並列動作するとボトルネックが発生していることがわかりました。ではそのボトルネックはどこで発生しているのでしょうか。その原因を追及するため次の表を作成しました。

　この表は"user time"に着目し、先ほどのelapsed timeとuser timeを比較できるようにしたものです。なおuser timeとはGaussian09のジョブがコアを実際に使った時間を合計した値です。例えば、4並列処理で４個のコアを各１０秒づつ使うとuset timeは４０秒になると計算します。

　表を見ると、実用版のG09 C01 EM64T-Legacyのuser timeと、先進版のG09 C01 EM64T-SSE4.2のuser timeを比較すると、先進版は１並列、２並列まではでは実用版とほぼ同じ時間ですが、４並列、８並列、１２並列では時間が長く掛かっています。

　しかも、elapsed timeとuser timeが共に増えています。このことから、複数のコアが並列動作する際のボトルネックはプロセッサの内部で発生していていることがわかります。コア間の通信処理などの遅延によってコアにアイドリングが発生しているのではないことを示しています。SSE4.2を使った並列処理ではプロセッサ内部で複数のコアが並列動作すると内部処理オーバーヘッドが発生し、それは並列度を増やすにしたがって大きくなるということがわかります。また、SSE4.2を使わない場合はこの問題は発生しません。SSE4.2が並列性能の低下の原因になっているようです。

識別番号	# 3	# 4	# 5	# 6	# 3から # 5の user time の性能向上率
計算機	HPC-ProServer DPeR710 CPU:X5690 Mem:96GB
G09バイナリ	実用版 G98 C01 EM64T-Legacy		先進版 G90 C01 EM64T-SSE4.2
並列度	user time (s)	elapsed time (s)	user time (s)	elapsed time (s)
1	2326	2332	2333	2335	100%
2	2412	1211	2367	1189	102%
4	2551	640	2705	680	94%
8	2836	356	3703	465	77%
12	3265	274	5120	428	64%

　今回のテストではここまでのテストしか行えなかったので、これ以上の原因追及は不可能です。原因は以下の２つのケースの何れかです。さらに原因追究をするためには平行処理でのスループット性能テスト結果が必要です。これは近日中に実施します。

・並列通信ボトルネックが発生している可能性がある ⇒可能性がある
・ SSE4.2の並列動作に問題がある可能性がある ⇒可能性がある

Gaussian09導入テストのまとめ

・ Gaussian09がB01からC01へバージョンアップしたことで約5%の性能向上が確認できた
・ SSE4.2はGaussian09の並列性能の高速化に逆効果があることがわかった
・このことからGaussian09 C01 EM64T-SSE4.2を実用版として使うことは問題
・実用版として使うならGaussian09 C01 EM-64T-Legacy

オンサイト作業でのテスト結果の報告と
インストールするGaussian09バイナリの決定

　Gaussian09用のクラスタシステムのオンサイトセットアップの過程で、以上のような検証作業を行い、その結果をお客様に報告しました。さらにお客さまと協議のうえ、今回のシステムにインストールするGaussian09のバイナリは実用版のGaussian09 C01 EM64T-Legacyに決定しました。

システムの取り扱い方法の説明

　オンサイトでのアプリケーションの動作検証に１日を費やし、お客様にも納得していただけるテストデータを提出し、Gaussian09 C01 EM64T-Legacy版をインストールすることを了承していただきました。

　次にお客様にシステムの利用方法をお伝えしました。システムは独立した管理サーバを搭載しているので、各ユーザはリモート端末から管理サーバにあるユーザ別のアカウントにリモートログインして計算機を使います。各ユーザは自分のアカウントからジョブをジョブスケジューラに投入すると、ジョブスケジューラはジョブを受け取り、次にジョブスケジューラは空いている計算機を探し、適切な計算機を見つけると、そこにジョブを投入します。もしジョブが規定の時間を超えても終了しないと、設定により警告が発信されジョブが強制終了させられます。計算が終了すると、結果はファイルサーバのユーザ領域に書き出され、最後ににユーザにジョブの完了の通知が発信されます。

　ジョブスケジューラを搭載していると、複数のユーザが計算機を共同利用していても、各ユーザは他のユーザの利用状況を意識する必要はありません。ジョブスケジューラはあらかじめ決められた運用ポリシーに従って最適な資源配分を実施します。オンサイトでの利用説明では、このようなジョブスケジューラの設定方法や、利用法についても詳しくお伝えします。

　その他、ユーザアカウントの変更方法、ファイルサーバの利用方法、定期バックアップの設定など、日常的な運用管理方法についても必要に応じてお伝えしています。

　これらのことを実機を使って説明しながら、お客様の質問にも答え、導入説明を完了させました。

HPC計算機専門のメーカーと一般的なLinuxサーバベンダーの違い

　弊社のようなHPC計算機専門のメーカーが提供するHPC計算機と、一般的なLinuxサーバベンダー提供するHPC計算機の違いは、システムが実現する機能の差です。

　弊社のようなHPC計算機の専門のメーカーは、大型計算センターの水準のHPC計算機を完成品として提供します。さらに高度なエンジニアリングサービスも付帯します。そのため、このようなHPC計算機を導入すると、お客様はHPCに精通したSEが常駐しているような感覚でシステムを利用できます。

　これに対して、一般的なLinuxサーバベンダーが提供する製品は、素材としてのLinux計算機です。提供価格は廉価ですが、HPC計算機としての構築や保守は利用者側の作業になります。そのためHPC計算機に精通した担当者がシステムの構築・維持・管理に時間を割かなければなりません。

プロ用のHPC計算機の提供

　弊社はHPC計算のプロ用が使う計算機システムを製造しています。HPC計算のプロがシステムに求めることのひとつは、ハードウェアの信頼性とシステム設定の完成度です。もしハードウェアが不調だったり、システム設定が不完全だと、快適な利用が妨げられるばかりか仕事への集中力も低下します。

　これまでの計算機はコア数も十分でなく、メモリ容量も不足気味でした。そのためそれらの増量は大きな課題でした。しかし今後の計算機は、コア数とメモリ容量が十分に多く搭載されます。すると次の課題は、如何にそれらを巧みに制御して、最高のパフォーマンスを引き出すようなシステムインテグレーションを実現するかということに移ります。

　そのため、ジョブスケジューラーの役割が大きくなります。ジョブスケジューラはこれまでのように、計算機リソースを無駄なく管理するという働きだけでなく、計算機リソースの最高の性能を引き出すための役割も負わされるのです。

　弊社が製造する計算機はプロ仕様の計算機として、信頼性の高いハードウェア、高度なシステム設定、優れた技術サポートを併せて提供しています。

【HPC導入事例】2011導入事例

Gaussian09 C01オンサイト導入に際して G09 C01 EM64T-Legacyと G09 C01 EM64T-SSE4.2での 性能の違いと役割の違いを考察 (2011.12.19 - 2012.1.4)

Gaussian09のバージョンがB01からC01へと更新され、 併せてSSE4.2に対応した新しいバイナリが追加された