図面 (/)

技術 並列コンピューティング環境でソフトウェアを開発するための方法

出願人 ジーイー・アビエイション・システムズ・エルエルシー
発明者 エリック・ダニエル・ビューラーベンジャミン・トーマス・オッチピンティ
出願日 2013年8月5日 (7年6ヶ月経過) 出願番号 2013-161940
公開日 2014年2月27日 (6年11ヶ月経過) 公開番号 2014-038613
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード 並列処理モード 保守段階 性能メトリクス ウォータフォール 並列コード 機能的要求 次設計 ベンチマーキング
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年2月27日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

並列コンピューティングプラットフォーム上で動作するプログラムの開発において、タイミング等の並列プログラム特有バグの検出を可能にする。

解決手段

ソフトウェアの順次実装順次処理環境で開発するステップ(114)と、ソフトウェアの前記順次実装が所期のように作動することを検証するステップ(116)とに加え、ソフトウェアの前記順次実装の並列実装並列処理環境で開発するステップ(118)と、ソフトウェアの前記順次実装の結果に対してソフトウェアの前記並列実装の結果を検証するステップ(120)とを備える。

概要

背景

ソフトウェア開発工程は、プログラムライフサイクル全体にわたるソフトウェア製品生産性および品質を向上させるために開発されてきた。個人向けおよび業務用のコンピューティングプロセッサが、シングルコア処理装置(CPU)からマルチコアCPUおよびグラフィック処理装置(GPU)に移行したため、コンピュータソフトウェアは、高度に順次(sequential)であることから高度に並列であることに遷移しつつある。

図1は、単一の命令ストリームおよび単一のデータストリームを用いる順次処理コンピュータアーキテクチャ10の概略的なフローチャートである。順次処理は、データプール16内のメモリに記憶されるデータを演算するために命令プール12からの命令の単一のストリームを単一のプロセッサが実行する、ハードウェアアーキテクチャでのコンピュータコードの実行を指す。ソフトウェア開発者によりプログラムされるソフトウェアの順次実装が、命令プール12に存在する。命令の単一の直列ストリームが、プログラムが実行される際に命令プール12から単一の処理装置(PU)14に送出される。PU14は、単一の直列ストリームでデータプール16からデータを受信する。順次処理アーキテクチャ10の表現は、コンピュータアーキテクチャのフリン分類の要素のような文献では、単一のストリーム命令、単一のストリームデータ(SISD)と呼ばれている。このアーキテクチャの最もよく知られた例は、1980年代および1990年代を通してPCで使用された従前の単一のプロセッサの機械である。

図2は、単一の命令ストリームおよび複数のデータストリームを用いる並列処理コンピュータアーキテクチャ20の概略的なフローチャートである。並列処理は、まったく異なる計算を並行的に実施可能な任意のコンピュータアーキテクチャを指す。一並列処理アーキテクチャでは並列コンピュータコードの実行は、データプール26内のメモリに記憶されるデータの複数のストリームを演算するために命令プール22からの命令の単一のストリームを複数のプロセッサが実行する場合に行われる。ソフトウェア開発者によりプログラムされるソフトウェアの並列実装が、命令プール22に存在する。命令の単一の直列ストリームが、プログラムが実行される際に命令プール22から1組の処理装置(PU)24に送出される。PU24は各々、データプール26からデータのストリームを受信する。並列処理アーキテクチャ20のこの表現は、コンピュータアーキテクチャのフリンの分類の要素のような文献では、単一のストリーム命令、複数のストリームデータ(SIMD)と呼ばれている。SIMDアーキテクチャは、GPUおよび大多数のマルチコアCPUで実装されている。

典型的なソフトウェア開発工程ではプログラマは、処理環境を選び出し、その選択した環境に対して開発を行う。その結果、並列コンピューティングプラットフォーム上で動作することになるアプリケーションを創作する仕事が課せられた開発者は、並列コンピューティングプラットフォームでのソフトウェア製品の並列実装を開発することになる。コンピュータプログラムの並列実装は、コンピュータ計算並行性が追加的なタイプのソフトウェアのバグおよびリソース管理の問題点に関する可能性を加えるので、順次実装より書き記すのが難しいことが知られている。例えば並列プログラムは、競合状態として知られるあるタイプの障害にみまわれる場合があり、そのことによってコンピュータプログラムの並列実装は、複数のプロセッサにより遂行される演算間のタイミングに決定的に依存することに起因した異常な挙動を呈する。これらのタイプのエラーは、追跡するのがきわめて困難であり、その結果解決するのに非常に時間がかかる場合がある。

ソフトウェア開発工程は、プログラムのライフサイクル全体にわたるソフトウェア製品の生産性および品質を向上させるために開発されてきた。典型的にはこれらの方法論は、ソフトウェア開発ライフサイクルのモデルを基に構築され、コンピュータプログラムが開発かつビルドされる際に開発者がしたがうべき計画を提供する。数十年の間パーソナルコンピュータ業界で優位を占めていたコンピュータハードウェアアーキテクチャの直列の性質に起因して、順次処理が、コンピュータコードを開発するためにコンピュータ科学者が使用してきたソフトウェア開発工程を形成してきた。グラフィック処理装置(GPU)およびマルチコア中央処理装置(CPU)が出現し利用しやすくなったことによって、並列コンピューティングが、業務用および個人向けの両方のコンピューティングの主流に至った。その結果ソフトウェア開発工程は、並列ソフトウェアの開発および配備に関して不適切であり効率的でない。

