JP2019191896A - 情報処理装置、情報処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】 情報処理装置における印刷に関する処理速度の向上と処理効率とを両立させることを目的とする。【解決手段】 印刷ジョブから中間データを生成する第一の動作モードと、前記第一のモードよりも省電力で印刷ジョブから中間データを生成する第二の動作モードとのいずれかの動作モードで中間データを生成する生成手段と、前記生成手段で生成された前記中間データを格納する格納手段と、前記格納手段に格納された前記中間データをプリンタエンジンで処理が可能なデータに展開する展開手段と、前記生成手段により前記第一の動作で前記中間データが生成される場合、冷却手段に冷却指示を出す指示手段と、を有することを特徴とする。【選択図】 図１３

Description

本発明は、印刷ジョブを処理する情報処理装置、情報処理方法およびコンピュータプログラムに関する。

特許文献１、特許文献２には、図形を描画するために図形が持つ座標情報等から図形の輪郭情報（エッジ情報とも呼ぶ）を抽出し、該輪郭情報に基づいて画像を形成するレンダリング手法は一般に広く利用されている。輪郭情報は直線で表現されるが該直線を表現するための手法も提案されている。また、これら印刷装置において消費電力を押さえるための技術はいくつか提案されている。例えば、特許文献３では、複数のＣＰＵを搭載するＰＤＬデータを処理可能なプリンタ装置において、求められる処理能力に応じて使用するＣＰＵを切り替える制御を行う手法等が提案されている。また、特定のノードへジョブを集中的に割り振った場合に特に最近の高速なＣＰＵに対して処理を集中させると、該ノード内、または、一部のデバイスの温度が設計上の閾値を超えてしまう。そこで、特許文献４、特許文献５、特許文献６、特許文献７には、パフォーマンスを一時的にダウンさせる等の工夫を行い、一定期間は発熱を抑え、機器の正常動作を保証する技術が開示されている。

特開平０４−１７０６８６号公報 特開平０８−７２３１７号公報 特開２００７−１０５９１７２号公報 特開２００６―２７７６３７号公報 特開２００６−１４６６０５号公報 特開２０１２―１６９４９４号公報 特開２０１２−２２７７４７号公報

従来から、図形毎に処理の単位（スレッド）を割り当てることを特徴とする画像形成処理方法が提案されている。図形のデータが入力された後、各図形のエッジ抽出の処理、及び各抽出処理後のデータをマージする処理（データ合成）それぞれについて複数のスレッドを割り当てることが可能である。スレッドの処理はそれを実行するユニット（ＣＰＵコア）にマップされ各コアが時間独立に処理を実行することで並列動作を可能とする。しかしながら並列に動作するＣＰＵ等は消費電力も大きく、また連続で並列動作した場合にはＣＰＵデバイス等から発生する熱等が問題になるケースが出てきている。

情報処理装置の冷却装置に関して開示されている技術を俯瞰すると、特許文献４に代表されるように、熱の発生状況に応じて冷却機構の工夫、または処理するノードの切り替え等が行われている。しかしながら、このような提案ではＣＰＵ処理装置の制御範囲が大まかに区切られているだけであり、例えば、ノード単位やＣＰＵユニットという単位であるために、ジョブの状況の変化に応じた制御が困難であった。そのため、装置の発熱量や消費電力等を効果的に削減することが難しかった。また、特許文献５に開示されている手法に関しては科学計算等の大規模なジョブを扱うケースでは意味があるかもしれないが、昨今のクラウドデータセンターのように実質的にＣＰＵのロードタスクが広く分散するような利用の形態等は想定がなされていない。

ＰＤＬデータの印刷処理（画像形成処理）が主たる対象となるようなケースでは、昨今の技術開発により並列処理を瞬時に実施するケースはよりクリティカルな性能が求められる。しかしながら、先の先行技術文献に提案されている手法等では、十分に効率的でかつ高パフォーマンスを実現する手法は実現出来ないという課題があった。

上記の課題に鑑みて、本発明は、情報処理装置における印刷に関する処理速度の向上と処理効率とを両立させることを目的とする。

本発明は、印刷ジョブから中間データを生成する第一の動作モードと、前記第一のモードよりも省電力で印刷ジョブから中間データを生成する第二の動作モードとのいずれかの動作モードで中間データを生成する生成手段と、前記生成手段で生成された前記中間データを格納する格納手段と、前記格納手段に格納された前記中間データをプリンタエンジンで処理が可能なデータに展開する展開手段と、前記生成手段により前記第一の動作で前記中間データが生成される場合、冷却手段に冷却指示を出す指示手段と、を有することを特徴とする。

