JP5081149B2 - 複数のプロセッサを備える機器上でのｘｓｌｔ処理における文書内並列処理をサポートする方法 - Google Patents

Description

関連出願の相互参照

本願は、「Ｍｅｔｈｏｄ ｆｏｒ Ｓｕｐｐｏｒｔｉｎｇ Ｉｎｔｒａ−ｄｏｃｕｍｅｎｔ ｐａｒａｌｌｅｌｉｓｍ ｉｎ ＸＳＬＴ ｐｒｏｃｅｓｓｉｎｇ ｏｎ ｄｅｖｉｃｅｓ ｗｉｔｈ ｍｕｌｔｉｐｌｅ ｐｒｏｃｅｓｓｏｒｓ」との名称で２００５年５月１８日に出願された整理番号Ｍ−１５９５２−Ｖ１ ＵＳの米国仮特許出願第６０／６８２５９９号と、「Ｍｅｔｈｏｄｓ ｆｏｒ Ｓｕｐｐｏｒｔｉｎｇ Ｉｎｔｒａ−Ｄｏｃｕｍｅｎｔ Ｐａｒａｌｌｅｌｉｓｍ ｉｎ ＸＳＬＴ Ｐｒｏｃｅｓｓｉｎｇ Ｏｎ Ｄｅｖｉｃｅｓ Ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｐｒｏｃｅｓｓｏｒｓ」という名称で２００５年９月２０日に出願された整理番号Ｍ−１５９５２ ＵＳの米国特許出願第１１／２３１４３０号に関連するものであり、これら出願の優先権を主張するものである。これら出願の開示を、その全体を参照することによって、本明細書に援用する。

発明の分野

本発明は、ＸＭＬ文書の処理に関するものである。詳細には、本発明は、ＸＭＬ文書のＸＳＬ変換（ＸＳＬＴ）を並列処理する方法に関するものである。

関連技術の説明

ＸＭＬ文書は、ＸＭＬ又は別種の文書（ＨＴＭＬ等）へと、例えば、拡張スタイルシート言語（ＸＳＬ）変換、すなわちＸＳＬＴを用いて、変換されることがある。この変換によって得られる文書は、通常、アプリケーション（Ｗｅｂブラウザ等）による処理に適した形態をとる。ＸＳＬＴは、１９９９年１１月にＷ３Ｃ推奨となったものであり、ＸＳＬ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ（ＸＳＬＴ）バージョン１．０に記載されている。この推奨規格の写しは、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｓｌｔから入手できる。通常、ＸＳＬＴは、ツリー構造で表され得る文書を操作する。ＸＳＬＴの用語では、ソース文書を「ソースツリー」といい、変換済み文書を「結果ツリー」という。

典型的な変換プロセスでは、ＸＳＬＴは、ＸＭＬパス言語（「ＸＰａｔｈ」）を用いて変換のマッチングパターンを定義する。ＸＰａｔｈは、ＸＭＬ文書の異なる部分をアドレス指定する。ソースツリーがＸＰａｒｔで定義されたＸＭＬ文書の部分とマッチングする場合に、ＸＳＬＴは、このソースツリーを結果ツリーに変換する。

しかしながら、ＸＳＬＴ処理は、計算負荷が高く、メモリアクセスも多い。さらに、ＸＳＬＴ処理は、通常、モバイル機器上では、デスクトップコンピュータ上より大幅に低速で実施される。これは、モバイル機器が、通常、より低いプロセッサ周波数とより低いメモリ帯域幅で動作し、比較的低機能のソフトウェアを実行するからである。このような欠点は、通常、専用ハードウェア（専用コプロセッサやハードウェアブロック等）を用いて克服される。例えば、汎用ＲＩＳＫプロセッサに加えて、現在のセルラ電話機は、通常、音声通信用のベースバンドプロセッサを備える。場合によっては、セルラ電話機は、グラフィックレンダリング用のＤＳＰコプロセッサも備えることがある。専用の追加ハードウェアを加えることによって追加機能を提供することは、モバイル機器でＸＳＬＴ処理を提供するのに実行可能な手法のように思われるが、このような手法は高くつく。したがって、専用ハードウェアを追加するのではなく、機器の汎用プロセッサを用いて追加機能を提供することが望ましい。

並列処理を活用して性能を達成することができる。文書処理では、文書間並列処理とは、複数の文書を複数のマシン又はプロセッサ上で同時に変換することを指し、各文書は、任意の時刻に、一つのマシン又はプロセッサのみによって処理される。かかる並列処理は、従来の並列又は分散計算処理ツールを使って達成することができ。このようなツールでは、通常、マシンの一つがマスタとして機能し、その他のマシンがスレーブとして機能する。マスタマシンは、各スレーブマシンに、「スタイルシート」と変換用のソース文書を送り、各スレーブマシンは、必要な変換を完了した後に、結果文書をマスタマシンに送り返す。現在、ＸＡ３５ ＸＭＬ Ａｃｃｅｌｅｒａｔｏｒ（Ｄａｔａ Ｐｏｗｅｒ Ｔｅｃｈｎｏｌｏｇｙ， Ｉｎｃ．のｈｔｔｐ：／／ｗｗｗ．ｄａｔａｐｏｗｅｒ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｘａ３５．ｈｔｍｌ、から提供されている）とＳｐｅｅｄｗａｙ ＸＳＬＴ Ａｃｃｅｌｅｒａｔｏｒ（Ｓａｒｖｅｇａ， Ｉｎｃ．のｈｔｔｐ：／／ｗｗｗ．ｓａｒｖｅｇａ．ｃｏｍ／ｘｍｌ−ｓｐｅｅｄｗａｙ−ａｃｃｅｌｅｒａｔｏｒ．ｐｈｐ、から提供されている）が、このＸＳＬＴ処理高速化の手法を用いた市販製品である。