図3は、ウォータフォールモデル30として知られるソフトウェア開発用の順次設計工程の概略的なフローチャートである。ウォータフォールモデル30は、ハードウェア設計方法論から適合され、ソフトウェア開発で使用されたよく知られた設計工程であり、工程の各々のフェーズは次のフェーズが始められる前に完了される。ウォータフォールモデル30のフェーズは、要求32、設計34、実装36、検証38、および保守40である。各々のステップは、全体的な開発工程が現在のステップの完了に基づいて次のステップに進行するように、次のステップに連続して結合され、進行がに類似するように、前のステップが後のステップの上方にある状態で視覚化されることが多い。

ソフトウェア開発用のウォータフォールモデル30の初期ステップは、要求段階32である。要求段階32は、設計段階34に連続して結合され、したがって要求段階32を、設計段階34が開始可能である前に完了しなければならない。設計段階34は、実装段階36に連続して結合される。実装段階36は、検証段階38に連続して結合される。検証段階38は、保守段階40に連続して結合される。保守段階40が完了すると、開発工程が完了する。

典型的には要求段階32の目標は、ソフトウェアの目的を説明し、ソフトウェア要求仕様書を策定することである。ソフトウェア要求仕様書は、開発されるべきソフトウェアの機能的要求および非機能的要求の両方を規定するソフトウェアシステムの完全な説明である。ソフトウェアに関する機能的要求は、ソフトウェアがどのように作動することになるかを説明する、入力、挙動、および出力の組である。機能的要求は典型的には、計算およびユースケースとして要求段階32で文書化される。ソフトウェアに関する非機能的要求は、速度、安定性能力、および移植性などのソフトウェアが呈することになる品質を説明する。非機能的要求は、システムアーキテクチャを定めることになる基準である。

設計段階34は、要求段階32で前に指定された目的および要求を満たすことになる具体的なソフトウェアソリューション立案する工程である。設計段階34中にソフトウェア開発者は、機能的要求および非機能的要求を検討し、実装されるべきソフトウェアの基本設計を詳述することになるソフトウェアモデルを開発することになる。ソフトウェア設計中の典型的な検討事項は、互換性モジュール性信頼性、有用性ロバスト性等である。ソフトウェアモデルの基本設計は、ソフトウェアアーキテクチャを説明する階層または枠組を説明することになる。ソフトウェアアーキテクチャは、個々のソフトウェアコンポーネントまたはモジュール、およびモジュールがどのように相互接続することになるかを説明することになる。設計段階34の出力は、ソフトウェアモデルの文書類であり、プレーンテキストの説明、フローチャート、または統一モデリング言語(UML)のようなモデリング言語での階層の説明であり得る。

実装段階36は、コンピュータコードが実際に書き記されるソフトウェア開発サイクルにおけるフェーズである。設計段階からの技術的説明が、ソフトウェアプログラムまたはコンポーネントとして実現される。プログラムは、設計段階34からのソフトウェア設計のそのままの実装であることにより、要求段階32からのソフトウェア要求準拠することが意図される。

ソフトウェア開発サイクルの検証段階38は、プログラムが正しく仕様書に合わせてビルドされたことを実証するために、実装されたソフトウェアがソフトウェアの要求および設計に対してテストされる工程である。ソフトウェア検証は、ソフトウェアが指定されたように遂行することを確認するためにテストが書き記される順序だった工程である。ソフトウェアが確認テスト合格しないならば、プログラムは欠陥を探し出し排除するためにデバッグされる。ウォータフォール開発工程30の検証段階38が完了すると、ソフトウェアはインストールされ保守される。ソフトウェア開発工程の保守段階40は、ソフトウェアシステムがエンドユーザプラットフォームにインストールされた後に行われる。この時点でエンドユーザは、前には未知のバグまたは性能の問題点を識別することになる。典型的にはウォータフォールモデル30のもとで開発されたソフトウェアシステムは、現場置型のシステムを使用するときにエンドユーザのソフトウェア要求が変化するのにしたがって進化し始めることになる。したがって保守段階40は、ソフトウェアシステムが、エンドユーザの動的なニーズ応答して、ウォータフォールモデル30のもとで開発されたソフトウェアの要求および設計から離れて移行するフェーズである。

概要

並列コンピューティングプラットフォーム上で動作するプログラムの開発において、タイミング等の並列プログラム特有なバグの検出を可能にする。ソフトウェアの順次実装を順次処理環境で開発するステップ(114)と、ソフトウェアの前記順次実装が所期のように作動することを検証するステップ(116)とに加え、ソフトウェアの前記順次実装の並列実装を並列処理環境で開発するステップ(118)と、ソフトウェアの前記順次実装の結果に対してソフトウェアの前記並列実装の結果を検証するステップ(120)とを備える。

目的

典型的にはこれらの方法論は、ソフトウェア開発ライフサイクルのモデルを基に構築され、コンピュータプログラムが開発かつビルドされる際に開発者がしたがうべき計画を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