本発明によれば、情報処理装置における印刷に関する処理速度の向上と処理効率とを両立させることが出来る。

実施形態１の基本システム構成図 本発明の図形ごとに処理スレッドを割り当てる様子を示した図。 本発明の各図形においてエッジ抽出処理を各々独立に適用した場合の図 図形に対してエッジ抽出処理を行う様子を示した図 システム上のＣＰＵコア数をＯＳ上で認識することを示す図 処理時間短縮の様子を示した図 実施形態１における複数コア適用時の処理時間短縮の様子を示した図 実施形態１におけるＲＩＰシステムの図 実施形態１におけるスプール数の変化を示した図 実施形態１における冷却機構を示した図 実施形態２における基本システム構成例の説明図 冷却装置における能力及び電力の時間変動状況を示した図 実施形態２におけるスプール数の変化を示した図

（実施形態１）
図１は、情報処理装置として機能する画像処理装置１００のハードウェア構成の一例を示す図である。図１において、ＣＰＵ１０１は、ＲＯＭ１０３又はハードディスク１１１からＲＡＭ１０２にロードされたＯＳや一般アプリケーション等のプログラムを実行し、後述するソフトウェアの機能及びフローチャートの処理を実現する。

ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）１０５は、キーボード１０９や不図示のポインティングデバイスからのキー入力を制御する。ディスプレイコントローラ１０６は、ディスプレイ１１０の表示を制御する。ディスクコントローラ（ＤＫＣ）１０７は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル等を記憶するハードディスク（ＨＤ）１１１やフレキシブルディスク（ＦＤ）等の外部メモリとのアクセスを制御する。

ＰＲＴＣ１０８は、接続された、媒体上に画像を形成して出力するプリンタエンジン部１１２との間の信号の交換を制御する。ＮＣ１１３は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、本実施形態では、以下に示す画像処理装置１００の機能は、ソフトウェアにより実現されるものと説明するが、各機能を専用のハードウェアで画像処理装置１００に実装するようにしても良い。なお、本実施形態のＣＰＵ１０１は、マルチコアのＣＰＵであるものとする。

図２は、各オブジェクトに対してエッジ抽出処理を各々独立に適用した場合の図である。ページ２０１上のオブジェクトごとにエッジ抽出処理を実施する様子を示している。オブジェクトごとにエッジ抽出処理のスレッド２１１〜スレッド２１３で抽出されたエッジ情報は再度ページ上の座標にマップされ合成処理がなされる。それぞれの処理は各々依存性がないために独立に実行することが出来る。つまり、オブジェクトのデータが入力された後、各オブジェクトのエッジ抽出の処理、及び各抽出処理後のデータをマージする処理（データ合成）それぞれについてスレッドを割り当てることが可能である。

スレッドの処理はそれを実行するユニット（ＣＰＵコア）にマップされ各コアが時間独立に処理を実行することで、並列で動作することが出来る。なおマージ処理はエッジ抽出が完了したオブジェクトに対して適用される。たとえば１のスレッド（すなわちコア）をマージ処理に割り当て、他をエッジ抽出に割り当てる。コアの数には制限があるため、ひとつのオブジェクトのエッジ抽出処理を完了したなら、当該コアは次のオブジェクトを対象としてエッジ抽出処理を行う。エッジ抽出を終えたオブジェクトはマージ処理の対象となる。抽出されたエッジは、マージによりページ内に再配置される。スレッドをコアに割り当てる処理は、例えばマージ処理を行うコアが行ってもよい。

マージされたエッジ抽出済みデータからは、ラスタライズ処理により、ラスタラインごとにエッジ間に画素が充填されたビットマップデータが生成される。

図３は本実施形態の基本構成を示したレンダリングシステム（ＲＩＰシステム）の図である。レンダリングシステムは中間データ生成処理部３０１とスプール３０２、画像形成処理部３０３とを含む。図にあるようにＰＤＬデータは描画インターフェースを経由して、ＰＤＬインタープリタ３００からＲＩＰシステム（すなわちレンダラ）３０１に受け渡される。ＲＩＰシステム３０１では「データ受け取り」の処理ブロック３１１が図形、文字、画像等のＰＤＬオブジェクトを受け取り、不図示の内部スプーラに適時データを蓄えた後に後段の処理ユニットにデータを流すよう構成されている。