また、文書間並列処理は、既存のスレッディング機構を用いて対称型マルチプロセッサプラットフォーム上で実現することもできる。この手法では、複数の実行スレッドを作成することができ、各スレッドが一つのプロセッサ上で動作し、１文書の変換を処理する。「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆａｓｔ ＸＳＬ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ」という名称で２００３年８月２１日に公開された米国特許出願公開公報第２００３／０１５９１１１号には、変換スレッドのプールをキャッシングし、複数文書の同時変換を可能にすることによって、並列ＸＳＬ変換を実現することが記載されている。

２００２年５月１日に出願された国際特許出願公開公報第ＷＯ２００２／０９１１７０号「Ｄｅｄｉｃａｔｅｄ Ｐｒｏｃｅｓｓｏｒ ｆｏｒ Ｅｆｆｉｃｉｅｎｔ Ｐｒｏｃｅｓｓｉｎｇ ｏｆ Ｄｏｃｕｍｅｎｔｓ Ｅｎｃｏｄｅｄ ｉｎ ａ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」には、非対称型マルチプロセッサプラットフォームを用いた文書処理の改善について開示されている。この非対称型マルチプロセッサプラットフォームでは、ＸＳＬＴ変換を含むＸＭＬ処理のために、専用プロセッサが提供されている。したがって、汎用プロセッサが、他のタスクの実行用により多く利用可能になる。

文書間並列処理は、スループット改善を目標としており、これは、サーバ環境に、特に、企業用途において、最適である。しかしながら、モバイルハンドセットでは、待ち時間とエネルギーの効率が、スループットよりも重要な問題である。

文書内並列処理とは、複数のマシン又はプロセッサを用いて１文書の変換を処理することを指す。かかる手法では、複数のマシン又はプロセッサが、総実行時間の少なくとも一部分において、同じ文書の変換を同時に実行する。「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｅｆｆｉｃｉｅｎｔ Ｍａｎａｇｅｍｅｎｔ ｏｆ ＸＭＬ Ｄｏｃｕｍｅｎｔｓ」という名称で２００１年１２月１３日に公開された国際特許出願公開公報第ＷＯ０１０９５１５５号には、文書とその処理コードが複数のマシンによって同時に処理されるように、文書を、分散共有オブジェクトの形態として処理することが開示されている。この手法では、各マシンが処理コードをローカルに実行して文書を変更する。ローカルに行われる更新は、伝搬され、同期される。

しかしながら、分散共有オブジェクトの手法もまた、無線アクセスネットワーク全域での同期のコストが分散処理によって得られる如何なる利益も容易に打ち消し得るモバイルハンドセットの環境では実際的でない。さらに、前述の国際特許出願公開公報は、ＸＳＬ変換の文書内並列処理に関する如何なる方法も開示していない。

Ｔａｒａｒｉ ＲＡＸ−ＣＰ Ｃｏｎｔｅｎｔ Ｐｒｏｃｅｓｓｏｒ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ ＸＭＬ（ＲＡＸ）Ｃｏｎｔｅｎｔ Ｐｒｏｃｅｓｓｏｒは、Ｔａｒａｒｉ，Ｉｎｃ．のｈｔｔｐ：／／ｗｗｗ．ｔａｒａｒｉ．ｃｏｍ／ｒａｘ／ｉｎｄｅｘ．ｈｔｍｌ、から提供されている）は、ＸＰａｔｈ要求を評価するＸＰａｔｈプロセッサのハードウェア実装を提供する。このＸＰａｔｈプロセッサは、一つ以上の他のプロセッサと並列に動作し、同時の要求を処理することができる。しかしながら、Ｔａｒａｒｉ ＲＡＸ−ＣＰ Ｃｏｎｔｅｎｔ Ｐｒｏｃｅｓｓｏｒは、ＸＰａｔｈ式評価だけを並列処理し、残りの変換を並列処理しない。ＸＰａｔｈ式評価は、ＸＳＬ変換の総コストの主要部分ではないため、結果として得られる改善は、実行時間においてもエネルギー効率においても限られたものになる。

概要

本発明の一実施形態によれば、ＸＳＬ変換プロセスを個別にスケジュール可能なサブタスクに分割し、個別にスケジュールされたＸＳＬＴ処理サブタスクの同期を取り、処理結果をマージする方法が開示される。ＸＳＬ変換は、（ａ）ソース文書のツリー表現を生成するソース文書構文解析と、（ｂ）通常、スタイルシートの「ａｐｐｌｙ−ｔｅｍｐｌａｔｅ」要素によってアクティブ化されるノード選択及びテンプレートマッチングと、（ｃ）テンプレートをノードに適用するテンプレート実行と、を含む。

一実施形態では、各ＸＭＬ要素が、「構文解析タスク」又は「ＰＴ」サブタスクで表される別個のサブタスクによって構文解析される。要素を構文解析することは、その要素の子要素と他の構文（テキストノードや処理命令等）を構文解析することを伴うので、ＰＴサブタスクは、別の（「親」）ＰＴサブタスク内にネストさせることができる。ノード選択及びテンプレートマッチングは、「マッチングタスク」又は「ＭＴ」サブタスクにおいて実行される。ＭＴサブタスクは、一つ又は複数のＰＴサブタスクの結果として生じることがあり、一つ以上のテンプレート実行（「ＥＴ」）サブタスクを生成することもある。ＥＴサブタスクは、ＭＴサブタスクによって作成される。ＥＴサブタスクは、一つ以上のＰＴサブタスクの完了の結果として生じることがあり、一つ以上のＭＴサブタスクを作成することもある。

一実施形態では、ソースツリーが全てのサブタスク間で共有され、ＰＴサブタスクはソースツリーへの書込みを行い、ＭＴサブタスクとＥＴサブタスクは、ソースツリーからの読取りを行う。ＭＴサブタスクとＥＴサブタスクはまた、結果ツリーも共有する。親ＰＴサブタスクは、その子ＰＴサブタスクの何れかが処理中である間は、ブロックされる。ブロックされたＰＴサブタスクは、文書ツリー内のそれに対応するノードにフラグを立てる。