並列コンピューティング環境ソフトウェアを開発するための方法であって、前記ソフトウェアの順次実装順次処理環境で開発するステップ、前記ソフトウェアの前記順次実装が所期のように作動することを検証するステップ、前記ソフトウェアの前記順次実装の並列実装並列処理環境で開発するステップ、前記ソフトウェアの前記順次実装の結果に対して前記ソフトウェアの前記並列実装の結果を検証するステップを含む、ソフトウェアを開発するための方法。

請求項2

前記ソフトウェアの前記順次実装および前記ソフトウェアの前記並列実装の両方を保守するステップをさらに含む、請求項1記載のソフトウェアを開発するための方法。

請求項3

前記ソフトウェアに対する要求を決定するステップ、および、前記ソフトウェアに対する設計を決定するステップをさらに含み、これらのステップが、前記ソフトウェアを前記順次処理環境で開発する前記ステップより前に遂行される、請求項1記載のソフトウェアを開発するための方法。

請求項4

前記ソフトウェアの前記順次実装の並列実装を並列処理環境で開発する前記ステップが、前記ソフトウェアの前記順次実装が所期のように作動することを検証する前記ステップと全体的に同時期に遂行される、請求項1記載のソフトウェアを開発するための方法。

請求項5

前記並列処理環境が少なくとも1つのGPUを備える、請求項1記載のソフトウェアを開発するための方法。

請求項6

前記並列処理環境が少なくとも1つのマルチコアプロセッサを備える、請求項1記載のソフトウェアを開発するための方法。

請求項7

前記順次処理環境が少なくとも1つのCPUを備える、請求項1記載のソフトウェアを開発するための方法。

請求項8

前記ソフトウェアの前記順次実装の前記結果に対して前記ソフトウェアの前記並列実装の前記結果を検証する前記ステップが、以下の、(a)前記ソフトウェアの前記並列実装の前記結果に信頼度テスティングを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、(b)前記ソフトウェアの前記並列実装の前記結果に少なくとも1つの単体テストを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、(c)前記ソフトウェアの前記並列実装の前記結果に少なくとも1つのコーナテストを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、および、(d)前記ソフトウェアの前記並列実装の前記結果に少なくとも1つのエッジテストを遂行し、前記結果を前記順次実装の前記結果と比較するステップのうちの少なくとも1つを含む、請求項1記載のソフトウェアを開発するための方法。

請求項9

前記ソフトウェアのランタイム状態が並列処理をサポート可能であるかどうかを検出するステップをさらに含む、請求項1記載のソフトウェアを開発するための方法。

請求項10

前記ソフトウェアのランタイム状態が並列処理をサポート可能であるかどうかを検出する前記ステップからの信号に基づいて、前記ソフトウェアを並列処理モードで走らせるステップをさらに含む、請求項9記載のソフトウェアを開発するための方法。

技術分野

0001

本発明は、並列コンピューティング環境ソフトウェアを開発するための方法に関する。

背景技術

0002

ソフトウェア開発工程は、プログラムライフサイクル全体にわたるソフトウェア製品生産性および品質を向上させるために開発されてきた。個人向けおよび業務用のコンピューティングプロセッサが、シングルコア処理装置(CPU)からマルチコアCPUおよびグラフィック処理装置(GPU)に移行したため、コンピュータソフトウェアは、高度に順次(sequential)であることから高度に並列であることに遷移しつつある。

0003

図1は、単一の命令ストリームおよび単一のデータストリームを用いる順次処理コンピュータアーキテクチャ10の概略的なフローチャートである。順次処理は、データプール16内のメモリに記憶されるデータを演算するために命令プール12からの命令の単一のストリームを単一のプロセッサが実行する、ハードウェアアーキテクチャでのコンピュータコードの実行を指す。ソフトウェア開発者によりプログラムされるソフトウェアの順次実装が、命令プール12に存在する。命令の単一の直列ストリームが、プログラムが実行される際に命令プール12から単一の処理装置(PU)14に送出される。PU14は、単一の直列ストリームでデータプール16からデータを受信する。順次処理アーキテクチャ10の表現は、コンピュータアーキテクチャのフリン分類の要素のような文献では、単一のストリーム命令、単一のストリームデータ(SISD)と呼ばれている。このアーキテクチャの最もよく知られた例は、1980年代および1990年代を通してPCで使用された従前の単一のプロセッサの機械である。

0004

図2は、単一の命令ストリームおよび複数のデータストリームを用いる並列処理コンピュータアーキテクチャ20の概略的なフローチャートである。並列処理は、まったく異なる計算を並行的に実施可能な任意のコンピュータアーキテクチャを指す。一並列処理アーキテクチャでは並列コンピュータコードの実行は、データプール26内のメモリに記憶されるデータの複数のストリームを演算するために命令プール22からの命令の単一のストリームを複数のプロセッサが実行する場合に行われる。ソフトウェア開発者によりプログラムされるソフトウェアの並列実装が、命令プール22に存在する。命令の単一の直列ストリームが、プログラムが実行される際に命令プール22から1組の処理装置(PU)24に送出される。PU24は各々、データプール26からデータのストリームを受信する。並列処理アーキテクチャ20のこの表現は、コンピュータアーキテクチャのフリンの分類の要素のような文献では、単一のストリーム命令、複数のストリームデータ(SIMD)と呼ばれている。SIMDアーキテクチャは、GPUおよび大多数のマルチコアCPUで実装されている。