ＰＤＬオブジェクトが図形等であった場合は、該図形オブジェクトのデータはエッジ抽出処理（スレッド）２１１〜２１３に受け渡される。一方、ＰＤＬオブジェクトがイメージであった場合は画像処理（スレッド）３１２にデータを受け渡す。

なお前述したベクタライズ処理も必要に応じて行われるが、ここではその説明を省略する。

これらのスレッドはこのスレッドに割り当てられたひとつのプロセッサコアにより実行される。オブジェクトが１ページに複数存在する場合は、それぞれのオブジェクトに対して独立したスレッドでエッジ抽出処理が割り当てられる。ただし、並列処理されるオブジェクトの数はプロセッサコアの数が上限となる。各オブジェクトのエッジ抽出処理を後段の独立したスレッド２１１〜２１３で実行させる。

各スレッドはそれぞれに割り当てた処理ユニット（プロセッサコア）により実行されるので、データ受け取り処理ブロック３１１は、各処理ユニットで実行されるエッジ抽出処理にスケジュールされたオブジェクトのデータを流すよう構成されている。なお一つのコアで時分割的に複数のスレッドを実行することも可能であるが、本例では少なくともエッジ抽出処理に関しては、各処理はそれぞれのコアで実行されるものとする。ただし、エッジ抽出処理とその他の処理、たとえばＰＤＬデータの分析等を一つのコアで時分割的に実行することはあり得る。

それぞれのエッジ抽出処理で抽出されたエッジデータは適宜後段のデータ合成処理（スレッド）３１３に渡される。そして、ページ上に合成（重ね合わせの処理）がなされると同時にタイル状のデータにフォーマットされた上でスプーラ３０２にＲＩＰ中間データとして書きだすよう構成されている。該タイル上にフォーマットされたＲＩＰ中間データは更に後段の画像形成処理３０３で処理され、タイル処理（スレッド）３３１〜３３３により各タイルにおいてピクセルの展開処理が行われる。それぞれのタイルの処理は時間独立で実行がなされる。タイルはつなぎ合わされて例えばバンドとなり、ラスタ信号としてエンジン部１１２に提供される。

図４は、図３（基本システム概説図）の処理の中で、「エッジ抽出処理」と抽出されたエッジのデータをマージする処理「データ合成」におけるデータの流れを説明した概説図である。図４にあるように図形１、２のデータは実体としては図形の種類を表す図形種情報とそれを構成する座標データの群で構成されている。これらデータは「エッジ抽出処理」、すなわち、先に説明した図５の処理フローによりエッジデータが抽出される。図形１と図形２にはそれぞれ独立した別々のスレッドで処理がなされるために同時に２つの図形のエッジデータが抽出される。

これらの処理の過程において不図示である色情報抽出処理により図形の輪郭の中の塗り情報が同時に抽出されるよう構成されている。スレッド３ではスレッド１およびスレッド２により抽出されたエッジデータおよび色情報から「データ合成」処理を行う。

例えば、図形２が赤の単色（不透明）で塗られており図形１が青の単色（不透明）で塗られていて、図形１が図形２の上に描画されている場合、重なりの部分は上層の色である青が塗られることになる。この状態では色情報は２つ（すなわち、青と赤）が保存される。

一方でスレッド３が処理の対象とする領域においては図形１と図形２の該領域におけるエッジデータの合成（例えば重なった結果で不要になったエッジは消去される）が行われる。本提案の処理方式では、重なりの状況によって、該領域に関して保持すべき色情報の数が増えることもある。例えば図形１が赤の単色（不透明）で塗られており、図形２が青の単色（透過）で塗られている場合で、かつ図形２が図形１の上に重なっている場合は透過合成の計算により該重なっている領域の色が計算される。例えば、青と赤を合成すると紫となるため、スレッド３の処理においては赤、青、紫の色情報が保持される。

図５は、上述したようにシステム情報を得るためにＯＳ側がハードウェア情報を、その内部に格納している状況を説明した概説図である。図中ブロックＰ１１０１はシステムのＯＳが表示するシステムインフォメーション情報であり、現在のＣＰＵの負荷状況や、利用されているメモリ量等を表示するものである。ＯＳは起動時にハードウェア情報（該ハードウェア情報は設定されているＢＩＯＳの情報を反映したものとなっている）を取得しているので自身がどのようなＣＰＵ上で動作しているかを把握している。それらはＯＳの中のシステム情報として保存されている状態である。よってＯＳに対して、ＣＰＵの「コア数」を問い合わせれば、該システムで利用可能なコア数の情報が確実に得られるように構成されている。