ＥＴサブタスクは、ＭＴサブタスクに「プレースホルダ」を割り当て、ＭＴの変換結果が後に結果文書にマージされ得るようにする。変数を読み取り又は書き込むＥＴサブタスクは、それらの結果にＥＴサブタスクが依存する他の全てのＥＴサブタスクとＭＴサブタスクが完了するまで、ブロックされる。一実施形態では、ＥＴサブタスクとＰＴサブタスクは、以下のように順序付けされる。（ａ）同じＭＴサブタスクによって作成されるＥＴサブタスクは、作成の順に完了される。（ｂ）同じＥＴサブタスクによって作成されるＭＴサブタスクは、作成の順に完了される。（ｃ）親ＥＴサブタスクによって作成されるＭＴサブタスクの子ＥＴサブタスクは、その親ＥＴサブタスクが完了する前に完了する。

ＥＴサブタスクは、そのＥＴサブタスクが、ＰＴサブタスクが完了する前に、そのＰＴサブタスクに対応するノードの子にアクセスすることが可能であるときに、そのＰＴサブタスク上でブロックされる。ブロックされたＥＴサブタスクは、そのＰＴサブタスクブロックリストに置かれる。このＥＴサブタスクは、ブロック側のＰＴサブタスクが完了したときにブロックリストから除去される。ＭＴサブタスクは、その値にＸＰａｔｈ式が依存する変数が完全に評価される前に、そのＭＴサブタスクがそのＸＰａｔｈ式を評価することが可能であるときに、ＰＴサブタスクによってブロックされる。このＭＴサブタスクは、そのＰＴサブタスクのブロックリストに置かれる。ノード集合の式（すなわち、ＸＭＬ文書ノードを評価する式）では、ＭＴサブタスクは、ＰＴサブタスクが進行した（子要素の構文解析を完了する等）ときに、通知を受ける。

本発明の別の実施形態によれば、モバイル機器の複数のプロセッサ上でサブタスクをスケジュールして文書変換の実行時間とエネルギー効率を改善する方法が開示される。一実施形態では、サブタスクが、例えば、リアルタイムスケジューリングアルゴリズム等を用いて、各プロセッサに割り当てられる。リアルタイムスケジューリングアルゴリズムは、マルチプロセッサのリアルタイムオペレーティングシステムによって一般的に実施されるものとすることもでき、複数のプロセッサのうちの一つでタスクとして実行されるカスタマイズされたアルゴリズムとすることもできる。

本発明の一実施形態によれば、リアルタイムスケジューリングアルゴリズムは、静的値と動的値の２種類の入力値を受け取る。静的入力値は、ハードウェアアーキテクチャに関するものであり、動的入力値は、処理環境（プロセッサ負荷、バス帯域幅、電池レベル、データ依存関係等）の現在の状態に関するものである。

本発明の一実施形態では、オフラインプロファイリングが、異なるタスク処理の各プロセッサによる取り扱いに関する相対的費用対効果に関する統計情報を提供する。この統計情報は、例えば、表形式で提示することができる。このよう表の各エントリは、例えば、各タスククラスのプロファイルデータを含むことができる。プロファイルデータには、例えば、タスククラスや、各プロセッサ上でそのクラスのタスクを実施する際の費用対効果を示す正規化メトリックが含まれる。費用対効果メトリックは、プロセッサ上での実行時間又はエネルギー消費を示す。このメトリックは、基準プロセッサでの対応のメトリックに対して正規化することができる。

一実装形態では、タスクを、異なる粒度レベルに分類することができる。例えば、最も粗い粒度レベルでは、タスクは、ＭＴサブタスク、ＰＴサブタスク、及びＥＴサブタスクとして分類され得る。中程度の粒度レベルでは、タスクは、スタイルシートに関連するサブタスクとして分類され得る（例えば、「スタイルシートＡを伴うＭＴサブタスク」、「スタイルシートＡを伴うＰＴサブタスク（ＰＴサブタスクは、実際には、スタイルシートではなく、ソース文書を構文解析することに留意されたい）」及び「スタイルシートＡを伴うＥＴサブタスク」等）。最も細かい粒度レベルでは、タスクは、スタイルシートと文書タイプとの関連で分類され得る（例えば、「タイプＴの文書に関するスタイルシートＡを伴うＭＴサブタスク」、「タイプＴの文書に関するスタイルシートＡを伴うＰＴサブタスク」、及び「タイプＴの文書に関するスタイルシートＡを伴うＥＴサブタスク」等）。

一実施形態では、複数のタスク粒度レベルでのプロファイル情報が利用可能である場合に、リアルタイムスケジューリングアルゴリズムは、最も細かいタスク粒度レベルに関連付けられたプロファイル情報を使用する。例えば、汎用のＭＴサブタスクの情報と、スタイルシートＡを伴うＭＴサブタスクの情報の双方が利用可能である場合に、リアルタイムスケジューリングアルゴリズムは、スタイルシートＡを伴うＭＴサブタスクの情報を選択する。

本発明の一実施形態によれば、リアルタイムスケジューラは、実行可能タスク（すなわち、ブロックされていないタスク）のタスクリストを保持する。アイドル状態の各プロセッサについて、スケジューラは、プロセッサの費用対効果メトリックに基づいて、そのプロセッサにタスクリストからタスクを割り当てる。タスクリストが空でなく、アイドル状態のプロセッサがある場合には、スケジューラは、使用中のプロセッサとそれらが実施しているタスクに注目し、その（プロセッサ、タスク）対のストールカウントを増大させる。

一実施形態では、（プロセッサ、タスク）対のストールカウントを用いて、その（プロセッサ、タスク）対の時間費用対効果メトリックが調整される。かかる調整は、特性のソース文書に起因するスキューに対処する。或いは、タスクに関連付けられるソース文書ノードの位置を用いて、費用対効果メトリックが調整されてもよい。ルートノードから遠く離れたソース文書ノードは、ルートノードに近いノードよりもキャッシュミスを引き起こす可能性が高い。したがって、基準プロセッサより大きいキャッシュを有するプロセッサは、ルートノードから遠く離れたノードに関連付けられるタスクでのより高い費用対効果メトリックを有するべきであり、一方、より小さいキャッシュを有するプロセッサは、より低い費用対効果メトリックを有する。