0005

典型的なソフトウェア開発工程ではプログラマは、処理環境を選び出し、その選択した環境に対して開発を行う。その結果、並列コンピューティングプラットフォーム上で動作することになるアプリケーションを創作する仕事が課せられた開発者は、並列コンピューティングプラットフォームでのソフトウェア製品の並列実装を開発することになる。コンピュータプログラムの並列実装は、コンピュータ計算並行性が追加的なタイプのソフトウェアのバグおよびリソース管理の問題点に関する可能性を加えるので、順次実装より書き記すのが難しいことが知られている。例えば並列プログラムは、競合状態として知られるあるタイプの障害にみまわれる場合があり、そのことによってコンピュータプログラムの並列実装は、複数のプロセッサにより遂行される演算間のタイミングに決定的に依存することに起因した異常な挙動を呈する。これらのタイプのエラーは、追跡するのがきわめて困難であり、その結果解決するのに非常に時間がかかる場合がある。

0006

ソフトウェア開発工程は、プログラムのライフサイクル全体にわたるソフトウェア製品の生産性および品質を向上させるために開発されてきた。典型的にはこれらの方法論は、ソフトウェア開発ライフサイクルのモデルを基に構築され、コンピュータプログラムが開発かつビルドされる際に開発者がしたがうべき計画を提供する。数十年の間パーソナルコンピュータ業界で優位を占めていたコンピュータハードウェアアーキテクチャの直列の性質に起因して、順次処理が、コンピュータコードを開発するためにコンピュータ科学者が使用してきたソフトウェア開発工程を形成してきた。グラフィック処理装置(GPU)およびマルチコア中央処理装置(CPU)が出現し利用しやすくなったことによって、並列コンピューティングが、業務用および個人向けの両方のコンピューティングの主流に至った。その結果ソフトウェア開発工程は、並列ソフトウェアの開発および配備に関して不適切であり効率的でない。

0007

図3は、ウォータフォールモデル30として知られるソフトウェア開発用の順次設計工程の概略的なフローチャートである。ウォータフォールモデル30は、ハードウェア設計方法論から適合され、ソフトウェア開発で使用されたよく知られた設計工程であり、工程の各々のフェーズは次のフェーズが始められる前に完了される。ウォータフォールモデル30のフェーズは、要求32、設計34、実装36、検証38、および保守40である。各々のステップは、全体的な開発工程が現在のステップの完了に基づいて次のステップに進行するように、次のステップに連続して結合され、進行がに類似するように、前のステップが後のステップの上方にある状態で視覚化されることが多い。

0008

ソフトウェア開発用のウォータフォールモデル30の初期ステップは、要求段階32である。要求段階32は、設計段階34に連続して結合され、したがって要求段階32を、設計段階34が開始可能である前に完了しなければならない。設計段階34は、実装段階36に連続して結合される。実装段階36は、検証段階38に連続して結合される。検証段階38は、保守段階40に連続して結合される。保守段階40が完了すると、開発工程が完了する。

0009

典型的には要求段階32の目標は、ソフトウェアの目的を説明し、ソフトウェア要求仕様書を策定することである。ソフトウェア要求仕様書は、開発されるべきソフトウェアの機能的要求および非機能的要求の両方を規定するソフトウェアシステムの完全な説明である。ソフトウェアに関する機能的要求は、ソフトウェアがどのように作動することになるかを説明する、入力、挙動、および出力の組である。機能的要求は典型的には、計算およびユースケースとして要求段階32で文書化される。ソフトウェアに関する非機能的要求は、速度、安定性能力、および移植性などのソフトウェアが呈することになる品質を説明する。非機能的要求は、システムアーキテクチャを定めることになる基準である。

0010

設計段階34は、要求段階32で前に指定された目的および要求を満たすことになる具体的なソフトウェアソリューション立案する工程である。設計段階34中にソフトウェア開発者は、機能的要求および非機能的要求を検討し、実装されるべきソフトウェアの基本設計を詳述することになるソフトウェアモデルを開発することになる。ソフトウェア設計中の典型的な検討事項は、互換性モジュール性信頼性、有用性ロバスト性等である。ソフトウェアモデルの基本設計は、ソフトウェアアーキテクチャを説明する階層または枠組を説明することになる。ソフトウェアアーキテクチャは、個々のソフトウェアコンポーネントまたはモジュール、およびモジュールがどのように相互接続することになるかを説明することになる。設計段階34の出力は、ソフトウェアモデルの文書類であり、プレーンテキストの説明、フローチャート、または統一モデリング言語(UML)のようなモデリング言語での階層の説明であり得る。

0011

実装段階36は、コンピュータコードが実際に書き記されるソフトウェア開発サイクルにおけるフェーズである。設計段階からの技術的説明が、ソフトウェアプログラムまたはコンポーネントとして実現される。プログラムは、設計段階34からのソフトウェア設計のそのままの実装であることにより、要求段階32からのソフトウェア要求準拠することが意図される。