図６は、１ページの処理に８コアを割り当てる場合の処理時間の違いを説明したグラフである。従来の考え方では、どの領域のどのデータに対して何コアを割り当てても、処理するユニット（コア）の数に変わりはないので、結果的には速度に差異は出ないという見解が一般的であった。しかしながら、本願発明人の検討によれば、図にあるようにページを上下に分割しそれぞれに４コアを割り当てた場合の方が、１ページ全体に８コアを割り当てるよりも高速に処理が完了するということを見出した。ＣＰＵはデータを処理する際に、主メモリのデータにアクセスするがそれらは直接読み込まれるのではなく、バスやキャッシュを経由してデータが流れるようになっている。

実際のＣＰＵの構成は先の図５のＣＰＵの構成図のように８コアという構成であっても、必要なデータのアクセス経路が等距離にない、という状況が発生する。このことに考慮してコア割り当てのパターンを最適化しないとマルチコアＣＰＵを用いたシステムにおけるプログラムの処理速度を最大化することは出来ない。図６にあるように、グラフィックス画像を多く含むヘビーページを、１ページ全体に対して８コアのＣＰＵで処理した場合、１０５０ｍｓかかっている。しかし、下図にあるように２つの領域に分割してそれぞれに４コアを割り当てた場合は９００ｍｓで処理が完了しており、約１４．３％の高速化が達成出来る。

以上のように、８つのプロセッサコアを持つマルチコアＣＰＵを用いたレンダリングシステム（すなわち画像処理装置）によりレンダリング処理の負荷が高いヘビーページをレンダリングする場合には、ページを二つの領域に分割する。そして、それぞれの領域について、４つずつのコアでエッジ抽出をはじめとする処理を実行する。これによりコアの稼働率を向上させ、より短時間でレンダリング処理を完了することができる。

なお、本実施形態では、ヘビーページか否かに応じてエッジ抽出処理に割り当てるコアの数を変えているが、無条件に、ヘビーページに対するのと同様に、複数のプロセッサコアをエッジ抽出処理に割り当ててもよい。すなわち、図８のヘビーページ検出部８０２および１コア処理用モジュールを持たず、コアの数に応じて、スレッドにコアを割り当てる。

また、コアの数が８を超える場合にも、同様にしてページを２つの領域に分割し、コアを２つのグループに分けて、それぞれの領域に含まれたオブジェクトのエッジ抽出処理をはじめとするレンダリング処理をおこなってよい。さらに、たとえば１つの領域を処理するコアの数を所定数、例えば４とするようにコアをグループ分けし、そのグループに対応付けてページを分割し、分割した各領域を１つのコアグループでレンダリング処理してもよい。

図７は、実施形態１におけるシステム構成に関する概説図である。ここではシステム情報を得るためにＯＳ側がハードウェア情報を、その内部に格納しているものを利用する。このシステムは、４コアのプロセッサを４つ搭載したマルチＣＰＵ構成を有している。したがって、コアの数は合計で１６となる。しかしながら、図７で示されるように、実際の物理コアの数と、オペレーティングシステムが認識する論理コアの数とが異なっているシステムが存在する。

システム側はＣＰＵコア数を３２と認識しているが実際のボードには４コアのＣＰＵが４つ搭載されているだけなので、実際の物理コアは１６となっている。これは、１つのコアの計算資源は１つのコアの分だけしか用意されていないが、デコーダ等を複数用意し、レジスタやパイプラインの空き時間を利用してあたかも２つのコア（これが論理コアである）があるかのようにふるまう技術による。演算回路は１コアに１セットしか容易されていないため、２つの論理コアにより２つのスレッドを完全に並列実行できるわけではない。

この状況で、３２コアというオペレーティングシステムにより提供された情報を参照して、実施形態１と同様の手法でコアの割り当ての最適化を行っても処理速度が向上しないという自体が発生する。そこで本実施形態ではＯＳ側から提供されるシステム情報をそのまま利用するのではなくて、不図示のＵＩによりユーザーがＣＰＵの構成情報を与えるよう構成している。