よって、本発明は、ＸＳＬ変換サブタスクの処理における文書内並列処理を提供する。その待ち時間（すなわち、文書処理開始から処理終了までの経過時間）を改善しない従来技術の文書間並列処理とは異なり、文書内並列処理は、待ち時間を改善し、したがって、モバイル機器により適切である。

本発明は、ＸＳＬＴ処理の特徴を更に活用して、効率を改善する。このようなＸＳＬＴ処理の特徴には、スタイルシート別のプロファイリングと、ソース文書構造別のプロファイリングがある。一実施形態では、特定の文書又はノードによって生じるプロファイリング情報中のスキューを動的に調整するために、ストールカウントとノード深さが測定される。

本発明は、以下の詳細な説明と添付の図面を考察すれば、よりよく理解されるものである。

好適な実施の形態の詳細な説明

この詳細な説明では、開示した各実施形態は、例示を目的とするものであり、例えば、全てのプロセッサ又はプロセスが全てのタスククラスを実行することのできるコンピュータシステムに適用可能である。しかしながら、本発明は、それだけに限定されるものではない。本発明は、一部又は全てのコンピュータプロセッサ又はプロセスが特定のタスククラスの実行のためにカスタマイズされるコンピュータシステムにも適用可能である。

本発明の一実施形態によれば、図３に示すように、ステップ３０１で、複数のプロセッサを備えるコンピュータシステムのプロセッサの一つ（「初期プロセッサ」）で、ＸＳＬ変換（ＸＳＬＴ）が開始される。ステップ３０２と３０３で、それぞれ、ソース文書とスタイルシートが獲得される。この初期プロセッサでスタイルシートがまだロードされていない場合には、スタイルシートがロードされ、前処理される。

ステップ３０４と３０５で、（図１に示す）ルート要素構文解析メソッドと（図２に示す）ルート要素変換メソッドがそれぞれ呼び出される。ルート要素構文解析メソッドは、図１にステップ１０１で開始されるものとして示されており、ステップ１０２で、ソース文書のルート要素を関連するノードとして有する「構文解析タスク」、即ち「ＰＴ」サブタスクを作成する。ステップ１０３で、作成されたＰＴサブタスクが、タスクリスト（「ＸＳＬＴサブタスクリスト」）に入れられる。次いで、ルート要素構文解析メソッドが終了する（ステップ１０４）。ルート要素変換メソッドは、図２にステップ２０１で開始されるものとして示されており、ステップ２０２で、ソース要素のルート要素を関連するノードとして有する「マッチングタスク」、即ち「ＭＴ」サブタスクを作成する。また、ステップ２０２では、「／」文字も、「ノード集合」選択として、ＸＰａｔｈ式として提供される。次いで、作成されたＭＴサブタスクがＸＳＬＴサブタスクリストに入れられて、ステップ２０４で、ルート要素変換メソッドが終了する。

ステップ３０４と３０５で、ルート要素構文解析メソッドとルート要素変換メソッドを開始した後に、ＸＳＬＴは、ステップ３０６で、プロセッサのそれぞれのスケジューラを開始し、ＸＳＬ変換の残りの実行の制御がこれらのスケジューラに渡される。次いで、ステップ３０７で、初期プロセッサ上のＸＳＬＴが終了する。

ＸＳＬＴによって各プロセッサで起動されるスケジューラは、ソース文書とスタイルシートの各対に対して、全てのプロセッサについて同じものである。このスケジューラは、ベースラインスケジューラ（例えば、図５に示すスケジューラ）でも、タスクの静的又はオフラインエネルギー消費プロファイル情報を考慮に入れるスケジューラ（例えば、図６に示すスケジューラ）でも、タスクの静的又はオフライン実行時間プロファイル情報を考慮に入れるスケジューラ（例えば、図７に示すスケジューラ）でも、オフラインプロファイル情報と動的プロファイル情報（すなわち、実行時に調整されるプロファイル情報）の双方を考慮に入れるスケジューラであってもよい。図８に、静的プロファイル情報と動的プロファイル情報の双方を考慮に入れるスケジューラを示す。

図５に示すように、ステップ５０１での開始時に、ベースラインスケジューラが、ＸＳＬＴサブタスクリストが空であるか否か（ステップ５０２）と、プロセッサがタスクを実行しているか否か（ステップ５０３）をチェックする。ＸＳＬＴサブタスクリストが空であり、全てのプロセッサがアイドル状態である場合に、ＸＳＬＴは完了され、スケジューラは終了する（ステップ５０４）。そうではなく、ＸＳＬＴサブタスクリストは空であるが、一つ以上のプロセッサがタスクを実行している場合に、スケジューラは、所定の期間においてスリープ状態となるか、又はブロックされ（ステップ５０５）てから、ステップ５０２に戻って、再度タスクリストを調べる。ＸＳＬＴサブタスクリストが空でない場合、スケジューラは、ステップ５０６で、ＸＳＬＴサブタスクリストからタスクを選択し、リストから除去する。ＸＳＬＴサブタスクリストは、全てのプロセッサによってアクセスされる共有リソースであるので、好ましくは、ＸＳＬＴサブタスクリストへの同時の、監視なしのアクセスを防ぐために、相互排他機構（ロック等）が設けられる。次いで、スケジューラは、ステップ５０７で、選択されたタスクに制御を移す。選択されたタスクが完了すると、ステップ５０２で、制御がスケジューラに戻される。