0012

ソフトウェア開発サイクルの検証段階38は、プログラムが正しく仕様書に合わせてビルドされたことを実証するために、実装されたソフトウェアがソフトウェアの要求および設計に対してテストされる工程である。ソフトウェア検証は、ソフトウェアが指定されたように遂行することを確認するためにテストが書き記される順序だった工程である。ソフトウェアが確認テスト合格しないならば、プログラムは欠陥を探し出し排除するためにデバッグされる。ウォータフォール開発工程30の検証段階38が完了すると、ソフトウェアはインストールされ保守される。ソフトウェア開発工程の保守段階40は、ソフトウェアシステムがエンドユーザプラットフォームにインストールされた後に行われる。この時点でエンドユーザは、前には未知のバグまたは性能の問題点を識別することになる。典型的にはウォータフォールモデル30のもとで開発されたソフトウェアシステムは、現場置型のシステムを使用するときにエンドユーザのソフトウェア要求が変化するのにしたがって進化し始めることになる。したがって保守段階40は、ソフトウェアシステムが、エンドユーザの動的なニーズ応答して、ウォータフォールモデル30のもとで開発されたソフトウェアの要求および設計から離れて移行するフェーズである。

先行技術

0013

米国特許出願公開第2008/0282228号明細書

0014

本発明は、並列コンピューティング環境でソフトウェアを開発するための方法に関する。方法は、ソフトウェアの順次実装を順次処理環境で開発するステップ、ソフトウェアの順次実装が所期のように作動することを検証するステップ、ソフトウェアの順次実装の並列実装を並列処理環境で開発するステップ、および、ソフトウェアの順次実装の結果に対してソフトウェアの並列実装の結果を検証するステップを含む。

図面の簡単な説明

0015

単一の命令ストリームおよび単一のデータストリームを用いる従来技術の順次処理コンピュータアーキテクチャの概略的なフローチャートである。
単一の命令ストリームおよび複数のデータストリームを用いる従来技術の並列処理アーキテクチャの概略的なフローチャートである。
ウォータフォールモデルとして知られるソフトウェア開発用の従来技術の順次設計工程の概略的なフローチャートである。
本発明の実施形態による順次および並列のソフトウェアの同時開発用の並列設計工程の概略的なフローチャートである。
本発明の実施形態による順次コード実装に対して並列コード実装を検証するために使用される工程の概略的なフローチャートである。

実施例

0016

背景技術および以下の説明において説明目的で、数多くの具体的な詳細を、本明細書で説明する技術の徹底した理解をもたらすために記載する。しかしながらこれらの具体的な詳細がなくとも、例示的な実施形態が実践可能であることは当業者には明白であろう。他の事例では、構造およびデバイスを、例示的な実施形態の説明を容易にするために線図の形式で示す。

0017

例示的な実施形態を、図面を参照して説明する。これらの図面は、本明細書で説明するモジュール、方法、またはコンピュータプログラム製品を実装する具体的な実施形態の決まった詳細を図示する。しかしながら図面を、図面に存在し得る何らかの制限を加えるものであると解釈すべきではない。方法およびコンピュータプログラム製品を、それらの動作を達成するために任意の機械可読媒体に付して提供することができる。実施形態を、既存のコンピュータプロセッサを使用して、またはこのもしくは別の目的で組み込まれる専用コンピュータプロセッサにより、またはハードワイヤードのシステムにより実装することができる。

0018

上記で記したように、本明細書で説明する実施形態は、機械実行可能命令もしくはデータ構造体を搬送するための、またはそれらが記憶された状態にするための機械可読媒体を備えるコンピュータプログラム製品を含み得る。そのような機械可読媒体は、プロセッサを伴う汎用または専用のコンピュータまたは他の機械によりアクセスされ得る任意の利用可能な媒体であり得る。例としてそのような機械可読媒体は、RAM、ROM、EPROM、EEPROM、CD−ROMもしくは他の光ディスク記憶装置磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、所望のプログラムコードを機械実行可能命令もしくはデータ構造体の形式で搬送もしくは記憶するために使用され得る、および、プロセッサを伴う汎用もしくは専用のコンピュータもしくは他の機械によりアクセスされ得る、任意の他の媒体を備え得る。情報をネットワークまたは別の通信接続(ハードワイヤード、ワイヤレス、またはハードワイヤードもしくはワイヤレスの組み合わせのいずれか)を介して機械に伝送または提供するとき、機械は当然のことながらその接続を機械可読媒体とみなす。したがって任意のそのような接続を、当然のことながら機械可読媒体と呼ぶ。上記の組み合わせもまた、機械可読媒体の範囲内に含まれる。機械実行可能命令は例えば、汎用コンピュータ、専用コンピュータ、または専用処理機械に、決まった1つの機能または機能の群を遂行させる命令およびデータを含む。

0019