本システムでは１６コアの物理コアが利用出来る状態であるので、ページを並列処理で高速化する場合には、１ページを１６コアで処理する、１ページを２分割して各領域を８コアで処理する等の割り当てが可能である。但し、同時に利用するコア数が多い為に発熱量は高くなることが想定される。これに対して、ページ処理を高速化するための並列コアの割り当ては全てのコア（１６コア）を割り当てるのではなく、その一部を割り当てることも可能である。例えば、１ページを２分割して各領域に２コアで処理（発熱量は比較的低い）するという選択も考えられる。

図８は、実施形態１におけるプリントシステムの概略ブロック図である。ユーザーはＵＩ等により、３２の論理コアを提供しているシステムにおいて１６の物理コアを指定し、かつヘビーページの場合に２つのモードを用意し、それぞれの設定を行うよう構成されている。ヘビーページの場合の第一のモードは、１ページを２分割し、それぞれの領域に８コアを割り振る。また第二のモードは１ページを２分割し、それぞれの領域に２コアを割り振るように設定を行っている。第一のモードは処理時間を優先させたい場合に利用する設定であり、ＣＰＵから発生する熱は増えるが高速に処理が出来るモードである。これに対し、第二のモードは第一のモードより高速ではないが発熱量も抑えられる動作モードである。

図８にあるようにプリントシステムに印刷ジョブが入力されると、まずページが検査ブロックで検査される。ここでページがヘビーページであるか否かを判定される。ページがヘビーページでない場合（便宜上シンプルページとも呼ぶ）は、中間データ生成処理部は動作モードＡで動作し、ページがヘビーページの場合は、更にスプーラの監視情報を参照し、スプール状況に余裕があるか否かを判断する。

ここでスプール状況（後述の図９で説明）に余裕がない場合は、中間データ生成処理部は動作モードＢ１（図７で説明の第一のモード）を選択する。一方で、スプール状況に余裕がある場合は、中間データ生成処理部は動作モードＢ２（同第二のモード）を選択するよう構成されている。コアの割り当ては、モードＡにおける処理は１ページ全体を１コアで処理するように構成されている。

一方、モードＢ１の処理ではページを２つの領域に分割し、それぞれに８つのコアを割り振り、モードＢ２の処理ではページを２つの領域に分割し、それぞれに２つのコアを割り振るよう構成している。

図９は、先の図８中のスプーラにおけるスプール数の変化を示す図であり、横軸は時間軸、縦軸はスプール数を示している。

時刻ｔ１では、スプール数は５０ページであり、スプール可能な最大数（スプール最大数）１５０ページに対してまだスプール可能な状態である。時刻ｔ１において、中間データ生成処理部は次のモードで動作する。このｔ１の時刻でシンプルページを処理する場合は、モードＡで処理を行う。しかし、ヘビーページを検出した場合はモードＡだと時間がかかり過ぎてしまう。時刻ｔ１の段階ではスプール数が５０ページでありスプール数は少ない。ヘビーページが大量に入力されると中間データ生成処理部から生成される単位時間あたりのページ数が減少し、その結果、スプールが空になってしまう可能性がある。そこで高速なモードで処理を行うように切り替えを行う。ここではモードＢ１でスプールデータの生成処理を行う。

モードＢ１では８コア＋８コアの合計１６のコアを短時間の中で同時実行するため、ＣＰＵ装置はかなりの熱を発生させてしまう。そこで時刻ｔ１からｔ２に移行する途中のタイミングでＲＩＰ制御装置側からリモートで制御される空調機に対して不図示のネットワークを介して冷却強度を上げるように冷却指示を出す。この冷却に関する機能については、後述の図１０で詳説する。

時刻ｔ３では、スプール数は１５０ページであり、スプール最大数１５０に達した状態である。これ以降、中間データ生成処理部は、動作モードを高速モードから発熱を抑えたモードＡ（いわゆる省エネモードと同義）に切り替えてスプールデータの生成処理を行う。スプール数が、予め定められた下限数（本実施例では１００ページを想定）を下回るまで、中間データ生成処理部は、モードＡでスプールデータの生成処理を行う。

時刻ｔ１からｔ２のタイミングで冷却要請（冷却強度を上げる指令）を実施しなかった場合、発熱によりＣＰＵ装置のクロック数を上げられない状況になる（または最悪の場合は逆にクロック数を下げて処理が行われる場合もある）。パフォーマンスアップが期待出来ない状況だと、時刻ｔ４では、スプール数は９０となり、中間データ生成処理部はスプールデータの生成処理をモードＡで続行することが出来なくなる。しかし、本実施形態１の例では、上述したようにＲＩＰ制御装置側から冷却要請を出しているために発熱量が抑えられ、その結果スプール数で１００ページを維持することが出来る（時刻ｔ５、ｔ６ともにモードＡで処理が続行される）。