この実施形態では、ＸＳＬＴサブタスクリスト内の各タスクは、（ａ）ＰＴ、ＭＴ又はＥＴとすることのできるサブタスク型と、（ｂ）スタイルシートの名前と（この実施形態では、全てのサブタスクに単一のスタイルシートが使用されるので、暗黙的に提供され得る）、（ｃ）関連付けられているソース文書ノードと、（ｄ）サブタスク型が「ＥＴ」である場合には、テンプレートの識別情報と、（ｅ）サブタスク型が「ＭＴ」である場合には、関連付けられているＸＳＬ要素と、を含み得る。サブタスク型フィールド以外に、処理を円滑化するために、その他のフィールドの情報があることが望ましいが、タスクの実行時に求めることができるので、必須ではない。

図６は、プロセッサ上で実行されるスケジューラであって、エネルギー消費プロファイルを考慮に入れてプロセッサ上での実行用のタスクを選択するスケジューラを示している。図５のベースラインスケジューラとは異なり、図６のスケジューラは、エネルギー関連の費用対効果プロファイル情報を含む表６０８を用いて、ＸＳＬＴサブタスクリストからサブタスクを選択する。ＸＳＬサブタスクリスト上の各サブタスクについて、スケジューラは、サブタスクの記述を用いて、表６０８のエネルギー関連の費用対効果プロファイル情報からエネルギー関連の費用対効果メトリックを検索する。

以下の表は、エネルギープロファイル表の例である。エネルギープロファイル表の各列は、（ａ）タスク型（ＰＴ、ＭＴ又はＥＴ）、（ｂ）タスク識別子（ＩＤ）、（ｃ）プロセッサＩＤ、及び（ｄ）エネルギー消費指数である。

本実施形態では、特徴付けられるタスクを表す幾つかのタスクＩＤが定義される。あるタスクのタスクＩＤが表に提供されていない場合、そのタスクは、そのタスク型に関連する「デフォルト」値をとる。ソース文書はスタイルシート（すなわちＸＳＬＴ文書）より動的であるものとみなされるので、全てのＰＴは同じデフォルト値を用いることができる。以下の表では、第３列はプロセッサＩＤを提供しており、本例では「プロセッサ１」と「プロセッサ２」と呼ばれる二つのプロセッサを含むものと仮定している。第４列は、各タスク型とタスクＩＤについて、対応するタスク型とタスクＩＤをもつタスクが、二つのプロセッサのそれぞれに対して実行されるときの相対的エネルギー消費率を収集されたプロファイル統計に基づいて表す正規化エネルギー消費指数を提供する。

例えば、プロセスＩＤ「ＰＴ００１」を有するタスクの実行がスケジュールされる場合には、この表がアクセスされる。タスクＰＴ００１は表には明確に記載されていないので、デフォルトのＰＴのタスク型の表エントリが適用可能である。表に示すように、構文解析タスクは、プロセッサ１よりもプロセッサ２でよりエネルギー効率よく実施され（エネルギー消費指数が、プロセッサ１の１に比べて、プロセッサ２では０．３である）、タスクＰＴ００１は、プロセッサ２上で実行されるようにスケジュールされる。別の例として、表には、タスクＩＤ「ＭＴ００１」を有するＭＴタスクの表エントリがある。エネルギー消費指数は、プロセッサ２で実行されるときの（１．２）よりもプロセッサ１で実行されるとき（１）の方が低いため、タスクＭＴ００１は、プロセッサ１で実行されるようにスケジュールされる。同様に、ＭＴタスク型のタスクＭＴ００２は、プロセッサ２で実行されるようにスケジュールされる。これは、デフォルトの表エントリが、タスクＭＴ００２は、プロセッサ２上で実施される方がより効率的であることを示しているからである。

したがって、そのプロセッサで実行する際に最高の費用対効果メトリックを有するサブタスクが選択され（ステップ６０６）、ＸＳＬサブタスクリストから除去される。次いで、プロセッサの制御が、選択されたサブタスクに渡される（ステップ６０７）。

図７は、プロセッサ条で実行するスケジューラであって、実行時間を考慮に入れてプロセッサでの実行用のタスクを選択するスケジューラを示している。図５のベースラインスケジューラとは異なり、図７のスケジューラは、実行時間関連の費用対効果プロファイル情報を含む表７０８を用いて、ＸＳＬＴサブタスクリストからサブタスクを選択する。ＸＳＬサブタスクリスト上の各サブタスクについて、スケジューラは、サブタスクの記述を用いて、表６０８の実行時間関連の費用対効果プロファイル情報から実行時間関連の費用対効果メトリックを検索する。時間関連の費用対効果メトリックは、上記の表のエネルギー消費プロファイルデータと同様の態様で、表で提供することができる（すなわち、正規化エネルギー消費指数の代わりに、正規化実行時間指数を提供することができる）。最高の時間関連の費用対効果メトリックを有するサブタスクがプロセッサでの実行用に選択され（ステップ７０６）、ＸＳＬサブタスクリストから除去される。次いで、プロセッサの制御が、選択されたサブタスクに渡される（ステップ７０７）。

図８は、オフラインプロファイルとオンラインプロファイル調整の双方を用い、それに関連付けられているプロセッサ上で実行するためのサブタスクを選択するスケジューラを示している。静的、即ちオフラインのプロファイル情報を使ってタスク選択をサポートする図６と図７のスケジューラとは異なり、図８のスケジューラは、ランタイム情報を用いて静的プロファイル情報を調整する。図８に示すように、例えば、ステップ８１０と８１１で、関連性を有するエネルギー関連の、又は実行時間関連のプロファイル情報が、各プロセッサに対して選択される。ステップ８０８と８０９で、選択されたプロファイル情報が、プロセッサにおける動的条件に対して調整される。例えば、ステップ８０８で、実行時間関連のプロファイル情報が使用される場合に、サブタスクの費用対効果メトリックを調整するように、（プロセッサ、サブタスク）対に関してストールカウントが保持されてもよい。別の例として、スケジューラは、実行時間関連の、又はエネルギー関連のプロファイル情報が使用される場合に、現在のサブタスクと関連付けられているソース文書内部のノードの深さを調べて（ステップ８０９）、サブタスクの費用対効果メトリックを調整してもよい。ＸＳＬサブタスクリスト上の各サブタスクについて、スケジューラは、サブタスクの記述を用いて、表８０８内の調整された費用対効果プロファイル情報に基づいて、対応する費用対効果メトリックを検索する。最高の費用対効果メトリックを有するサブタスクがプロセッサでの実行用に選択され（ステップ８０６）、ＸＳＬサブタスクリストから除去される。次いで、プロセッサの制御が選択されたサブタスクに渡される（ステップ８０７）。

