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

Description

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

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

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

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

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

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

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

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

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

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

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

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

米国特許出願公開第２００８／０２８２２２８号明細書

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

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

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

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

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

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

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

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

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

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

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

修正されたウォータフォールモデル１００の段階は、要求１１０、設計１１２、順次実装１１４、順次検証１１６、並列実装１１８、順次実装に対する並列検証１２０、および保守１２２である。要求段階１１０は、設計段階１１２に連続して結合される。設計段階１１２は、順次実装段階１１４に連続して結合される。次いで順次実装段階１１４は、順次検証段階１１６および並列実装段階１１８の両方に結合される。順次検証段階１１６および並列実装段階１１８の両方は、順次実装に対する並列検証段階１２０に結合される。順次実装に対する並列検証段階１２０は、保守段階１２２に連続して結合される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１０ 順次処理コンピュータアーキテクチャ
１２ 命令プール
１４ 処理装置
１６ データプール
２０ 並列処理コンピュータアーキテクチャ
２２ 命令プール
２４ 処理装置
２６ データプール
３０ ウォータフォール方法
３２ 要求段階
３４ 設計段階
３６ 実装段階
３８ 検証段階
４０ 保守段階
１００ モデル
１１０ 要求段階
１１２ 設計段階
１１４ 順次実装段階
１１６ 順次検証段階
１１８ 並列処理段階
１２０ ＣＰＵコードに対する並列コード検証段階、順次実装に対する並列検証
１２２ 保守段階
２００ 工程
２１０ 信頼度テスティング
２１２ 単体テスティング
２１４ コーナテスティング
２１６ エッジテスティング
２１８ 順次実装、結果を順次実装テスティング結果と比較する

Claims (9)

1. 並列コンピューティング環境でソフトウェアを開発するための方法であって、
   前記ソフトウェアの順次実装を順次処理環境で開発するステップ、
   順次処理アーキテクチャを使用するステップと、
   前記ソフトウェアの前記順次実装が所期のように作動することを検証するステップ、
   前記ソフトウェアの前記順次実装の完了に続き、並列次処理アーキテクチャを使用して、並列実装を並列処理環境で開発するステップと、
   前記ソフトウェアの前記順次実装が所期のように作動することを検証するステップに続いて、前記ソフトウェアの前記並列実装のテストを含む結果を検証するステップと、
   前記ソフトウェアの前記順次実装および前記ソフトウェアの前記並列実装の両方を実行可能に保守するステップと、
   を含み、
   前記順次実装と前記並列実装は、前記順次処理アーキテクチャと前記並列処理アーキテクチャのそれぞれを採用した処理環境でコンピュータコードを開発することを含み、
   前記ソフトウェアの前記順次実装と、前記ソフトウェアの前記並列実装とは、前記異なるハードウェアアーキテクチャの対応するひとつにそれぞれ設計されている、
   ソフトウェアを開発するための方法。
2. 前記並列処理環境が少なくとも１つの中央処理装置（ＣＰＵ）と少なくとも１つのグラフィック処理装置（ＧＰＵ）を備え、
   前記順次処理環境がシングルコア中央処理装置（ＣＰＵ）を備える、請求項１に記載のソフトウェアを開発するための方法。
3. 前記ソフトウェアに対する要求を決定するステップ、および、
   前記ソフトウェアに対する設計を決定するステップ
   をさらに含み、
   これらのステップが、前記ソフトウェアを前記順次処理環境で開発する前記ステップより前に遂行される、
   請求項１または２に記載のソフトウェアを開発するための方法。
4. 前記ソフトウェアの前記順次実装の並列実装を並列処理環境で開発する前記ステップが、前記ソフトウェアの前記順次実装が所期のように作動することを検証する前記ステップと全体的に同時期に遂行される、請求項１乃至３のいずれかに記載のソフトウェアを開発するための方法。
5. 前記並列処理環境が少なくとも１つのグラフィック処理装置（ＧＰＵ）を備え、
   前記順次処理環境が少なくとも１つの中央処理装置（ＣＰＵ）を備える、
   請求項１乃至４のいずれかに記載のソフトウェアを開発するための方法。
6. 前記並列処理環境が少なくとも１つのマルチコアプロセッサを備え、
   前記順次処理環境が少なくとも１つの中央処理装置（ＣＰＵ）を備える、
   請求項１乃至５のいずれかに記載のソフトウェアを開発するための方法。
7. 前記ソフトウェアの前記並列実装のテストを含む前記結果を検証する前記ステップが、
   （ａ）前記ソフトウェアの前記並列実装の前記結果に信頼度テスティングを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、
   （ｂ）前記ソフトウェアの前記並列実装の前記結果に少なくとも１つの単体テストを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、
   （ｃ）前記ソフトウェアの前記並列実装の前記結果に少なくとも１つのコーナテストを遂行し、前記結果を前記順次実装の前記結果と比較するステップ、および、
   （ｄ）前記ソフトウェアの前記並列実装の前記結果に少なくとも１つのエッジテストを遂行し、前記結果を前記順次実装の前記結果と比較するステップ
   のうちの少なくとも１つを含む、
   請求項１乃至６のいずれかに記載のソフトウェアを開発するための方法。
8. 前記ソフトウェアのランタイム状態が並列処理をサポート可能であるかどうかを検出するステップをさらに含む、請求項１乃至７のいずれかに記載のソフトウェアを開発するための方法。
9. 前記ソフトウェアのランタイム状態が並列処理をサポート可能であるかどうかを検出する前記ステップからの信号に基づいて、前記ソフトウェアを並列処理モードで走らせるステップをさらに含む、請求項８に記載のソフトウェアを開発するための方法。