図１０は、実施形態１で想定しているデータセンターの空調設備を含めた構成概念図である。パフォーマンスを求める処理系にはＨＰＣ系のサーバー群（ＨＰＣインスタンス）が用意されており、図１０中ではそれらはＨＰＣゾーンに区分されている。一方で処理パフォーマンスが問題にならない処理系では、いわゆるマイクロサーバーで構成されるスモールサーバー群（マイクロインスタンスとも呼ばれる）が用意されている。マイクロインスタンスは、クロック数は高くないが省電力で効率良く動作し、かつ高い集積度で実装されたサーバー群である。これらは図１０にあるようにＭＳゾーンに配置されている。本実施系では図８にあるようにＲＩＰ処理はＨＰＣゾーンで実行されるよう構成されており、空調に対する制御を司るファシリティマネージャーの処理はＭＳゾーン中のマイクロサーバーで実行されるように構成されている。ＲＩＰ処理はＨＰＣゾーン内に配置されているサーバーで処理されるよう構成さており、常時、動作モード状況をファシリティマネージャーに通知している。ファシリティマネージャーはＲＩＰがモードＢ１で動作を開始したタイミングでＨＰＣ専用空調機にリモート冷却要請を通知するよう構成されている。これら一連の動作によりＨＰＣゾーンのサーバーは適宜冷却され、ＲＩＰ処理が必要なタイミングで最大パフォーマンスが発揮出来るよう構成されている。

（実施形態２）
図１１は、実施形態２におけるプリントシステムの概略ブロック図である。ユーザーはＵＩ等により、６４の論理コアを提供しているシステムにおいて３２の物理コアを指定し、かつヘビーページの場合に２つのモードを用意し、それぞれの設定を行うよう構成されている。ヘビーページの場合の第一のモードは、１ページを４分割し、それぞれの領域に８コアを割り振る。また第二のモードは１ページを２分割し、それぞれの領域に２コアを割り振るように設定を行っている。第一のモードは処理時間を優先させたい場合に利用する設定であり、ＣＰＵから発生する熱は増えるが高速に処理が出来るモードである。これに対し、第二のモードは第一のモードより高速ではないが発熱量も抑えられる動作モードである。実施形態１との対比では印刷ジョブがＲＩＰに投入される前にジョブスプーラに一旦スプールされる点が異なる。該スプーラに投入されたジョブはページ単位でヘビーページであるか否かを、図の先読み検査ブロックにより検査される。この検査の情報は図中のファシリティマネージャーに適宜、通知されるよう構成されている。因みに、空調機（ヒートポンプ等で構成される）の能力の増減には、一般的に一定の時間が必要である。図１２で示されるように、空調能力は時刻ｔの経過に伴い最大の能力が発揮されるまでは最大の電力を使い、能力を最大化出来た後に空調機は一定運転がなされる。

本実施形態２の構成によれば空調機の冷房能力が最大化するタイミングを適性化することが可能となるため、高速な印刷処理が要求されるレスポンスに適切に応えることが出来るようになる。図１３は、先の図１１中のスプーラにおけるスプール数の変化を示す図であり、横軸は時間軸、縦軸はスプール数を示している。

時刻ｔ１では、スプール数は５０ページであり、スプール可能な最大数（スプール最大数）１５０ページに対してまだスプール可能な状態である。時刻ｔ１において、中間データ生成処理部は次のモードで動作する。このｔ１の時刻でシンプルページを処理する場合は、モードＡで処理を行う。しかし、ヘビーページを検出した場合はモードＡだと時間がかかり過ぎてしまう。時刻ｔ１の段階ではスプール数が５０ページでありスプール数は少ない。ヘビーページが大量に入力されると中間データ生成処理部から生成される単位時間あたりのページ数が減少し、その結果、スプールが空になってしまう可能性がある。そこで高速なモードで処理を行うように切り替えを行う。ここではモードＢ１でスプールデータの生成処理を行う。

但し、先読み処理ブロックにて、ｔ１以降の入力データにおいてヘビーページが連続で投入されることがないことがわかっている（予め設定した閾値で判定）場合は、高速モード（Ｂ２）に切り替えて処理を行うよう構成されている。