実施形態を、例えばネットワーク化された環境での機械により実行されるプログラムモジュールの形式でのプログラムコードなどの機械実行可能命令を含むプログラム製品により一実施形態において実装され得る、方法ステップの全体的な脈絡で説明する。一般にプログラムモジュールは、個別のタスクを遂行する技術的効果を有する、または個別の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体等を含む。機械実行可能命令、関連するデータ構造体、およびプログラムモジュールは、本明細書で開示する方法のステップを実行するためのプログラムコードの例を表す。そのような実行可能命令の個別のシーケンスまたは関連するデータ構造体は、そのようなステップで説明する機能を実装するための対応する作用の例を表す。

0020

実施形態を、プロセッサを有する1つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で実践することができる。論理接続は、ここでは例としてであり限定としてではなく提示される、ローカルエリアネットワーク(LAN)および広域ネットワークWAN)を含み得る。そのようなネットワーク環境は、職場内または企業内のコンピュータネットワークイントラネットおよびインターネットではありふれたものであり、多種多様の異なる通信プロトコルを使用することができる。そのようなネットワークコンピューティング環境が典型的には、パーソナルコンピュータ、ハンドヘルドデバイスマルチプロセッサシステムマイクロプロセッサベースまたはプログラマブルの民生用電子機器、ネットワークPC、ミニコンピュータメインフレームコンピュータ等を含む多くのタイプのコンピュータシステム構成を包含することになることを当業者ならば理解するであろう。

0021

実施形態を、通信ネットワークを介して(ハードワイヤードリンクワイヤレスリンクによって、またはハードワイヤードもしくはワイヤレスのリンクの組み合わせによってのいずれかで)リンクされる、ローカルおよびリモート処理デバイスによりタスクが遂行される分散コンピューティング環境でさらに実践することができる。分散コンピューティング環境ではプログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイスに存在し得る。

0022

例示的な実施形態の全体または一部分を実装するための例示的なシステムは、処理装置、システムメモリ、および、システムメモリを含む様々なシステム構成要素を処理装置に結合するシステムバスを含む、コンピュータの形式での汎用コンピューティングデバイスを含み得る。システムメモリは、リードオンリーメモリ(ROM)およびランダムアクセスメモリ(RAM)を含み得る。コンピュータは、磁気ハードディスクに関する読み出しおよび書き込みを行うための磁気ハードディスクドライブリムーバブル磁気ディスクに関する読み出しまたは書き込みを行うための磁気ディスクドライブ、ならびに、CD−ROMまたは他の光学媒体などのリムーバブル光ディスクに関する読み出しまたは書き込みを行うための光ディスクドライブをさらに含み得る。ドライブおよびそれらの関連する機械可読媒体は、機械実行可能命令、データ構造体、プログラムモジュール、およびコンピュータ用の他のデータの不揮発性の記憶をもたらす。

0023

実施形態で開示する方法の技術的効果には、並列処理アプリケーション開発の効率を向上させることがある。さらにこの方法は、順次および並列の両方での、複数のハードウェアプラットフォームでのアプリケーションの開発者には他の方法では利用可能でないデバッグの選択肢を考慮することにより、既存のソフトウェアおよびハードウェアのデバッグ技法を改善する。現場設置型のプラットフォームでのこの技法の実装は、アプリケーションの最良ランタイム状態を自動的に選択することによりシステムのロバスト性を改善することになる。

0024

図4は本発明の実施形態によるモデル100を図示し、図1〜3に関して示し説明した従来技術のウォータフォールモデル30が、本明細書で提供する図示の例によって改善されている。モデル100は、並列コンピューティング環境でソフトウェアを開発するためのソフトウェア設計工程である。開発工程は、典型的には順次処理ソフトウェア開発で使用されるウォータフォールモデル30として知られる順次設計工程を拡張したものである。拡張されたフェーズは、ソフトウェアプログラムの順次および並列の実装の同時開発を明示する。次いで工程は、順次実装に対して並列実装を検証する方法を明示する。

0025

修正されたウォータフォールモデル100の段階は、要求110、設計112、順次実装114、順次検証116、並列実装118、順次実装に対する並列検証120、および保守122である。要求段階110は、設計段階112に連続して結合される。設計段階112は、順次実装段階114に連続して結合される。次いで順次実装段階114は、順次検証段階116および並列実装段階118の両方に結合される。順次検証段階116および並列実装段階118の両方は、順次実装に対する並列検証段階120に結合される。順次実装に対する並列検証段階120は、保守段階122に連続して結合される。

0026

修正されたウォータフォールモデル100の要求段階110は、ウォータフォールモデル30の要求段階32でのように実装される。ウォータフォールモデル30の設計段階34の工程に加えて、修正されたウォータフォールモデル100の設計段階112は、あるとすればどの順次アルゴリズムが並列実装のために並列アルゴリズムに変換されることになるかを決定するための、開発者による追加的な形式的な分析を含む。あるとすればどの順次アルゴリズムが並列実装のために並列アルゴリズムに変換されることになるかを決定するための分析は、要求段階110からの初期の要求、ならびに設計段階112からの想定および要求が、アルゴリズムがコンピュータコードに実装される際に変化する場合があるので、設計段階112に限定される。

0027