一実施形態において、スケジューラは、（ａ）電力利用可能性の判定に基づき、もっぱら実行時間関連のプロファイル情報、又はエネルギー関連のプロファイル情報だけを選択的に使用することによって、或いは（ｂ）現在の電力利用可能性、所望のサービス品質メトリック、又はデフォルトの優先度に基づき、二つ以上のプロファイル情報の組の間での動的な選択を行うことによって、動作環境に適合する。この方法は、電力消費と実行時間の動的平衡を維持する。十分な電力が利用可能な場合、この平衡は、実行速度の方に傾いてもよい。逆に、平衡は、電力利用可能性が減少するにつれて、電力消費の方に傾いてもよい。その時々において、実行時間と電力消費の双方の重みつきの組み合わせを使用することができる。

図９は、本発明の一実施形態に従って、ＭＴサブタスクを実行するプロセスを示している。図９に示すように、ステップ９０２で、図９のプロセスは、ＭＴサブタスクと関連付けられているノード集合のＸＰａｔｈ式を評価し始める。ステップ９０３で、生成されたノード集合内に含まれる各ノードについて、マッチングテンプレートがそのノード用に選択され、変換結果用に空間が予約され、ノードに関連付けられたＥＴサブタスクが作成される。ステップ９０４で、評価が一部完了している場合（すなわち、ＭＴサブタスクは、まだ完了していない対応のＰＴサブタスクによって、別のノードがノード集合に追加されると期待する。図１０に関連する以下の考察を参照されたい）、ＭＴサブタスクは、これをブロックするＰＴサブタスクのブロックリストに追加される（ステップ９０５）。次いで、制御がスケジューラに渡される。ノード集合に一つ以上の新しいノードが追加された後に、ブロック側のＰＴがＭＴサブタスクを起動すると、評価がステップ９０６に進む。ステップ９０６で、変換結果用に空間が予約され、新しく追加された各ノード用にＥＴサブタスクが作成される。評価は、ノード集合で生成される全てのノードが評価されるまで続く。

図１０は、本発明の一実施形態に従って、ＰＴサブタスクを実行するプロセスを示している。図１０に示すように、ステップ１００１でＰＴサブタスクが開始される。ステップ２００２で、次の構文が、新しい子要素が生じたことを示す「ＳＴＡＲＴ＿ＥＬＥＭＥＮＴ」タグである場合、ＰＴサブタスクは、この子要素用の子ＰＴサブタスクを作成する（ステップ１００３）。次いで、ステップ１００５で、子ＰＴサブタスクの実行を可能にするために、制御が渡される。子ＰＴが完了すると、ＰＴサブタスクは、それ自体をＸＳＬＴサブタスクリストに戻し入れ（ステップ１００４）、制御をスケジューラに渡す（ステップ１００５）。スケジューラが制御をＰＴサブタスクに戻すと、ＰＴサブタスクは、次の構文が「ＳＴＡＲＴ＿ＥＬＥＭＥＮＴ」タグ（ステップ１００２）であるか、それとも「ＥＮＤ＿ＥＬＥＭＥＮＴ」タグ（ステップ１００６）であるかをチェックする。次の構文が「ＳＴＡＲＴ＿ＥＬＥＭＥＮＴ」タグでも「ＥＮＤ＿ＥＬＥＭＥＮＴ」タグでもない場合には、構文解析は完了せず、ステップ１００７で次の構文解析が実行される。しかしながら、ステップ１００６で、次の構文が「ＥＮＤ＿ＥＬＥＭＥＮＴ」タグである場合、現在のＰＴサブタスクは完了される。次いで、親ＰＴサブタスクがＸＭＬサブタスクリストに戻され、制御が親ＰＴサブタスクに戻される（ステップ１００８）。よって、現在のＰＴサブタスクは終了する（ステップ１００９）。

図１１は、本発明の一実施形態に従って、ＥＴサブタスクを実行するプロセスを示している。図１１に示すように、ステップ１１０１で、ＥＴサブタスクが初期設定される。ステップ１１０２で、要素実行プロセス（フローチャート１１５０）が呼び出される。フローチャート１１５０では、ステップ１１０４で初期設定され、関連するテンプレート内の次の構文が獲得される（ステップ１１０５）。その次の構文が「ＥＮＤ＿ＥＬＥＭＥＮＴ」タグである場合、評価は完了し、フローチャート１１５０のプロセスが完了する（ステップ１１０７）。その後、ステップ１１０３で、ＥＴサブタスクが完了する。次いで、制御がスケジューラに戻される。

ステップ１１０６で、次の構文が「ＥＮＤ＿ＥＬＥＭＥＮＴ」タグでない場合、ＥＴサブタスクは、次の構文が「Ａｐｐｌｙ−ｔｅｍｐｌａｔｅ」要素であるかどうか調べる（ステップ１１０８）。次の構文が「Ａｐｐｌｙ−ｔｅｍｐｌａｔｅ」要素である場合、変換結果に空間が予約され（ステップ１１０９）、次いで、この要素用にＭＴサブタスクが作成される（ステップ１１１０）。現在のＥＴサブタスクがＰＴタスク上でブロックされる（すなわち、次の構文が、まだ完了していない実行側ＰＴサブタスクの結果に依存する）場合、ＥＴサブタスクは、そのＰＴサブタスクのブロックリストに入れられる（ステップ１１１１）。ＥＴサブタスクが変数へのアクセスを必要とする場合、変数が、それらの値に未解決の依存関係がないかどうか（例えば、いずれかの変数が、まだ完了していない評価から値を受け取るのを待っているかどうか等）を判定するためにチェックされる。ＥＴサブタスクは、要素に依存関係がなくなるまでブロックされる（ステップ１１１２）。要素評価が可能になると（ステップ１１１５）、要素が評価される（ステップ１１１５）。要素の評価後、ＥＴサブタスクは、ステップ１１０５に戻って、次の構文を取得する。