モードＢ１では８コアｘ４の合計３２のコアを短時間の中で同時実行するため、ＣＰＵ装置はかなりの熱を発生させてしまう。該当するページに関しては上述した先読み検査ブロックで検出されておりファシリティマネージャーへ事前に通知されている。よって、最適なタイミングでＲＩＰ制御装置側からリモートで制御される空調機に対して不図示のネットワークを介して冷却強度を上げるように指令を出す。

時刻ｔ３では、スプール数は１５０ページであり、スプール最大数１５０に達した状態である。これ以降、中間データ生成処理部は、動作モードを高速モードから発熱を抑えたモードＡ（いわゆる省エネモードと同義）に切り替えてスプールデータの生成処理を行う。スプール数が、予め定められた下限数（本実施例では１００ページを想定）を下回るまで、中間データ生成処理部は、モードＡでスプールデータの生成処理を行う。

適切なタイミングで冷却要請（冷却強度を上げる指令）を実施しなかった場合、発熱によりＣＰＵ装置のクロック数を上げられない状況になる（または最悪の場合は逆にクロック数を下げて処理が行われる場合もある）。パフォーマンスアップが期待出来ない状況だと、時刻ｔ４では、スプール数は想定以上に落ち込むことが考えられる。しかし、本実施形態２の例では、上述したようにＲＩＰ制御装置側から冷却要請を出しているために発熱量が抑えられ、その結果スプール数で１２０ページを維持することが出来る（時刻ｔ５、ｔ６ともにモードＡで処理が続行される）
（他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (10)

1. 印刷ジョブから中間データを生成する第一の動作モードと、前記第一のモードよりも省電力で印刷ジョブから中間データを生成する第二の動作モードとのいずれかの動作モードで中間データを生成する生成手段と、
   前記生成手段で生成された前記中間データを格納する格納手段と、
   前記格納手段に格納された前記中間データをプリンタエンジンで処理が可能なデータに展開する展開手段と、
   前記生成手段により前記第一の動作で前記中間データが生成される場合、冷却手段に冷却指示を出す指示手段と、を有することを特徴とする情報処理装置。
2. 前記生成手段は、前記印刷ジョブの数が第一の閾値を超えていない場合は、前記第一の動作モードで前記中間データを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記生成手段は、前記印刷ジョブの数が前記第一の閾値とは異なる第二の閾値を超えている場合は、前記第二の動作モードで前記中間データを生成することを特徴とする請求項２に記載の情報処理装置。
4. 前記第一の動作モードは、前記第二の動作モードよりも高速に前記中間データを生成する動作モードであることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記指示手段からの冷却指示は、前記情報処理装置とは異なる装置からの指示に基づき、出されることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記生成手段は、前記印刷ジョブの数が前記第一の閾値とは異なる第二の閾値を超えると判定される場合は、前記第二の動作モードで前記中間データを生成することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記第一の動作モードは、複数のＣＰＵを用いて前記中間データの生成を行う動作モードであることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記第二の動作モードは、前記第一の動作モードよりもＣＰＵのクロック数が少ない動作モードであることを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 生成手段が、印刷ジョブから中間データを生成する第一の動作モードと、前記第一のモードよりも省電力で印刷ジョブから中間データを生成する第二の動作モードとのいずれかの動作モードで中間データを生成する生成工程と、
   格納手段が、前記生成工程で生成された前記中間データを格納手段に格納する格納工程と、
   前記格納手段に格納された前記中間データをプリンタエンジンで処理が可能なデータに展開する展開工程と、
   前記生成工程により前記第一の動作で前記中間データが生成される場合、冷却手段に冷却指示を出す指示工程と、を有することを特徴とする情報処理方法。
10. コンピュータを、
    印刷ジョブから中間データを生成する第一の動作モードと、前記第一のモードよりも省電力で印刷ジョブから中間データを生成する第二の動作モードとのいずれかの動作モードで中間データを生成する生成手段と、
    前記生成手段で生成された前記中間データを格納する格納手段と、
    前記格納手段に格納された前記中間データをプリンタエンジンで処理が可能なデータに展開する展開手段と、
    前記生成手段により前記第一の動作で前記中間データが生成される場合、冷却手段に冷却指示を出す指示手段と、を有することを特徴とする情報処理装置として機能させるためのプログラム。

Images