設計段階112が完了すると、順次実装段階114が始められる。順次実装段階114は、ウォータフォールモデル30の実装段階36と同様に、コンピュータコードが実際に書き記されるソフトウェア開発サイクルにおけるフェーズである。順次実装段階114で開発されるコンピュータコードは、順次処理環境で走るソフトウェアの順次実装である。速度などの要求段階32で策定される非機能的要求は、順次実装段階114では満たされる必要がないことになる。本発明の代替実施形態では、順次および並列のアルゴリズムは各々1組の要求を有し、順次実装は順次実装用に記された要求にしたがうべきである。順次実装段階114が完了すると、より徹底した分析が、どの順次アルゴリズムが並列化から最大に利益を得そうであるかを決定する。

0028

順次検証段階116は、順次実装段階114が完了すると開始する。ウォータフォールモデル30の検証段階38と同様に、順次検証段階116の目標は、ソフトウェアの順次実装が所期のように作動することを検証することである。

0029

順次検証段階116と同時期に、並列実装段階118は開始することができる。並列実装段階118の目標は、ソフトウェアの順次実装の並列実装を並列処理環境で開発することである。並列処理環境は、マルチコアCPUおよびGPUなどの主流のハードウェアアーキテクチャを含み得る。アルゴリズムの実装では小さな変化でさえ並列実装に相当の変化をもたらす可能性があるので、並列処理実装段階118を、順次実装段階114が終結させられるまでスタートさせるべきではない。

0030

順次検証116および並列実装118の両方の段階が完了すると、並列検証120の段階が開始することができる。並列検証段階120は、ソフトウェアの順次実装の結果に対してソフトウェアの並列実装の結果を検証する。

0031

ソフトウェアの並列実装が並列検証段階120で検証された後、修正されたウォータフォールモデル100のソフトウェア開発工程は保守段階122に入る。ウォータフォールモデル30の保守段階40と同様に、修正されたウォータフォールモデル100の保守段階122は、ソフトウェア開発工程から進化的開発へのソフトウェアプロジェクトの移行であり、このことによって、障害がエンドユーザにより発見され、ソフトウェアに対する増分の変化が、これらの障害およびエンドユーザの要求の変化に応答して生じる。

0032

図5は、修正されたウォータフォールモデル100の並列コード検証段階120を遂行するために使用され得る工程200を図示する。この工程200では並列コード実装を検証するために、一連のテストを、出力および結果を前に検証されたソフトウェアの順次実装と比較するためにソフトウェア開発者により開発かつ遂行することができる。工程は、並列実装の信頼度テスティング210から始めることができる。次いで信頼度テスティングの結果を、順次実装218の結果と比較することができる。結果の比較が成功すると工程は、並列実装の単体テスティング212に進むことができる。次いで単体テスティングの結果を、順次実装218の結果と比較することができる。結果の比較が成功すると工程は、並列実装のコーナテスティング214に進むことができる。次いでコーナテスティングの結果を、順次実装218の結果と比較することができる。結果の比較が成功すると工程は、並列実装のエッジテスティング216に進むことができる。次いでエッジテスティングの結果を、順次実装218の結果と比較することができる。

0033

並列実装検証がスタートすると、ソフトウェア開発者は信頼度テスティング210を開発かつ遂行することができる。信頼度テスティングは典型的には、ソフトウェア実装の全体的な機能実行を迅速に検証するように定められたテスティングの略式の方法である。一連のテストがすでに順次検証段階116で順次実装に対して開発されていることが可能なので、信頼度テスティング210の結果を、順次検証段階116に対して開発された同様のテストに対する結果と比較することができる。

0034

信頼度テスティングの結果が順次実装の結果に対して検証された後、ソフトウェア開発者は単体テスティング212を開発かつ遂行することができる。単体テスティングは、ソフトウェアコードの特定のセクションの機能性を検証するソフトウェアコンポーネントをテストする方法である。一連の単体テストがすでに順次検証段階116で順次実装に対して開発されていることが可能なので、単体テスティング212の結果を、順次検証段階116に対して開発された同様のテストに対する結果と比較することができる。

0035

単体テスティングの結果が順次実装の結果に対して検証された後、ソフトウェア開発者はコーナテスティング214を開発かつ遂行することができる。コーナテスティングは、ソフトウェアが、通常の動作パラメータの外部で発生するだけの入力に対処しなければならない不健全な場合をテストする方法である。一連のコーナテストがすでに順次検証段階116で順次実装に対して開発されていることが可能なので、コーナテスティング214の結果を、順次検証段階116に対して開発された同様のテストに対する結果と比較することができる。

0036

コーナテスティングの結果が順次実装の結果に対して検証された後、ソフトウェア開発者はエッジテスティング216を開発かつ遂行することができる。エッジテスティングは、ソフトウェアが、ただ1つのパラメータが通常の動作パラメータの外部で発生する場合の入力に対処しなければならない不健全な場合をテストする方法である。一連のエッジテストがすでに順次検証段階116で順次実装に対して開発されていることが可能なので、エッジテスティング216の結果を、順次検証段階116に対して開発された同様のテストに対する結果と比較することができる。

0037

ソフトウェアの順次実装の結果に対してソフトウェアの並列実装の結果を検証するために、ソフトウェア開発者は、ソフトウェアの並列実装の結果に信頼度テスティングを遂行することができ、その結果を順次検証段階からの順次実装の結果と比較する。追加的に開発者は、ソフトウェアの並列実装の結果に単体テスト、コーナテスト、およびエッジテストを遂行し、その結果を順次検証段階からの順次実装の結果と比較することになる。