前述の実施形態では、例として、多重処理システムが、同じメモリアーキテクチャを共用する同一のプロセッサ（すなわち、同じ速度で動作し、同じ電力を消費し、同じローカルキャッシュ構成を有する）を備えるものと仮定している。ＸＰａｔｈ式を評価する専用ハードウェア評価（「ＸＰａｔｈＭａｔ」）構成要素を含む全ての機能構成要素のスケジューリングを調整するために、通常は、プロセッサの一つにグローバル制御機能が割り当てられる。各ＸＰａｔｈＭａｔ構成要素についてスケジューリングアルゴリズムによって考慮される静的入力は、各プロセッサに対して同じである。しかしながら、各プロセッサへの動的入力は、アーキテクチャとシステムソフトウェアの能力に応じて異なっていてもよい。

或いは、プロセッサには、汎用プログラマブルプロセッサと、専用コプロセッサ又はハードウェアブロックの双方が含まれていてもよく、専用コプロセッサ又はハードウェアブロックは、もっぱら特定のＸＰａｔｈＭａｔサブタスクの実行のために設計されており、或いは、ＸＰａｔｈＭａｔサブタスクの処理要件と厳密に合致するアーキテクチャ設計を提供するものである。

一実施形態では、汎用プロセッサの一つで実行されるよう割り当てられる、スケジューラの単一のインスタンスが、利用可能なプロセッサ上で実施されるべき全てのサブタスクをスケジュールする役割を果たす。

第３の代替として、ソース文書の文書ツリーがすでに存在するときには、構文解析は不要である。よって、この実施形態では、ＸＳＬ変換は、文書ツリーを直接獲得し、図１のルート要素構文解析メソッドを呼び出さない。

一実施形態では、各ＥＴ又はＭＴサブタスクは、データ依存関係フラグ（ＤＤＦ）と関連付けられる。このフラグを設定し、クリアする規則は、以下の通りである。即ち、（ａ）別のサブタスクによって作成されていないサブタスクは、ＤＤＦフラグをクリアして作成される。（ｂ）ＤＤＦフラグがクリアされているサブタスクがサブタスクを作成するときには、このサブタスクは、それ自体のＤＤＦフラグを立て、その第１の子サブタスクのＤＤＦフラグをクリアし、他の子サブタスクのＤＤＦフラグを立てる。（ｃ）ＤＤＦフラグが立っているサブタスクがサブタスクを作成するときには、その全ての子サブタスクのＤＤＦフラグが立てられる。（ｄ）ＤＤＦフラグがクリアされているサブタスクが完了するとき、このサブタスクは、もしあれば、従属サブタスクに「ＣＬＥＡＲ」信号を送り、従属サブタスクがなければ、その親タスクに送る。変換プロセスは、サブタスクに親タスクがなくなったときに完了する。サブタスクがＣＬＥＡＲ信号を受け取ると、ＣＬＥＡＲ信号は、まだ完了していないその第１の子サブタスクに転送される。

図４は、ＰＴサブタスクＰ１で構文解析されるルートノードにおけるＸＳＬＴプロセスを示すタスクグラフを示している。図４に示すように、ＥＴサブタスクＥ１、Ｅ２、Ｅ３、及びＥ４は、それぞれ、ＰＴサブタスクＰ２、Ｐ５、Ｐ３、及びＰ６から作成される。これらの依存関係は、ソース文書の構造と、関連する一以上のスタイルシートから決定される。例えば、ＥＴタスクＥ１は、ＰＴタスクＰ２に依存する。というのは、ＥＴタスクＥ１の実行時に、Ｅ１が、ＰＴタスクＰ２から提供される情報を必要とし得るからである（例えば、Ｅ１は、「ＡＢＣ」という名前のノードが、Ｐ２によって処理されるソース文書の子ノードであるか否かを判定することある）。

以上の詳細な説明は、本発明の具体的な実施形態を説明するために示したものであり、限定することを意図したものではない。本発明の範囲内で多くの変更及び変形が可能である。本発明は、添付の特許請求の範囲で定義される。

本発明の一実施形態に係るルート要素構文解析メソッドを示すフローチャートである。 本発明の一実施形態に係るルート要素変換メソッドを示すフローチャートである。 本発明の一実施形態に係るＸＳＬ変換のメソッドを示すフローチャートである。 本発明の一実施形態に係るサブタスクグラフの一例を示す図である。 本発明の一実施形態に係るベースラインスケジューラを示すフローチャートである。 本発明の一実施形態に従って、タスクのエネルギー消費に関連する静的又はオフラインプロファイリング情報を考慮に入れるスケジューラを示すフローチャートである。 本発明の一実施形態に従って、タスクの実行時間に関連する静的又はオフラインプロファイリング情報を考慮に入れるスケジューラを示すフローチャートである。 本発明の一実施形態に従って、静的又はオフラインプロファイル情報と動的プロファイル情報の双方を考慮に入れるスケジューラを示すフローチャートである。 本発明の一実施形態に係るＭＴサブタスクを実行するプロセスを示す図である。 本発明の一実施形態に係るＰＴサブタスクを実行するプロセスを示す図である。 の本発明の一実施形態に係るＥＴサブタスクを実行するプロセスを示す図である。

Claims (24)

