1/2ページ
カタログの表紙
カタログの表紙

このカタログをダウンロードして
すべてを見る

ダウンロード(605Kb)

三次元流体解析プログラム最適化事例 総合重工業メーカー株式会社IHI様

事例紹介

シミュレーション実行を 9.98倍速くする。 スパコンの性能を引き出す「アプリ高速化ソリューション」

航空用ジェットエンジン開発における、三次元圧縮性流体解析プログラムと流体力学シミュレーションプログラムの高速化チューニングを実施しました。

◆抱えていた課題
• より規模が大きい複雑なケースのシミュレーションを行いたい
• テストケースを増やしてより多くのシミュレーションを行いたい
• スレッド並列化したにもかかわらず逐次処理よりも時間がかかっていた
◆高速化適用後の効果
• 9.98倍の高速化を実現したことによる
シミュレーションコスト(期間、費用)の低減
• 製品の市場投入を早められたことによるビジネスインパクトの向上

◆詳細はカタログをダウンロードしご覧いただくか、お気軽にお問い合わせ下さい。

このカタログについて

ドキュメント名 三次元流体解析プログラム最適化事例 総合重工業メーカー株式会社IHI様
ドキュメント種別 事例紹介
ファイルサイズ 605Kb
登録カテゴリ
取り扱い企業 株式会社メトロ (この企業の取り扱いカタログ一覧)

この企業の関連カタログ

この企業の関連カタログの表紙
アプリ省電力ソリューション
製品カタログ

株式会社メトロ

この企業の関連カタログの表紙
アプリ高速化ソリューション
製品カタログ

株式会社メトロ

この企業の関連カタログの表紙
車載システム開発 ADAS開発支援サービス
製品カタログ

株式会社メトロ

このカタログの内容

Page1

三次元流体解析プログラム最適化事例 シミュレーション実行を 9.98 倍 速くする。 スパコンの性能を引き出す「アプリ高速化ソリューション」 航空用ジェットエンジン開発における、三次元圧縮性流体解析プログラムと流体 力学シミュレーションプログラムの高速化チューニングを実施しました。 抱えていた課題 • より規模が大きい複雑なケースのシミュレーションを行いたい © IHI • テストケースを増やしてより多くのシミュレーションを行いたい • スレッド並列化したにもかかわらず逐次処理よりも時間がかかっていた 高速化適用後の効果 • 9.98倍の高速化を実現したことによる 総合重工業メーカー 株式会社 IHI シミュレーションコスト(期間、費用)の低減様 • 製品の市場投入を早められたことによるビジネスインパクトの向上 ■期間 改善のポイント 2017年 4月~11月 • コアレベルの並列性の向上 ソース修正とOpenMPにより、スレッド並列化を促進しました。 • 命令レベルの並列性の向上 ソース修正と最適化指示子でSIMD化し、命令スケジューリングを促進しました。 1 スレッド並列化における性能劣化問題  初めに行った性能計測では、16コアを使った自動スレッド並列 ■プロファイルの結果 処理であるにもかかわらず、逐次処理の約 4倍もの実行時間がか かってしまっていることを確認しました。また、プロファイルの結 スレッド並列化したにも 果から、整数型 load を扱う装置で待ち合わせが発生していること かからわず逐次処理よりも 時間がかかっていた が分かりました。  では、なぜ整数型 load で待ち合わせが発生しているのでしょう か。メトロでは 30年間で 2700件を超えるチューニングに対応し てきたこれまでの知見から、複雑なアセンブラコードの中で目星を つけ、検証と分析を繰り返して原因を絞り込んでいきます。 株式会社メトロ 03-5484-1022 営業本部 ビジネス&テクノロジー営業部 hpc-office@metro.co.jp 本社・田町ソフト開発センター 〒 108-0023 東京都港区芝浦 4-6-8 住友不動産田町ファーストビル 9F 沼津ソフト開発センター    〒 410-0007 静岡県沼津市西沢田 347 メトロビル http://www.metro.co.jp
Page2

三次元流体解析プログラム最適化事例 2 コアレベルの並列性の向上についての原因と対策 ■ 16 並列(改善前) real(8), pointer, dimension(:,:):: a allocate(a(10, 100)) !$omp parallel do shared(ret,a,i) private(j) default(none) do i=1,1000000 do j=1,10 ret = func_a(a(j,:)) end do end do deallocate(a) ■ 16 並列(改善後) real(8), pointer, dimension(:,:):: a real(8),dimension(100):: q1 allocate(a(10, 100)) !$omp parallel do shared(ret,a,i) private(j,q1) default(none) do i=1,1000000 do j=1,10 q1(:) = a(j,:) ←ローカル配列にコピー   ret = func_a(q1) end do end do deallocate(a)  最もボトルネックになっていたのは、コンパイラが内部 カル配列にコピーして、その配列を引数とすることが最適な で生成する allocate 関数が各スレッドから同時期に実行 手法だと考えられました。これによりローカル配列はスレッ され、大きなコンフリクトが発生していたことでした。 ドスタック領域に確保されるため、関数を呼び出すたびに発  この問題を解決するには複数の手法がありますが、プロ 生していたヒープ領域のコンフリクトが解消されます。 グラムの特性と環境を考慮した結果、ポインタ配列をロー 3 コアレベルの並列性の向上についての性能改善の結果 並列数 実行時間 (秒 ) 比率 ( 倍 ) ■プロファイルの結果 コアレベルの 並列性の向上により 逐次(改善前) 4.72 1.00 7.15倍性能向上 16並列(改善前) 16.39 0.28 さらに 16並列(改善後) 0.66 7.15 命令レベルの  今回の事例では改善前と比較して、7.15倍高速化することがで 並列性の向上により きました。スレッド並列化はマルチコアを活用する大変有効な手 9.98倍 性能向上 段です。しかし、ハードウェア本来の性能を十分に発揮するには、 コンパイラとハードウェアを熟知し、並列実行時に発生するボト ルネックを正しく分析し適切に対処することが必要となります。  さらに命令レベルの並列性の向上を合わせて行うことで最終的 には 9.98 倍の性能向上を実現することが可能になりました。 株式会社メトロ 営業本部 ビジネス&テクノロジー営業部 03-5484-1022 hpc-office@metro.co.jp