評価期間Paの間のプロセッサ負荷のアセスメントを考慮してパフォーマンス状態を選択するプロセッサパフォーマンスマネジメントPPMシステムによってプロセッサのパフォーマンス状態が制御されている間に、バックグラウンドにおいてタスクを実行する場合に、当該プロセッサによって消費されるエネルギーを低減する方法であって、当該エネルギー低減方法は:aアクティブ期間Tの間に前記プロセッサに前記タスクの一部を実行させるステップと、b各アクティブ期間の後、インターバルSについて、前記プロセッサに前記タスクを実行することを停止させるステップと、c前記タスクが完了されるまで、ステップa及びステップbを繰り返し実行するステップと、を含み、前記タスクの実行の開始と終了との間の前記PPMシステムの各評価期間Paの間に、100未満であるが0よりも大きい平均的な負荷を前記タスクの実行が前記プロセッサに課すように、前記アクティブ期間T及び前記インターバルsの持続期間が選択される、エネルギー低減方法。各アクティブ期間Tの前記持続時間は、前記PPMシステムの前記評価期間Paの持続時間よりも少ない、請求項1に記載のエネルギー消費低減方法。ステップbは、前記タスクの命令シーケンスが1つ以上のダミー命令を含むように設定し、前記インターバルSの間に前記プロセッサに当該ダミー命令の1つ以上を実行させることを含む、請求項1又は請求項2に記載のエネルギー消費低減方法。ステップbは、前記インターバルSについて、前記タスクをスリープにすることを含む、請求項1又は請求項2に記載のエネルギー消費低減方法。実行中に、現在の実行期間の間に経過した時間のチェックが為され、所定の期間Tが経過した場合には前記インターバルSについて前記タスクをスリープにするように要求が為されるように、前記タスクは構成される、請求項1に記載のエネルギー消費低減方法。実行中に、現在の実行期間の間に経過した時間のチェックが為され、所定の期間Tが経過した場合には前記インターバルSについて前記タスクをスリープにするように要求が為されるように、前記タスクは構成される、請求項2に記載のエネルギー消費低減方法。前記タスクは、前記タスクがファンクションコールを呼び出す度に、前記経過した時間のチェックが為されるように構成される、請求項5又は請求項6に記載のエネルギー消費低減方法。前記プロセッサに依存する前記アクティブ期間T及び前記インターバルSのうちの少なくとも1つの前記持続期間を設定するステップ、を含み、前記タスクを実行するために前記オペレーティングシステムが用いられる、請求項1に記載のエネルギー消費低減方法。前記アクティブ期間T及び前記インターバルSのうちの少なくとも1つの前記持続期間は、前記タスクの実行の前記開始と前記終了との間に変化する、請求項1に記載のエネルギー消費低減方法。コンピュータ使用可能な媒体上に記憶され、プロセッサCPUによって実装されるように適合されるタスクを表すソフトウェアコードを含むコンピュータプログラムプロダクトであって、前記プロセッサのパフォーマンス状態は、評価期間Paの間のプロセッサ負荷のアセスメントを考慮して前記プロセッサについてのパフォーマンス状態を選択するプロセッサパフォーマンスマネジメントPPMシステムによって制御され、前記タスクは、前記プロセッサを用いて当該コンピュータプログラムプロダクトが実行される場合に、それぞれのアクティブ期間Tの間に前記タスクの一部が前記CPUによって実行され、前記アクティブ期間の合間に前記プロセッサが前記タスクを実行することを停止するインターバルSが設けられるように適合されるプログラムコードを含み、前記アクティブ期間T及び前記インターバルSの持続時間が、前記タスクの実行の開始と終了との間の前記PPMシステムの各評価期間Paの間に、前記タスクの実行が100未満であるが0よりも大きい平均的な負荷を前記プロセッサに課すように、前記プログラムコードは適合される、コンピュータプログラムプロダクト。前記プログラムコードは、前記評価期間Paの持続時間よりも持続期間の短いアクティブ期間Tの間に、前記タスクを実行させるように適合される、請求項10に記載のコンピュータプログラムプロダクト。プロセッサを備え、評価期間Paの間のプロセッサ負荷のアセスメントを考慮してプロセッサパフォーマンス状態を選択するプロセッサパフォーマンスマネジメントPPMを実装するように構成されるコンピューティング装置であって、前記コンピューティング装置は、評価期間選択されるタスクの一部を評価期間Paの間に繰り返し実行し、各アクティブ期間の後、インターバルSについて前記選択されるタスクを実行することを停止することによって、前記選択されるタスクを実行するように構成され、前記選択されるタスクの実行の開始と終了との間の各評価期間Paの間の前記PPMシステムの各評価期間Paの間に、前記選択されるタスクの前記実行が、100未満であるが0よりも大きい平均的な負荷を前記プロセッサに課すように前記アクティブ期間T及び前記インターバルSの持続時間が設定される、コンピューティング装置。前記アクティブ期間Tの前記持続時間は、前記評価期間Paの持続時間よりも短い、請求項12に記載のコンピューティング装置。プロセッサ上で実行されるべきタスクを表すプログラムコードを再コンパイルするように適合されるコンパイラであって、プロセッサパフォーマンス状態は、評価期間Paの間のプロセッサ負荷を考慮して当該パフォーマンス状態を選択するプロセッサパフォーマンスマネジメントシステムによって制御され、前記コンパイラは、前記プロセッサ上で実行される場合に、前記プログラムコードを再コンパイルし、それにより、再コンパイルされるタスクがaアクティブ期間Tについて実行されるステップと;b各アクティブ期間Tの後、インターバルSについて実行を停止するステップと;c前記タスクの実行が完了するまで、ステップa及びステップbを繰り返すステップと;を実行するように構成され、再コンパイルされる前記プログラムコードは、前記アクティブ期間T及びインターバルSの持続時間により、前記タスクの実行の開始と終了との間の前記PPMシステムの各評価期間Paの間に、前記タスクの実行が、100未満であるが0よりも大きい平均的な負荷を前記プロセッサに課すように適合される、コンパイラ。再コンパイルされる前記プログラムコードは、前記アクティブ期間Tの持続時間が前記評価期間Paの持続時間よりも短くなるように適合される、請求項14に記載のコンパイラ。前記コンパイラは、前記プログラムコードを再コンパイルし、それにより、前記再コンパイルされるタスクが前記プロセッサ上で実行される場合に、前記再コンパイルされるタスクがファンクションコールを呼び出す度に、経過したクロックサイクルを確認するステップと、前記アクティブ期間Tについて前記タスクが前記プロセッサ上でアクティブであったことを当該確認するステップが示す場合、前記インターバルSについて前記タスクをスリープにするステップと、を実行するように構成される、請求項14に記載のコンパイラ。コンピュータ使用可能な媒体上に記憶され、プロセッサを備えるコンピューティング装置上で実行される場合に、当該プロセッサによるタスクの実行を制御するように適合されるソフトウェアコードを含むコンピュータプログラムプロダクトであって、前記プロセッサのパフォーマンス状態は、評価期間Paの間のプロセッサ負荷を考慮してプロセッサパフォーマンス状態を選択するプロセッサパフォーマンスマネジメントシステムによって制御され、前記ソフトウェアコードは、前記プロセッサに、aアクティブ期間Tについて前記タスクを実行するステップと;b各アクティブ期間Tの後、インターバルSについて前記タスクを実行することを停止するステップと;c前記タスクの実行が完了するまで、ステップa及びステップbを繰り返すステップと;を実行させるように適合され、前記アクティブ期間T及びインターバルSの持続時間により、前記タスクの実行の開始と終了との間の前記PPMシステムの各評価期間Paの間に、前記タスクの実行が、100未満であるが0よりも大きい平均的な負荷を前記プロセッサに課す、コンピュータプログラムプロダクト。前記アクティブ期間Tの持続時間が前記評価期間Paの持続時間よりも短い、請求項17に記載のコンピュータプログラムプロダクト。本発明は、計算集約的ではあるがユーザにとって緊急でないタスク、即ち、実行の完了のために要する時間における幾らかの増加をユーザが許容できるタスクにプロセッサが直面する場合に、比較的低パフォーマンスのプロセッサ状態が維持されることを可能にするための異なるアプローチを提案する。オペレーティングシステムのレベルにおいて問題に対処する代わりに、本発明は、タスクがPPMシステムからマスクされるようにタスクを適合させて、タスク自体のレベルにおいて問題に対処する。より具体的には、本発明は、本明細書に添付される特許請求の範囲において定義されるエネルギー消費量低減方法、コンピュータプログラムプロダクト、コンパイラ及びコンピューティング装置を提供する。本発明に係る技法は、CPUへの負荷に少なくとも部分的に基づいてプロセッサパフォーマンス状態を選択するPPMアルゴリズムを採用するシステム上で計算集約的であるが緊急ではないタスクが実行される場合に為されるべきエネルギー節約を可能にする。本発明は、タスクの実行に関連付けられる計算負荷のPPMアルゴリズムへの影響を低減する。特に、本発明は、選択されるタスクの実行に関連付けられるCPUへの計算負荷をPPMシステムが充分に考慮した場合よりも、比較的低いパフォーマンスのプロセッサ状態をPPMシステムが維持するであろう可能性をより高くする。選択されるタスクの実行に関連付けられるCPU負荷は、PPMシステムから充分に又は部分的にマスクされたと見なすことができる。このマスキングは、通常要したであろう割合のエネルギーのみを用いてタスクが実行されることを可能にすることができる。さらに、本発明のエネルギー節約技法は、プロセッサへの熱ストレスを低減し、雑音も同時に低減しつつ冷却ファンを動作させるために必要な時間を低減する利点を提供する。本発明のエネルギー節約技法は、採用される特定のプロセッサ、オペレーティングシステム、PPMシステム、又はデバイスアーキテクチャに依存せず、関連するオペレーティングシステム及び/又はPPMシステムがCPU負荷をヒューリスティックとして用いてプロセッサ電力状態を判定する限り、実質的に任意の最新のプロセッサ、オペレーティングシステム、及び/又はデバイスアーキテクチャと共に用いられることができる。本発明のエネルギー節約技法は、マルチコアプロセッサの場合でも採用されることができる。本発明のマスキング技法を採用しているタスクが第1のプロセッサコア上で実行されており、図らずして異なるプロセッサコア上に移行される場合、マスキングプロシージャにおいて短期間の悪影響perturbationがあり得るが、最悪の場合でも、これはすぐに減少するCPU負荷における一時的な増加となる。図4から図7を参照しつつ、現在好適である、本発明の第1の実施形態が説明されるであろう。CPU負荷を判定するためにPPMシステムによって用いられる詳細なヒューリスティックは、特にオペレーティングシステムのタイプ/バージョン間で異なる。例えば、オペレーシングシステムのMicrosoftWindows7TMは、プロセッサアクティビティの計算accountingを、現在のシステムアクティビティに基づいてどのパフォーマンス状態が適当かを判定する際により精密度が高い新しいやり方で扱う。本発明は、CPU使用率を評価するためにPPMシステムが用いている特定のヒューリスティクスに関わらず適応されることができ、プロセッサがCPUバウンドなタスク又は処理を実行しているとしても、PPMシステムがプロセッサについて比較的低いパフォーマンス状態を維持するように欺いて、CPU使用率に少なくとも一部は基づいてプロセッサパフォーマンス状態を選択するプロファイルに従ってPPMシステムが実行されている間にエネルギー節約は達成されることができるという概念に基づく。本発明は、概して、PPMシステムがCPU負荷を一定時間ごとに評価し、所与の時間間隔についてのCPU負荷について判定される値に基づいて、どのプロセッサパフォーマンス状態を選択すべきかを決定するという知見に基づく。本発明によれば、タスクの実行に関連付けられる平均的なプロセッサ使用率は、CPU負荷を判定する際にPPMシステムが適用する評価期間にわたって低減されるので、PPMアルゴリズムには、タスクは見えseeない又は、部分的にしか見えseesない。換言すれば、タスクの実行に関連付けられる計算負荷は、PPMシステムによって選択されるプロセッサパフォーマンス状態への低減された影響を有するようにされる。本発明の第1の好適な実施形態において、CPU負荷を評価するためにPPMシステムによって用いられる各評価期間にわたってタスクがそのCPU使用率を低減することができるように採用される技法は、定期的な短いインターバルをアクティブ期間の合間に設けて、タスクが非常に短い期間にわたって実行されるように構成することである。BOINCにおいて用いられるアプローチと同様に、本発明の第1の好適な実施形態において、タスクはマイクロスリープ即ち、ごくわずかなスリープであり、ここでのマイクロという用語の使用は、これらのごくわずかなスリープの持続時間をマイクロ秒に限定しないを有すると見なされ得る。本発明の第1の好適な実施形態の場合、アクティブ期間及びそれらの合間のインターバルの持続時間は、PPMシステムの評価期間にわたってタスクによって生じる平均的なCPU負荷が比較的低くなり、プロセッサについてより高いパフォーマンス状態の選択をトリガする可能性が低くなるように設定される。しかし、この低減された平均的なCPU負荷は依然としてゼロではない。即ち、計算上、依然として幾らかの進展が為されている。従って、BOINCにおけるスリープとは異なり、本発明の第1の好適な実施形態において用いられるマイクロスリープは、エネルギー消費量における低減を確実にもたらす。実際に、BOINCは、本発明において採用されるタイミング粒度timinggranularityを生成することはできない。BOINCソフトウェアパッケージが用いられてボランティアコンピューティングアプリケーションが展開される場合、当該アプリケーションは、シグナルハンドラを実装するBOINCライブラリにコンパイルされなければならない。ボランティアに充てられるプロセッサ上でのアプリケーションの実行中、BOINCマネージャは、別個のプロセスとして実行され、オペレーティングシステムによって提供されるプロセス間通信機能を用いてアプリケーションに一定時間ごとに信号を送信する。シグナルハンドラがBOINCマネージャから信号を受信する場合、どのくらいの時間が経過したかをチェックし、必要であればアプリケーションをスリープにする。アプリケーションをスリープにするための技法は、アクティブ期間、及び本発明に関与する短期間のマイクロスリープを生成することができない。図4から図7は、エネルギー節約を実現するための第1の好適な実施形態に係るアプローチの有効性を実証する。上述されたベンチマークアプリケーションは、下記の疑似コードに従って、テスト用のラップトップ構成上で実行される:この疑似コードは、ベンチマークアプリケーションにプロセッサにアクセスさせて期間Tの間に少量の作業を実行させ、インターバルSの間はスリープにする。T及びSの値を、本発明の第1の好適な実施形態の効果を実証するように変化させた。S=0の場合、これはベンチマークアプリケーションがプロセッサに連続的にアクセスすることを意味し、平均的なCPU使用率は100となり、プロセッサについてPPMシステムによって高パフォーマンスモードを選択することになる。これは、上述されたスクリーンセーバ又は従来のバックグラウンド実行と同じである。T及びSの双方が、PPMシステムの評価期間Paこれは、GNU/Linuxを用いる我々の例において、およそ10ミリ秒であると比較して大きい値に設定される場合、CPU使用率が100であるPPM評価期間アクティブ期間Tの間と、CPU使用率が0であるPPM評価期間スリープSの間とが存在する。従って、ある期間の間は高パフォーマンスモードが選択され、他の期間については低パフォーマンスモードが選択される。これは、省電力無しの、BOINCの使用制限機能を用いて得られる振る舞いと同じである。図4は、T及びSが評価期間Paよりも大きい及び小さい異なる値に設定された場合に観察された振る舞いを図示する。図4aは、T及びSの値と共にエネルギー使用量がどのように変化したかを図示し、図4bは、プロセッサが最低電力パフォーマンス状態において費やす時間の割合に対してT及びSの値を変化させることが有した効果を図示する。下記の表2は、図4a及び図4bにおいてグラフに描かれるデータ点の一覧である。図4aから分かるように、Tが本例における評価期間Paにおおよそ等しい約107CPUチック以上であった場合、ベンチマークアプリケーションを実行させるために要した余分なエネルギーは、バックグラウンドにおいてアプリケーションを中断無しに実行させるために要した969ジュールのエネルギーを超えた。同様に、図4bは、Tが107CPUチック≒Pa前後の値をとった場合、プロセッサは、最低電力を用いるパフォーマンス状態においてあまり時間を費やさなかったことを示す。しかしながら、T及びSがより小さな値に設定された場合、興味深い振る舞いが観察された。S及びTの小さな値の範囲内で、PPM評価期間の間、平均的なCPU負荷は100未満のままであり、従って、PPMシステムはベンチマークアプリケーションのためにCPUパフォーマンス状態を増加させなかったが、計算上の有益な進展は依然として達成された。図5は、Sが500マイクロ秒に設定され、Tが105から107CPUチックの範囲における異なる値に設定された場合に、本例において観察された結果を示す。Tは、Intelと互換性のあるプロセッサに提供されるCPUタイプスタンプカウンタを用いて測定された。このカウンタは、CPUのクロックチックごとにインクリメントされ、オペレーティングシステムの介入なしに単一命令を用いて読まれることができる。図5aは、実験の間に消費された総エネルギーがTの値と共にどのように変化したかを図示する;図5bは、ベンチマークアプリケーションの実行を完了させるために要した時間がTと共にどのように変化したかを図示する;図5cは、Tの様々な値について、CPUが低電力アイドルパフォーマンスモードにあった時間の割合を示す;また、図5dは、ベンチマークアプリケーションの実行に起因し得る余分なエネルギー消費がTと共にどのように変化したかを図示する。図5dは、ベンチマークアプリケーションの実行に起因し得る付加的な電力消費における明確な最小値を示す。この最小値は、Tが106CPUクロックチックに設定された場合に生じた:マシンは依然として低パフォーマンス低電力/アイドルモードにあったが、有益な作業が依然として為されていた。計算時間は、190秒、即ち、スクリーンセーバとして実行されようとバックグラウンドにおいて実行されようと中断無しのCPU使用率の場合における持続時間の3倍強に伸びた。しかし、マイクロスリープと共にベンチマークアプリケーションを実行させることに起因し得る余分なエネルギー消費量の総量は、ベンチマークアプリケーションがバックグラウンドにおいて中断無しに実行されたフルパワーの場合に要したエネルギーの50未満であった。さらに、CPU負荷100においてベンチマークアプリケーションがバックグラウンドにおいて中断無しに実行される上記の場合と比較して、100000CPUチックよりも大きい、グラフに描かれる全てのTの値について、マイクロスリープアプローチを用いたエネルギー節約が観察された。図5のグラフには図示されていないが、図4及び図5から、このタスクによって課される平均的なCPU負荷が各評価期間の間に100よりも小さくなることを確実にするためには、Tに上限があること、つまり、Tは評価期間Paの持続時間よりも小さく設定されるべきであること、即ち、T<Paに設定されるべきことが理解されるであろう。図6は、Tが106CPUチックに設定され、Sが25マイクロ秒単位で1~1000マイクロ秒に増加された場合に観察された結果を示す。図6aは、実験の間に消費された総エネルギーがSの値と共にどのように変化したかを図示する;図6bは、ベンチマークアプリケーションの実行を完了させるために要した時間がSと共にどのように変化したかを図示する;図6cは、様々な値のSについて、CPUが低電力アイドルパフォーマンスモードにあった時間の割合を示す:また、図6dは、ベンチマークアプリケーションの実行に起因し得る余分なエネルギー消費がSと共にどのように変化したかを図示する。図6は、非アクティブ期間Sの小さな値について、即ち、1~500マイクロ秒の範囲において、PPMシステムが混乱し、CPUを高パフォーマンス状態から低パフォーマンス状態へ切り替え、及び元の状態へ戻す傾向があることを示す。実際、Sがあまりに小さい場合、オペレーティングシステムは、要求されたスリープ機能をアクティブループに置換し、CPU負荷100のアセスメントにつながる。しかしながら、500マイクロ秒よりも長い非アクティブ期間Sについては、CPUは低パフォーマンス/低電力状態に維持され、ベンチマークアプリケーションの実行に起因し得るエネルギー消費は低く維持された状態で、振る舞いは安定する。図6dから、本実験において、ベンチマークアプリケーションが中断無しにバックグラウンドにおいて実行される場合と比較して、90マイクロ秒と100マイクロ秒との間の小さなSの値の範囲、及び約130マイクロ秒を超える、グラフに描かれる全てのSの値について、PPMシステムが上述したように混乱している低い値においてもエネルギー節約が実現されることが分かる。最も低いエネルギー消費は、500マイクロ秒と600マイクロ秒との間のSの値について、実現される。ただし、同様のエネルギー節約は、より大きな値のSにおいても実現される。理論上、Sに上限は存在しない。ただし、ごくわずかなスリープの持続時間が長くなればなるほど、対象タスクを完了するためにかかる時間は長くなるであろう。従って、この特定の実験において、エネルギー節約と計算の時間との間の最適なトレードオフは、スリープ時間Sを500~600マイクロ秒の範囲に設定することを含む。最適よりも低いエネルギー節約及び幾らかのファンノイズを許容することができる場合、Sの値を最適なエネルギー効率を与える値よりも低いが充分に大きく、評価期間Paにわたる平均的なCPU負荷が依然として100未満であるように設定することによって、例えば、本例においては、Sを90マイクロ秒と100マイクロ秒との間、又は130~500マイクロ秒の範囲に設定することによって、タスクのより速い実行を実現することができる。実際には、最適なエネルギー節約を提供するであろう、アクティブ期間T及び非アクティブ期間Sの値の特定の範囲は、考慮中の特定のタスク及びプラットフォームプロセッサ、オペレーティングシステム、PPMシステムに依存して、状況ごとに変化するであろう。上記の実験において、ベンチマークアプリケーションは、15.3ワットの電力消費について実行され得るが、これはマシンのアイドルの電力消費13ワットを2.3ワットだけ超過し、440ジュールのエネルギーが消費されることと同じである。ベンチマークアプリケーションが連続的に実行される場合よりも約3.3倍長く計算にかかるが、上記の実験は、本発明の第1の好適な実施形態に係るアプローチが、同じ計算集約なアプリケーションがバックグラウンドにおいて中断無しに実行される場合よりも2.2倍、及び、当該アプリケーションがスクリーンセーバとして実行される場合よりも3.8倍少ないエネルギーが用いられることを可能にすることを示す。本発明の第1の好適な実施形態に従ってタスクの断続的な実行、即ち、ごくわずかなスリープのインターバルでインターリーブされるごくわずかな算出の期間を達成する多くの異なる手法が存在する。ユーザアプリケーション又はシステムレベルサービスデーモンの場合に、オリジナルコードに如何なる変更も必要としない1つの簡単な技法は、アプリケーション又はサービスがファンクションコールを呼び出す度に、経過したクロックサイクルが確認され、所望の時間Tが経過したことが分かった場合には、持続時間Sのごくわずかなスリープが導入されるように、特別なコンパイルオプションを用いてアプリケーション又はシステムレベルサービスを再コンパイルすることにある。これは、例えば、多くのコンパイラにおいて利用可能なプロファイリングオプションを利用することによって達成されることができ、また、下記の実験においては、ファンクションコールが呼び出される度にごくわずかなスリープが導入されるように、GNUオペレーティングシステムのツールにおいて利用可能なmcountプロファイリング機能の適合されたバージョンが用いられた。第2の技法は、Tの現在の値をテストし、Tが所望の値に達したときに、プログラムを選択された期間Sについてスリープにする特殊関数を、一定の間隔で命令リストに挿入することによって、CPUによって実行されるべきタスクを表す低レベル命令の線形リストを変更することを伴う。第3の技法は、ネイティブCPUをエミュレートするバーチャルマシン上で予めアプリケーションシステムレベルサービス、デーモン等を実行することにある。バーチャルマシンは、コードをプロファイルしてCPUに負担をかけるプログラムの部分を発見し、CPU上でネイティブに即ち、バーチャルレイヤで実行され、アプリケーションを選択された間隔でスリープにする新たな命令ストリームを生成する。本発明の第1の好適な実施形態は、上述された3つの技法への言及によって限定されないことが理解されるべきである:他の適切な技法は、当業者であれば容易に想到するであろう。最新の気候モデリングアプリケーションは、上述された3つの技法のうちの第1の技法に従って再コンパイルされ、上記のテスト用のラップトップ構成を用いてバックグラウンドにおいて実行された。図7は、T計算のごくわずかな期間各々の持続時間がプロセッサクロックの106.2サイクルに固定された場合に、再コンパイルされたアプリケーションによって要求されるエネルギー消費が様々な値のSスリープの持続時間についてどのように変化したかを図示する。図7が示すように、最適な値のSこの場合は700マイクロ秒であったについて、気候モデルは、完了のために308ジュールを要し、82.3秒を費やした。対照的に、同じ気候モデルがテスト用のラップトップ構成上でスクリーンセーバとして実行された場合、これは25.8秒で完了したが、782.704ジュールのエネルギーを要した。従って、再コンパイルされたアプリケーションを実行するために要するエネルギー消費は、同じアプリケーションをテスト用ラップトップコンピュータ上でスクリーンセーバとして実行するために要するエネルギーよりも2.5倍少なくされ得る。上記の実験において、PPMシステムによって用いられる評価期間Paの持続時間の明示的知識なしに様々な値のT及びSが調査された。実際に、テスト用のラップトップ構成におけるように特にLinuxオペレーティングシステムが用いられる場合、評価期間Paの持続時間は、動的に変更させることができる。本発明に係る技法がタスクの設計に適用されることにより、タスクがタスク自身をPPMシステムからマスクできるようにする場合、T及びSについて適当な値を設定するために、多数の異なるアプローチが用いられることができる。1つのアプローチは、実験を前もって実行して、一般のCPU又はCPUファミリー及びオペレーティングシステムの種々の組み合わせを用いて実行される場合に、どのT及びSの値が対象タスクについて良好なエネルギー節約を提供するかを判定するソフトウェアプロバイダにある。関連する値は、例えばルックアップテーブル又はデータベースにおいてリストアップされることができ、タスクは書き込まれるか又は適合され、これにより、タスクを実行しようとしているCPU又はCPUファミリー及びオペレーティングシステムについてリストアップされている値に、タスクはアクセスする。このアクセスは、値リストをタスク自体にハードコードすることによって直接的に、又は、特定のロケーションこれは、CDROM、RAM、ROM、光ディスク等の記憶媒体、又は、例えばインターネット、LAN、若しくはWANを介してアクセスされるロケーションであり得るからS及びTの適当な値をフェッチするようにタスクを設計することによって間接的に提供されることができる。リストから読み出したS及びTの初期値を適合して、これらの値を最適化するようにタスクが設計されることは有利である。これは、例えば、CPU周波数といったヒューリスティクスを用いて、リストから読み出された初期のS及びTの値への適当な調整を判定するようにタスクを設計することによって達成されることができる。別の技法は、読み出された初期の値から始めてS及びTの最適な値を判定する小さなベンチマーク処理を実行することができるように、タスクを設計することにある。実際に、Sの値を、おおよそ500マイクロ秒Linuxオペレーティングシステムが用いられる場合又は1000マイクロ秒WindowsTMオペレーティングシステムが用いられる場合に設定し、Tの値を微調整することによって、多くの場合に良好な結果を達成することができることが分かった。本発明の第1の好適な実施形態の変更例において、例えば、タスクがより緊急になる場合に達成されることができるエネルギー節約を制限することを代償にしてタスクの完了を加速するために、プロセッサによるタスクの実行中に、タスクが動的な手法でS及びTの値を調整するようにタスクを設計することは有利であることが分かった。これは、計算の完了を実現する期限が存在するアプリケーションにおいて特に有益である。例えば、幾つかのボランティア計算アプリケーションにおいて、ボランティアに供給されるデータの各ブロックに関連付けられる期限が存在し、当該期限が終了する前に、処理されたデータがサーバに返されることが必要である。本発明の第1の実施形態の変更例がそのようなタイプのボランティア計算アプリケーションに適用される場合において、T及びSの現在の値は関連するデータのブロックに関連付けられた期限よりも遅くに所与の計算の完了をもたらすであろうとタスクが判定するとき、タスクはS及びTの値を調整して、当該タスクのより速い完了を実現することができる非常に緊急な場合に、中断無しに計算が継続するように、Sの値はゼロに設定されることができる。この機能性は、任意の好都合な手法で達成され得る。例えば:タスクの完了の期限がDとして表され、当該タスクをCPU負荷100で完了するために費やされる時間がT100と示され、低電力モードにおけるCPUを用いたタスクの実行を完了させるために要する時間がTlpと示され、所与の瞬間tにおいて完了されたタスクの割合がδただし、0≦δ≦1と示される場合、タスクは実行中の所定の時間に下記のテストを行うように構成され得る:所定の瞬間tにおいて、低電力モードにおいて完了するまでの時間をチェックする即ち、1-δ×Tlpの値を判定する;低電力モードにおいて計算を完了するために充分な時間が残されているか否かを判定するために、安全マージンΔTを持たせて、低電力モードにおける完了までの時間[即ち、1-δ×Tlp]を、期限前に利用可能な残りの時間と比較し、即ち、D-tと比較する;また、{1-δ×Tlp}ΔT<D-tの場合、CPU負荷を100まで上昇させ、エネルギー節約を終わらせそうであってもSをゼロに設定し、即ち、それ以後はタスクを連続的に実行する。タスクが実際に実行される場合に、一連のアクティブ期間の合間に介在するであろうインターバルSの持続時間がタスクによって設定される値に一致することを保証することはしばしば不可能である。これは、タスクが特定の持続時間のスリープを要求し得るが、システムは当該タスクを幾らか長い期間についてスリープにし得るためである。ただし、これは低パフォーマンスプロセッサ状態の維持を阻止しないであろう。エネルギーを節約するためにタスクがPPMシステムからマスクされることができる本発明の一般原理は、様々な手法において実装されることができ、そのうちの幾つかは特定のPPMシステム及びアルゴリズムに固有の特徴を利用する。例えば、国際公開第2007/103051号は、CPU負荷に基づくだけでなく、実行されているタスクのメモリバウンドな程度を定量化するパラメータも考慮して、プロセッサのパフォーマンス状態が選択されるPPMシステムを提案する。別の例において、米国特許出願公開第2009/0089598号明細書は、CPU負荷だけでなく、少なくとも部分的にはプロセッサがいつストールされるかのアセスメントに基づいて、プロセッサパフォーマンス状態が選択されるPPMシステムを提案する。これらのPPMシステムによれば、タスクがメモリバウンドであると考えられる場合、又は、タスクの実行中にプロセッサがストールされると考えられる場合、より低いパフォーマンス状態がCPUについて選択される。本発明の第2の実施形態は、タスクがこれらのタイプのPPMシステムからタスク自体をマスクすることを可能にする。これは、タスクのコードにダミー命令を挿入し、これらのPPMシステムのフィードバックメカニズムを欺くことによって達成される。任意の好都合なダミー命令がタスクのコードに挿入され、上記のタイプのPPMシステムのフィードバックメカニズムがタスクをメモリバウンドであると推論するように欺き得る。適切なダミー命令の1つの例は、ランダムなただし、有効なメモリロケーションからCPUレジスタにデータをロードするようにCPUに要求し、このデータロード作業について如何なる計算の必要も存在しない命令にある。要求されるデータをCPUがレジスタにロードしている間、CPUは実際にはタスクを進展させていないため、タスクが短期間休止していると考えることができる。メモリから読み出されるデータの量が大きいほど、このごくわずかなスリープの持続時間は長くなる。従って、ロードされるべきデータの量は、ごくわずかなスリープ期間Sの持続時間を制御する。本発明の第2の実施形態において、タスクの命令フローを変更することは、オペレーティングシステムからの如何なるサポートも要しない。従って、第1の実施形態と同様に、エネルギー節約は、オペレーティングシステムのレベルにおいて取られる動作というよりも、タスクのレベルにおける動作によって達成されることができる。本発明の第2の実施形態において、アクティブ期間T及びスリープインターバルSの持続時間を設定する場合に第1の実施形態の場合と同じ考察が適用されるので、簡潔にするため、これらの特徴はここでは繰り返さない。本発明の上記第1及び第2の実施形態においては、計算集約的なタスクがバックグラウンドにおいて実行されている場合でも、この特定のタスクがCPUに課す平均的なCPU負荷を低減することによってCPUの低電力/低パフォーマンス状態を維持することができると仮定される。しかしながら、バックグラウンドタスクによって課される低減されたCPU負荷は、同時に実行されている他のタスク例えば、ユーザが従事するフォアグラウンドタスクによって課されている任意のCPU負荷に付加される。このような他のタスクがCPU負荷100を課すexert場合、バックグラウンドタスクは如何なる余分なエネルギーの使用も生じさせていない。他方、このような他のタスクが当該タスクだけでは高パフォーマンスなCPU状態の使用をトリガするために充分なCPU負荷を課さないが、バックグラウンドタスクの重畳によりPPMシステムが高パフォーマンス状態を選択することをトリガする状況があり得る。この状況が当てはまるのは、バックグラウンドタスクが実行されている全期間を通じて極めてまれであり、従って、本発明の第1及び第2の実施形態は有益なエネルギー節約をもたらすであろうことが理解されるであろう。ただし、本発明の第3の実施形態は、この状況が回避されることを可能にする。本発明の第3の実施形態によれば、第1及び第2の実施形態に関連して上述された方法のうちのいずれかを用いて、短いアクティブ期間において、その合間にごくわずかなスリープインターバルを有した状態で実行するようにタスクは構成される。また、他のタスクによって課される負荷に加えて現在のタスクに起因する負荷によって課される全負荷が、PPMシステムの評価期間Paの間、100未満のままであるように、平均的なCPU負荷のアセスメントに基づいてS及びTの値を適応的に変更するように、タスクはさらに構成される。これは、平均的なCPU負荷と、所与のPステートにおいてプロセッサが費やす時間とに関する情報についてオペレーティングシステムに問い合わせるようにタスクを構成することによって達成されることができる。概して、本発明の第1、第2及び第3の実施形態に係る発明は、最初からプログラムコードの一部を形成し、又はタスクの旧バージョンのコンパイルの結果、コードの一部を形成する命令によって、タスクがタスク自体をPPMシステムからマスクするように、上記で議論された原理に従って設計されたタスクユーザアプリケーション、システムレベルサービス、デーモン等を表す表現をプログラムコードにおいて発見するであろう。典型的には、このプログラムコードは、好都合な物理的な媒体例えば、CDROM、RAM、ROM、光ディスク、テープ、又は他の記憶媒体に記録される特別に適合されたプログラムコードを含む、コンピュータプログラムプロダクトとして具現化されるであろう。プログラムコードは、ネットワーク例えば、LAN、WAN、インターネット等を介してブロードキャストされ又は送信されてもよい。しかしながら、本発明の第4の実施形態によれば、選択されるタスクは、タスク自体の外部にあるが、選択されるタスクが実行される場合にこれらのタスクにマイクロスリープを導入することによって、選択されるタスクをPPMシステムからマスクするように動作するディレクタアプリケーションによってPPMシステムからマスクされることができる。このディレクタアプリケーションは、オペレーティングシステムの一部を形成せず、例えば、記憶媒体からインストールされ、インターネットからダウンロードされる等のアドオンである。ディレクタアプリケーションは、明らかな不適合が生じる場合を除き、上述された第1から第3の実施形態の種々の特徴を実装することができることが理解されるべきである。本発明は、本発明の幾つかの目下好適な実施形態に関して上述された。添付の特許請求の範囲において定義されるような本発明の範囲内における好適な実施形態において変更例及び発展形が為され得ることを当業者は容易に理解するであろう。本発明は、ユーザアプリケーションをPPMシステムからマスクする実施形態に関連して上述された。しかしながら、同じ技法は、ユーザアプリケーション以外のプロセス、特に印刷、ファイル共有、データベースサービス等を含むシステムレベルサービス、Unixのデーモン、及び他のマルチタスキングオペレーティングシステムを、PPMシステムからマスクするために適用されることができる。本発明は、ボランティアコンピューティングアプリケーションのエネルギー効率を改善することに特に関連して上述された。しかしながら、本発明は、計算集約的であるが必ずしも緊急ではない他のタスク例えば、フラクタルのレンダリング、編集後のビデオデータの圧縮、ビデオ及びオーディオのコーディング及びデコーディング、並びにその他多数により広く適用可能である。本発明の種々の実施形態は、付加的な機能性を提供する補助モジュールに関連して用いられることができる。例えば、幾つかの場合に、本発明の第1から第4の実施形態の技法を用いてPPMシステムからマスクされるタスクとやりとりするために、ユーザインタフェースが提供され得る。このユーザインタフェースは、ユーザがマスキング処理の種々のパラメータ、特に下記の1つ以上を制御することを可能にする:アクティブ期間Tの持続時間及び/又はごくわずかなスリープインターバルSについて設定される値、S及びTについて適当な初期の値を取得するためにタスクがアクセスすべきソース、タスクの実行の完了のために費やされる時間、並びに、タスクの実行のために要する時間に比較したエネルギー節約の相対的重要度。ユーザインタフェースは、タスクが実行されるCPU及び/又はオペレーティングシステムの詳細例えば、CPU及びオペレーティングシステムを識別すること、CPUクロック周波数を特定すること等をタスク/マスキング処理にユーザが手動で通知することを可能にし得る。