0038

修正されたウォータフォール方法100を並列ソフトウェア開発ツールとして使用すると、開発者が並列実装を確信的かつ迅速にテストすることを可能にすることにより、ソフトウェア開発者はより大きな柔軟性を伴う並列実装を開発することができる。ソフトウェア開発ツールとして、本発明の実施形態による修正されたウォータフォール方法100は、順次検証段階116の完了の際に複数のまったく異なる並列テストの筋書を自動的に生成することを考慮したものである。並列実装の信頼度テスティングは難しく時間がかかることがよく知られているので、本発明の実施形態による修正されたウォータフォール方法100は、順次検証段階116からの前に調べられた結果と比較することにより、並列実装に対する結果を調べるための迅速かつ信頼可能な方途を提供する。

0039

並列ソフトウェア開発ツールとして、修正されたウォータフォール方法100を用いてソフトウェアを開発することにより、並列処理用のハードウェアアーキテクチャの性能テスティングおよび現場のデバッグが大きく強化される。配備されるソフトウェアを並列実装と順次実装との間で、トグル切り換えることは、ハードウェアアーキテクチャのベンチマーキングを考慮したものである。順次実装は、ハードウェアの速度のベースライン評価を提供する。順次実装のベンチマークを使用して開発者は、複数の異なるハードウェアアーキテクチャにわたる並列実装のベンチマークの情報に基づいた比較を行うことができる。例えば開発者またはエンドユーザは、比較のために、ハードウェアシステム内へのいくつかの異なるGPUカードの中で交換し、性能メトリクス収集することができる。加えて開発者またはエンドユーザは、CPUと一体化されるGPUカードおよびハードウェアシステムからの性能メトリクスを比較することができる。

0040

同様に、エラーが現場で発生する場合に、開発者はソフトウェアの順次実装を並列実装に交換することができるので、現場のデバッグを、修正されたウォータフォール方法100を用いてソフトウェアを開発することにより強化することができる。例えば、GPU内の処理の連鎖を分離するために、独立したメモリアドレッシングが順次コードに対して選定されている状態で、GPUで順次コードおよび並列コードの両方を走らせることにより、GPUの障害を分離することができる。実装をトグルで切り換えることを、ハードウェアまたはソフトウェアの障害としてバグを分離するために使用することができる。例えば開発者が、プログラムが第1のハードウェア構成によって作動するが、第2のハードウェア構成によって作動しないと判断する。2つの構成間で、トグルで切り換えることを可能にすることにより、開発者は、特定の機能およびコード内のバグの目標位置を迅速に分離することができる。

0041

並列ソフトウェア開発ツールとしての修正されたウォータフォール方法100の別の利点は、ソフトウェア製品の配備に関するものである。開発工程では結果として、ソフトウェアの並列および順次の両方の実装が得られるので、プラットフォームのロバスト性の向上が実現される。ソフトウェア開発ツールを、ソフトウェアのランタイム状態が、そのソフトウェアが配備されているプラットフォームで並列処理実装をサポート可能であるかどうかを検出するように構成することができる。例えばソフトウェア開発ツールは、シングルコアCPUを用いるシステムに順次実装を配備し、GPUベースのシステムに並列実装を配備する場合がある。

0042

修正されたウォータフォール方法100の別の利点は、順次および並列の実装の前の、要求および検証の段階の結果の高いレベルの再利用である。各々の結果として得られる実装のためにこれらの段階を個々に通って歩みを進める必要がないことにより、開発者は、時間を節約し機能的実装をより迅速に開発することができる。同様に、両方の実装を比較かつ検証するために1組の確認結果を有することは、時間節約の利点となる。

0043

記述した本説明では、最良の形態を含めて本発明を開示するために、さらには、任意のデバイスまたはシステムを作製かつ使用すること、および任意の組み込んだ方法を遂行することを含めて、本発明を実践することを当業者ならば誰でも可能にするために例を使用する。本発明の特許的な範囲は、特許請求の範囲により定義され、当業者が想到する他の例を含み得る。そのような他の例は、それらの例が、特許請求の範囲の文字通りの文言と異ならない構造要素を有するならば、またはそれらの例が、特許請求の範囲の文字通りの文言と実質的な違いのない等価の構造要素を含むならば、特許請求の範囲の範囲内にあることが意図される。

0044

10順次処理コンピュータアーキテクチャ
12命令プール
14処理装置
16データプール
20並列処理コンピュータアーキテクチャ
22 命令プール
24 処理装置
26 データプール
30ウォータフォール方法
32要求段階
34設計段階
36実装段階
38検証段階
40保守段階
100モデル
110 要求段階
112 設計段階
114 順次実装段階
116 順次検証段階
118並列処理段階
120 CPUコードに対する並列コード検証段階、順次実装に対する並列検証
122 保守段階
200 工程
210信頼度テスティング
212単体テスティング
214コーナテスティング
216エッジテスティング
218 順次実装、結果を順次実装テスティング結果と比較する

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