1. 複数のプロセッサを備えるコンピュータシステムにおいて構造化文書の変換を並列処理するための方法であって、
   構造化ソース文書とスタイルシートを受け取るステップと、
   前記ソース文書の構造のルートノード用の構文解析タスクを作成し、前記構文解析タスクをタスクリストに置くステップと、
   前記ルートノードの評価タスクを作成し、前記評価タスクを前記タスクリストに置くステップと、
   前記複数のプロセッサの各々でスケジューラを動作させるステップであり、各スケジューラが、前記タスクリストから一度に一つのタスクを、該スケジューラが作動している前記プロセッサによって実行されるように選択し、該スケジューラは、各プロセッサにおける前記タスクのエネルギー消費に関連するプロファイルデータに従って、前記タスクリストから前記タスクを選択する、該ステップと、
   を含み、
   前記スケジューラが、前記プロファイルデータを用いる際に、前記タスクリスト内のタスクと関連付けられている前記ソース文書内部のノードの深さを調べることで該プロファイルデータを調整する、
   方法。
2. 構文解析タスクの実行が、各子ノード用の構文解析タスクを再帰的に生成し、新しく作成された前記構文解析タスクをタスクリストに置く、請求項１に記載の方法。
3. 評価タスクの実行が、各テンプレートマッチングステートメント用のマッチングタスクを作成し、新しく作成された前記マッチングタスクをタスクリストに置く、請求項１に記載の方法。
4. マッチングタスクの実行が、構文解析タスクによって構文解析されるゼロ個以上のノードを、前記スタイルシート内のゼロ個以上のテンプレートにマッチングさせる、請求項３に記載の方法。
5. 構文解析タスクによって解析されるノードを前記スタイルシート内のテンプレートにマッチングさせ次第、対応する前記ノードを用いて前記テンプレートを評価する評価タスクを作成し、前記評価タスクを前記タスクリストに置くステップを更に備える、請求項４に記載の方法。
6. 前記スケジューラが、実行時間に関連するプロファイルデータに従って、前記タスクリストから前記タスクを選択する、請求項１に記載の方法。
7. 前記タスクが、電力利用可能性に従い、実行時間要因とエネルギー消費要因との重み付きの組み合わせに基づいて選択される、請求項１に記載の方法。
8. 前記スケジューラが、静的プロファイルデータと動的プロファイルデータの双方に従って、前記タスクリストから前記タスクを選択する、請求項１に記載の方法。
9. 前記動的プロファイルデータが、プロセッサ負荷要因、バス帯域幅要因、電池レベル要因、及びデータ依存関係要因のうちの一つ以上を含む、請求項８に記載の方法。
10. 前記静的プロファイルデータが、プロファイルデータの表として提供され、前記動的プロファイルデータが、前記プロファイルデータの表内の前記静的プロファイルデータを随時調整するために使用される、請求項８に記載の方法。
11. 前記タスクリストが、相互排他機構を介してアクセスされる、請求項１に記載の方法。
12. 前記複数のプロセッサが同一の能力を有する、請求項１に記載の方法。
13. 前記複数のプロセッサの一部が、ＸＭＬ文書処理用にカスタマイズされたプロセッサを備える、請求項１に記載の方法。
14. コンピュータシステムにおいて構造化文書の変換を並列処理するための方法であって、
    構造化ソース文書とスタイルシートを受け取るステップと、
    前記ソース文書の構造を構文解析するための構文解析タスクを作成するステップであって、前記構文解析タスクはルートノードに関連付けられたノードセットを提供する、該ステップと、
    前記スタイルシート内の対応するテンプレートを前記ノードセット内の第１のノードにマッチングさせるために第１のマッチングタスクを作成するステップであって、前記第１のマッチングタスクは前記対応するテンプレートを前記第１のノードに適用する評価タスクを作成し、前記評価タスクが第２のテンプレートを検知した場合には、前記評価タスクは、前記第２のテンプレートを前記ノードセット内の第２のノードにマッチングさせる第２のマッチングタスクを作成する、該ステップと、
    を含み、
    スケジューラが、実行時間に関連するプロファイルデータに従って、複数のプロセッサにおける構文解析タスク、マッチングタスク及び評価タスクの実行をタスクリストからスケジュールし、
    前記スケジューラが、前記プロファイルデータを用いる際に、前記タスクリスト内のタスクと関連付けられている前記ソース文書内部のノードの深さを調べることで該プロファイルデータを調整する、
    方法。
15. 構文解析タスクが、各子ノード用の構文解析タスクを再帰的に生成し、該子ノードを前記ノードセットに含める、請求項１４に記載の方法。
16. マッチングタスクが評価タスクを作成し、評価タスクがマッチングタスクを作成することができるように、前記方法が再帰的に適用可能である、請求項１４に記載の方法。
17. マッチングタスクが、前記構文解析タスクが追加ノードを前記ノードセットに含めることを完了するのを待つためにブロックする、請求項１４に記載の方法。
18. スケジュールされた各タスクが、電力利用可能性に従い、実行時間要因とエネルギー消費要因との重み付きの組み合わせに基づいて選択される、請求項１４に記載の方法。
19. 前記スケジューラが、静的プロファイルデータと動的プロファイルデータの双方に従って、前記タスクリストから前記スケジュールされたタスクを選択する、請求項１４に記載の方法。
20. 前記動的プロファイルデータが、プロセッサ負荷要因、バス帯域幅要因、電池レベル要因、及びデータ依存関係要因のうちの一つ以上を含む、請求項１９に記載の方法。
21. 前記静的プロファイルデータが、プロファイルデータの表として提供され、前記動的プロファイルデータが、前記プロファイルデータの表内の前記静的プロファイルデータを随時調整するために使用される、請求項２０に記載の方法。
22. 前記タスクリストが、相互排他機構を介してアクセスされる、請求項１４に記載の方法。
23. 前記複数のプロセッサが同一の能力を有する、請求項１４に記載の方法。
24. 前記複数のプロセッサの一部が、ＸＭＬ文書処理用にカスタマイズされたプロセッサを備える、請求項１４に記載の方法。

Images