JP6417727B2 - 情報集約システム、プログラム、および方法 - Google Patents

情報集約システム、プログラム、および方法 Download PDF

Info

Publication number
JP6417727B2
JP6417727B2 JP2014118467A JP2014118467A JP6417727B2 JP 6417727 B2 JP6417727 B2 JP 6417727B2 JP 2014118467 A JP2014118467 A JP 2014118467A JP 2014118467 A JP2014118467 A JP 2014118467A JP 6417727 B2 JP6417727 B2 JP 6417727B2
Authority
JP
Japan
Prior art keywords
identifier
node
individual
information
work area
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014118467A
Other languages
English (en)
Other versions
JP2015233178A (ja
Inventor
尚 神田
尚 神田
剛 橋本
剛 橋本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2014118467A priority Critical patent/JP6417727B2/ja
Priority to US14/719,360 priority patent/US9847913B2/en
Publication of JP2015233178A publication Critical patent/JP2015233178A/ja
Application granted granted Critical
Publication of JP6417727B2 publication Critical patent/JP6417727B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、分散システムにおいて複数ノードから情報を集約する情報集約システム、プログラム、および方法に関する。
大規模な分散システムで複数ノードを使用して実行される並列ジョブの制御や、システム全体でノードあるいはノードの構成部品などを「資源」として管理するためには、ジョブないしシステム全体の制御を行うノードに対して、管理対象の状態情報をリアルタイムに集約する必要がしばしば生ずる。
このような集約を行うための情報集約型の通信では、ネットワーク上の送受信に伴う通信量または伝送時間が問題になる。近年の計算機システムは各ノードを構成するコンピュータの処理速度に比べ、ノード間をつなぐネットワークの通信速度が格段に遅いため、ネットワーク上を伝送される管理対象の状態情報の通信量が、情報集約システム全体の負荷の大きさを決める主要因となる。
上述のような負荷を低減するために、従来、以下のようなネットワーク管理システムが知られている（例えば特許文献１）。端末装置は、装置内部の状態を管理情報として出力する。LAN（ローカルエリアネットワーク）内でこれらに接続された、インテリジェントエージェント（中間管理装置）は、これらのMIB(Management Information Base：管理情報ベース)を取得し、これらを集約し、集約MIBを作成する。バックボーンLANによってこれらに接続された、管理装置は、この集約MIBを管理することによって、端末装置を管理する。この従来技術は、ネットワーク管理装置に負荷がかからず、ネットワーク管理装置と各端末装置との間のトラフィックが低く、管理情報の解析が容易で、ベンダ各社固有の管理情報の違いを管理者が意識しなくても管理ができる、ネットワーク管理システムを実現する。
特開平９−２９８５４３号公報
前述した従来のネットワーク管理システムは、集約中間装置及び管理装置が端末情報を記号化して配下の装置分を集約して管理する階層ノードの情報集約に関する従来技術である。
しかし、階層構造を持たない分散システムにおける情報集約型通信では、送信側ノードから受信側ノードにメッセージを送信する過程で、ノード間をつなぐネットワーク上の通信量を効率良く削減することができないという問題点を有していた。
そこで、本発明の１つの側面では、分散システムにおける情報集約型通信において、情報集約時のノード間の通信量を低減することを目的とする。
態様の一例では、送信側ノードに設けられ、情報の通知元に固有の個別識別子と、情報の通知元からの個別識別子による通知を集約して集団識別子とを生成して送信する識別子集約機構と、受信側ノードに設けられ、集団識別子を受信し個別識別子を復元する処理と、個別識別子から情報の通知元を特定する処理を実行する識別子分析機構とを、情報集約システムは備える。
分散システムにおける情報集約型通信において、情報集約時のノード間の通信量を低減することが可能となる。
通常考える技術と実施形態の比較説明図である。 大規模システムでの割り込み集約処理の必要性の説明図である。 疎な（ほとんど全てのビットが0の）ビット列の例を示す図である。 情報集約システムを構成する計算機の実施形態のブロック図である。 第１の実施形態における送信側ノードにおける識別子集約機構４０１の処理の例を示すフローチャートである。 第１の実施形態における受信側ノードにおける識別子分析機構４０２の処理の例を示すフローチャートである。 第１の実施形態に従った情報集約システムの構成例を示す図である。 送信側ノードにより管理される管理対象の説明図である。 管理対象を識別子のコード化体系によって個別識別子にコード化し、その個別識別子と状態とからリダクションにより集団識別子を計算する動作の説明図である。 分解能が完全な場合におけるリダクションによる情報集積でのメモリ使用量削減の効果の説明図である。 集団識別子の分解能の概念の説明図である。 分解能が完全な場合と制限されている場合における、リダクションによる情報集積での通信量およびメモリ使用量削減の効果の説明図である。 管理対象番号と受信側ノードのメモリ領域内の集団識別子格納領域のbit位置との対応関係の説明図である。 管理対象番号とbit位置とを対応付ける計算機の構成例を示す図である。 演算が乗法の場合における受信側ノードが持つ個別識別子表の例を示す図である。 演算が加法の場合における受信側ノードが持つ識別子表の例を示す図である。 第２の実施形態における送信側ノードにおける識別子集約機構４０１による処理の例を示すフローチャートである。 第２の実施形態における受信側ノードにおける識別子分析機構４０２による集団識別子全体に渡る受信処理の例を示すフローチャートである。 第２の実施形態における受信側ノードにおける識別子分析機構４０２による集団識別子を構成する個々のビットフィールドの受信処理の例を示すフローチャートである。 第２の実施形態に従った情報集約システムの第１の構成例を示す図である。 第２の実施形態に従った情報集約システムの第２の構成例を示す図である。 第２の実施形態に従った情報集約システムの第３の構成例を示す図である。 管理対象（ノード）のグループ化の階層の説明図である。 管理対象のグループ化階層と各サブグループに対して「割当てられた識別子」の対応関係の説明図である。 図２４の具体例を示し、階層的なグループ分けで疎なビット列の０でないビットの検索範囲を限定する動作を説明する図である。 階層的なグループ分けで疎なビット列の０でないビットの検索範囲を限定する際の送信メッセージと受信領域の例を示す図である。 第４の実施形態における送信側ノードにおける識別子集約機構４０１による階層的にグループ化された集団識別子の送信処理の例を示すフローチャートである。 第４の実施形態における受信側ノードにおける識別子分析機構４０２による深さ優先探索を伴う受信処理の例を示すフローチャートである。 第４の実施形態における受信側ノードにおける識別子分析機構４０２による受信処理時の下層識別子領域の探索の処理の例を示すフローチャートである。 第５の実施形態における送信側ノードにおける識別子集約機構４０１の処理の例を示すフローチャートである。 第５の実施形態における受信側ノードにおける識別子分析機構４０２の処理の例を示すフローチャートである。 第５の実施形態を説明する図表である。 リダクションの演算が乗法である場合における、集団識別子からの素数冪の個別識別子成分の抽出処理を示すフローチャート（その１）である。 リダクションの演算が乗法である場合における、集団識別子からの素数冪の個別識別子成分の抽出処理を示すフローチャート（その２）である。 リダクションの演算が乗法である場合における、集団識別子からの素数冪の個別識別子成分の抽出処理を示すフローチャート（その３）である。 リダクションの演算が乗法である場合における、集団識別子からの素数冪の個別識別子成分の抽出処理を示すフローチャート（その４）である。 第６の実施形態における送信側ノードにおける識別子集約機構４０１の処理の例を示すフローチャートである。 第６の実施形態における受信側ノードにおける識別子分析機構４０２の処理の例を示すフローチャートである。 第７の実施形態の処理の例を示すフローチャート（その１）である。 第７の実施形態の処理の例を示すフローチャート（その２）である。 第７の実施形態の処理の例を示すフローチャート（その３）である。 第８の実施形態における送信側ノードにおける識別子集約機構４０１の処理の例を示すフローチャートである。 第８の実施形態における受信側ノードにおける識別子分析機構４０２の処理の例を示すフローチャートである。 対数の加法による乗算を利用する場合の例外値リストの作成処理の例を示すフローチャート（その１）である。 対数の加法による乗算を利用する場合の例外値リストの作成処理の例を示すフローチャート（その２）である。 対数の加法による乗算を利用する場合の例外値リストの作成処理の例を示すフローチャート（その３）である。 第９の実施形態における送信側ノードにおける識別子集約機構４０１の処理の例を示すフローチャートである。 第９の実施形態における受信側ノードにおける識別子分析機構４０２の処理の例を示すフローチャートである。 加法のリダクションで集団識別子の成分を求めた場合の受信側ノードで使用する個別識別子成分の対応リストの作成処理の例を示すフローチャート（その１）である。 加法のリダクションで集団識別子の成分を求めた場合の受信側ノードで使用する個別識別子成分の対応リストの作成処理の例を示すフローチャート（その２）である。 加法のリダクションで集団識別子の成分を求めた場合の受信側ノードで使用する個別識別子成分の対応リストの作成処理の例を示すフローチャート（その３）である。 第１０の実施形態において、bitwise or 演算で階層的にグループ化された識別子の送信処理の例を示すフローチャートである。 第１０の実施形態において、bitwise or 演算で階層的にグループ化された識別子の受信処理の例を示すフローチャートである。 第１０の実施形態において、乗法演算で階層的にグループ化された識別子の送信処理の例を示すフローチャートである。 第１０の実施形態において、乗法演算で階層的にグループ化された識別子の受信処理の例を示すフローチャートである。 第１１の実施形態における個別識別子リストの探索処理の一般的な処理の例を示すフローチャート（その１）である。 第１１の実施形態における個別識別子リストの探索処理の具体的な処理の例を示すフローチャート（その２）である。 第１１の実施形態における個別識別子リストの探索処理の例を示すフローチャート（その３）である。 第１１の実施形態における個別識別子リストの探索処理の例を示すフローチャート（その４）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その１）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その２）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その３）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その４）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その５）である。 第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャート（その６）である。 brute force method 以外のアルゴリズムにより、所与の整数の素因数を少なくとも１つ求める処理の例を示すフローチャートである。 第１３および第１４の実施形態の相違点の説明図である。
以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
まず、いくつかの実施形態について説明する前に、前提として本出願人が通常考え得る技術およびその技術における課題について説明する。
分散システムにおける情報集約の例として、例えば、次のような場合に、割当て時点に十分近い時点での各システム資源の状態が、割当て制御を行うノードに集約されている必要がある。例えば、ジョブへのノード割当て時点で、ジョブの予想実行時間やアクセスする予定のハードウェア資源に合わせた最適化を行う場合である。あるいは例えば、実行開始後に、チェックポイント間隔やマイグレーション先を決定する場合である。さらに例えば、各ノード自体の構成部品の状態、ファイルサーバの負荷分散、さらにはサーバにアクセスする通信経路の予想負荷などを考慮して、割り当てを行う場合である。
また、各ハードウェア資源の状態や負荷を継続的に監視し、随時適切に変更するためには、短い間隔での情報集約が望ましい。
状態情報の集約以外にも、並列計算機の環境において、複数ノードで並列に一部分を計算した結果を、ある時点で特定の１ノードに集約する場合や、複数ノード間で互いの計算結果を共有する必要が、しばしば生ずる。このような情報集約型の通信は、並列計算全体のボトルネック、ないしクリティカルパスになりやすい。
情報集約型の通信では、ネットワーク上の送受信に伴う通信量または伝送時間が問題になる。近年の計算機システムは各ノードを構成するコンピュータの処理速度に比べ、ノード間のネットワークの通信速度が格段に遅いため、ネットワーク上を伝送される管理対象の状態情報の通信量が、情報集約システム全体の負荷の大きさを決める主要因となる。従って，データ量に比例する部分だけではなく、データ量に関わらず送受信動作１回あたりに必要な時間の大きさが無視できない。
俣、情報集約型の通信では、ネットワーク上の送受信に伴う伝送時間だけでなく、情報を集約するノードでの処理負荷も問題になる。近年の計算機システムはCPU の演算処理の速度に比べ、メモリへのアクセス速度が数桁のオーダで遅いため、アクセスすべきメモリの量が、ノードでの負荷の大きさを決める主要因となる。
情報集約型の通信に固有の課題は、情報拡散型の通信の典型である「同報通信」と対比すると明確になる。
多数ノードに対しての同報通信の場合は、同報通信機構を持つハードウェアを利用する事で、送信側ノードの負荷が１ノードへの送信と同じオーダまで改善される。ただし、状態情報の通知や並列計算への適用では、動画配信等の同報通信と異なりデータのビット化けやパケット欠落への厳密な対策を含むリライアブルマルチキャスト（reliable multicast）の実現が必要になり、単純にハードウェアの同報通信機構を使うだけでは実現できない場合も多い。しかし、各システム環境で利用できる同報通信機能を利用したreliable multicast の実現方法が複数知られている。これらの技術により送信側ノードの負荷はノード数をパラメタとしてO(1)となり、通信の実所要時間に関する要件も、比較的満たしやすい。
ここでO() は「ランダウの記号」で、一般にある量が() 内で指定される量と同じオーダで増加あるいは減少する事（記号で言及された量と() 内で指定された量の比の極限が定数である事）を示す。O(1) とは、「比較の基準となる量（あるいはパラメタ）が変化しても、一定である事」を意味する。
複数ノードから特定１ノードへ情報を集約する通信は、例えばメッセージパッシングインタフェース（Message Passing Interface(MPI)）規格では、MPI_gather というAPI として規定されている。一方、最終的には参加した全てのノードが通信対象データを共有する場合のMPIでの通信API はMPI_Allgather と呼ばれている。以下の説明では、MPI で規定されたAPI を使用しない場合も通信パターンが共通である場合、gather あるいはallgather と呼ぶ。
gather の所要時間削減について、例えば、以下の動作（この動作を実現するための通信ハードウェア機能を含む）に基づく技術が知られている。
Write RDMA （Write Remote Direct Memory Access：ライトリモートDMA）という「送信側でのコマンドのみで通信を開始し、受信側メモリの所定領域を更新する」事を特徴とする通信機能を利用する技術。この技術により、受信側が通信コマンドを発行するオーバヘッドが削減される。
個々の通信毎の割り込み動作を抑制する技術。この技術においては、複数のノードからのデータを受信する際、個々のデータでは受信割り込みを起こさず、送信側全ノードのデータ送信完了を送信側全ノードと受信側ノードとのバリア同期などによる別の手段で知る。特に大規模システムで、仮に送信側ノード数に比例した割り込みが発生するとすれば、コンテキスト切り替えによるオーバヘッドが非常に大きくなる。従って、この技術による割り込み回数の削減は、性能改善に有効である。
gather に関する、上記従来技術の組み合わせによる受信側ノードのオーバヘッド削減には、以下の要因(1), (2) による限界が存在する。
(1) 個々のノードから受信する１回のデータ量は、少なくとも「最小パケット長」以上になる。
write RDMA に対し（より一般にread を含めたRDMA に対しても）、パケット長の最小値とは別に、メモリアクセス単位としてサポートされる最小データ長（以下L と書く（単位は通常はバイト））が存在する。
(2) 通信相手のノード数N に伴って受信すべきデータ量はO(N) で増加する。
前述したwrite RDMA により個々のノードから所定形式のデータを受信する場合、N*Lバイト以上の領域が必要になる。ただし、受信に要する時間は、各ノードからのデータが比較的小さい場合（すなわち、通信時間に対する通信遅延時間（latency）項の寄与が大きい場合）は、O(log(N)) となる。一方、データが比較的大きく、通信時間が「データの大きさ／バンド幅」で評価できる場合は、O(N) となる。一般に数十ノード以上からの受信の場合は、何段階かの中継ノードを設定する事で、「（中継段数）×（中継を含む受信側ノード毎の通信相手ノード数）」に比例する時間が必要になる。
各中継段で受信側ノード毎の通信相手ノード数a が一定とすると、中継段数はa を底とする対数に比例する。送信元ノード数をN として、通信所要時間は、ほぼ「a×log(N)/log(a)」となる。中継処理をノード上で行う場合、ここでのa は、2 ないし3 程度の比較的小さい値にする事が大規模システムでは有利な事が、理論モデル、シミュレーションや実測に基づく裏付けを伴った研究により、広く知られている。ここで、log(N)/log(a) は「a を底とするN の対数」を「標準の固定値」を底とする対数によって表す式である。対数の底となる「標準の固定値」は文脈により異なるが、どの場合でも、式の形は同じである。「標準の固定値」には、以下のような値が使われる。
- 「常用対数」の場合10
- 「自然対数」の場合e （Napier's constant ; ネイピアの定数）
- コンピュータ科学の多くの文献の場合2
以下、「a を底とするx の対数」を表記する際、log_a(x) という記法も用いる。例えば、log_a(x) = log_10(x)/log_10(a) = log_e(x)/log_e(a) = log_2(x)/log_2(a) となる。
中継に際して、一段前のノードからのWrite RDMA による転送が全て完了するのを待ってから受信したデータを含む領域全体を上位にRDMA 一回で転送すれば、中継に要するCPU の処理時間は、必ずしもノード数に依存しないようにする事ができる。しかしながら、通信にかかる実時間全体がノード数に伴って増加する事自体は避けられない。
ここで、後述するいくつかの実施形態が比較対象として想定する技術は、上述してきたgather による情報集積である。図１（ａ）は後述するいくつかの実施形態が比較対象として想定する本出願人が通常考える技術の方式を示す図である（図１（ｂ）については後述する）。想定される通常考える技術は、図１（ａ）に示されるように、１つ以上のノード１０２内の１つ以上の管理対象１０１から受信側ノード１０３に情報を集約する方式１０４が、gather による情報集積であるものである。gather による情報集積の方式１０４は例えば、情報を、管理対象１０１の識別子と、管理対象１０１についての各１ビットの情報（所定の状態なら：１、そうでないなら：０）で表す方式である。
後述するいくつかの実施形態が比較対象として想定する通常考える技術は、「管理対象に所定の状態が発生した事を感知したノードから割り込み処理を伴う通信を行い、そうでないノードは何も通知しない」という方法(X) ではない。この理由は、以下の通りである。
方法(X) は、管理対象で所定の状態が発生する割合が想定通り少数ノードであれば、受信側の負荷は十分小さくなるはずなので、一見、自然な監視方法に見えるかも知れない。しかし、方法（X) は大規模システムでの安定的な動作の観点から見て以下の(A)および(B)の問題がある。
(A) 「管理対象が所定の状態にないため、管理担当ノードからメッセージが送られない」場合と「ノードに深刻な異常が発生したためメッセージを送信できない状態にある」場合の区別がつかない。
後者の状態については別に監視が行われているとすれば、ノードの状態は、最終的には、適切に検知されるかも知れない。しかし、管理対象の状態に対し誤認が発生し記録されてしまう事の回避や、その誤認の影響からの回復は必ずしも容易ではない。
(B) 多くのノードで同時に所定の状態が発生した場合に、受信側ノードが過負荷になる恐れがある。図２（ａ）は、大規模システムでの割り込み集約処理の必要性の説明図である。図２（ａ）に示されるように、受信側ノード２０２内のNIC(Network Information Controller)２０３が、各送信側ノード２０１からのメッセージを受信する毎にIO割り込みを発生させた場合を考える。この場合、NIC２０３からのIO割り込みに基づいてCPU２０４が受信側のコンテクスト２０５を切り替えて、割り込みハンドラを起動し、プロセスを起動する。この場合の割り込み回数の最悪値は、送信側ノード２０１のノード数に比例してしまう。また、NIC２０３に接続されるネットワーク上のトラフィックも、送信側ノード２０１の数に応じて増加為てしまい、ネットワーク上の通信量が増加する。
割り込みを伴う通信は、図２（ａ）に示されるように、必ず割り込みに対応するためのコンテキスト切り替え処理のオーバヘッドを生ずる。このため、大規模システムで通常時より桁違いに多くのノードからの受信割り込みを処理しようとすれば、受信側ノード２０２における過負荷の発生は避けがたい。
k 個のメッセージを受信した時点で、受信側ハードウェアの機能として割り込みを停止する事が、受信側ノードの過負荷対策として考えられるが、この場合、割り込みを発生する状態に戻すタイミングを適切に決定する事は容易ではない。さらに、受信側ハードウェア仕様上の割り込み停止指定可能範囲が、ネットワーク・インターフェース毎ないしポート毎の場合、割り込みを停止する事は、同じネットワーク・インターフェースや上ポートを利用する通信を妨げる事になる。この場合、そのネットワーク装置による他の用途での通信での必要性の観点からは、割り込みを停止するとシステム運用上の支障を生じるため、割り込みの停止が不都合な場合も考えられる。
ここでの問題は「送信側ノードで、ある時点で特定状態のノードが全体でいくつあるか」は「送信前に決まっている情報」ではないので、通知情報の種類に対応するパケット属性に応じた（送信側の）指定で割り込みの発生の有無を決める」手法は使えない事である。
以上の考察により、受信時に割り込みを伴う通信を使用する場合、一斉に多数のノードからの通知を受ける場合を想定すると、次のような対策が必要となる。図２（ｂ）の２０６に示されるように、システム内の送信側ノード２０１（管理対象）の数に応じた階層化などすることにより、ネットワーク上のトラフィックを削減し、また各ノードでの負荷分散を行い、かつ、最大負荷を想定してシステム資源を用意する必要がある。
さらに、不定期の割り込み発生は並列計算時の「集団通信」性能を劣化させる事が知られている。つまり、このような監視情報を受信するノードは、並列計算を行うノードと別にするか、少なくとも、各ノードで上記割り込みを処理するシステム資源を並列計算用のシステム資源と分けて別に持たないと、システムの並列計算性能が著しく劣化する。
しかし、そのように、目的別に独立のシステム資源を通常時の処理には過剰な程度に余裕を見て用意しておく方法は、システムコストの大幅な増加につながる。
以上の考察により、管理対象の状態分布が想定通りである場合と、そうでない場合との間で、受信側ノードの負荷に大差がない監視方法が大規模システムでは極めて望ましい事が分かる。「所定の状態が発生した時のみ割り込みを伴う通信を行う」方法(X) は、この条件を満たさない。
後述するいくつかの実施形態が解決すべき課題を要約すると、次の３つの技術課題となる。
技術課題１:
情報集約型通信で、受信側ノードが各ノードからのメッセージ毎に最小メッセージサイズの領域を参照せざるを得ない事によるネットワーク上の通信量の増加および各ノードでのメモリアクセス負荷の削減限界を超える事。
技術課題２：
情報集約型通信で、受信側ノードがアクションを起こす必要がないノードからの情報にも全てアクセスせざるを得ない事によるネットワーク上の通信量の増加および各ノードでのメモリアクセス負荷の削減限界を超える事。
技術課題３：
情報集約型通信で、事前に設定した閾値を越えた数の管理対象が「監視中の状態」となった場合「閾値を越えた」事のみを認識すればよいという条件下で、全管理対象の状態を識別する必要がある場合よりも小さいネットワーク上の通信量および各ノードでのメモリアクセス負荷を実現する事。
これらの技術課題全てに共通する前提は「ある１つのノードが、多数のノードから、それと同数、ないし、より多数の管理対象についての情報を、各々について1ビットずつ受信する」という状況における通常考えられる情報集約技術の通信効率およびメモリ使用効率の低さが、システム全体の通信性能を制限している事である。
また、技術課題２と技術課題３に共通する前提は、上記の共通前提の下で「受信するビットの大多数が0 （1 であるビットが少数）」という状況における通常考えられる情報集約技術の通信効率およびメモリアクセス効率の低さが、システム全体の通信性能を制限している事である。図３は、疎な（ほとんど全てのビットが0の）ビット列の例を示す図である。これを見れば、大多数が0である情報列に対しても、各ビットごとに通信を行わねばならず、かつ各ノードにおいてメモリ領域を割り当てなければならず、通信効率およびメモリアクセス効率が悪いことが理解できる。
以下では、本出願人が通常考える技術との関連を含めて、上述の３つの課題についてさらに詳細に説明する。
大規模なシステムでの一斉受信時には、一般的な情報受信に共通の課題と、「例外的な状態」が発生した場合の情報受信に特有の課題がある。
まず、大規模システムでの多数ノードからの情報受信に共通の課題を説明する。
情報の中継が行われるには、管理ノード、あるいは各段の個々の中間ノードの通信相手ノード数と中継段数の間に次のトレードオフがあるため、通信遅延を大きく削減する事は難しい。
各段での通信相手ノード数を減らすと、中継段数が増加する。
各段での通信相手ノード数を増やすと、受信用のメモリ領域が増加する。
受信処理時に必要なメモリ領域が増加し、かつ、受信（あるいは中継）処理に伴うオーバヘッドが、各段の通信相手ノード数に比例して増加する。
ノードでの中継動作を伴う通信は、中継段数の増加に伴い通信遅延時間(latency) が、少なくとも「ノード数の対数」に比例して増加する。通信遅延時間の短縮は、各段の「中継動作」の所要時間削減で達成せざるを得ず、そのために、通信データ量と中継の各段での処理時間の各々を削減する必要がある。
多数ノードからの情報集積の処理性能を支配する要素としては、受信側ノードでの処理時間、特に、受信側ノードでのメモリアクセスの所要時間の占める割合も大きい。
メモリアクセスの所要時間はアクセスすべきメモリ量の増加関数となるため、アクセスすべきメモリ量の削減が性能改善の鍵となるが、以下の要因により削減の下限が規定されてしまう。この問題が前述した「技術課題１」である。
１ビットの受信時にも、少なくとも最小パケットサイズのメモリ領域は必要である。
受信時の割り込み処理によるCPUオーバヘッドを減らすため、割り込みを抑止したままで全ノードのパケットを受信しようとした場合、ノード数×最小パケットサイズのメモリがメッセージ保存用に必要になる。なぜならば、全メッセージを受信するまでメモリを解放できないためである。
次に、「管理対象に例外的な状態が発生した場合」の情報受信に特有の課題を説明する。
ここで、「例外的な状態」は、「異常な状態」と言い換えられる場合が多いが、「正常な状態で、単に稀であるだけ」の場合もある。「異常ではないが例外的」な状態としては、例えば大規模な疎行列の積を並列計算する際、「大部分の成分が0 である事」が分かっていれば、0 でない成分は「例外的」と考えられる。疎行列は、全ての成分に１つの領域を割り当てるのではなく、「「0 でない成分の位置」と「その位置の値」の対」として表現される場合が多く、入力データや（最終的な）出力データとしては、各成分を直接管理対象とする事は少ない。ただし、演算を並列処理する際に大多数のノードの分担部分が0 になる事はある。しかしながら、分かりやすさの観点から以下では「異常な状態」が発生する場合の状態監視の場合を例にして説明する。
一般に大規模な並列システムを構成する個々のハードウェア部品の故障率は非常に低いので、システム上で複数のノードあるいは複数の部品に共通する原因箇所がある場合を除き、複数のノードないし部品が同時に故障する確率は、１つが故障する確率に比べて何桁も小さい。なぜならば、各ノードあるいは部品の異常が「独立事象」とすれば、複数の管理対象が同時に異常な状態になる確率は、１つが異常な状態になる確率の積になるためである。
このため、全管理対象の状態を受信した後で個々の管理対象の状態を確認する場合は、大半の管理対象についての状態を「読み飛ばす」事になる。言い換えれば、ほとんど全ての管理対象に対しては受信側がアクションを起こす必要はないにも関わらず、多くの管理対象の状態を通信およびメモリを参照するための負荷自体は発生する。この問題が、前述した技術課題２である。
こうした場合、異常があったノード全てを識別する処理が不要な場合がある事に注意する。
例えば、１つの並列ジョブに割り当てたノード全ての異常を監視するシステムにおいて、異常があるノード数が事前に定めた閾値以下の場合と閾値を越えた場合では、次のような異なる対応を行うとする。
閾値以下の場合は、ただちに代替ノードの割当てジョブを継続する。
閾値を越えた場合は、いったんジョブを打ち切る。
このようなシステムでは、前者の場合は、異常が発生したノードを識別する必要があるが、後者の場合、「異常なノードの数が閾値を越えた」事が分かれば、当面の処理自体は可能と考えられるので、異常が発生したノードを識別する必要はない。
より一般に、信頼性確保のために用意された冗長資源の数を越えた異常が発生した場合は、冗長資源数の決定根拠が妥当だとすれば、同時に異常が発生した場合それらの異常が独立な事象である可能性は低い。従って、仮に冗長資源の数を多くしておいても、回復可能であるかは不確実である。想定していない「単一の故障原因箇所(single point of failre)」が存在する場合、冗長資源割当てによる処理継続は不可能なので処理を打ち切らざるを得ない。この状況では、個々の異常箇所の特定は、処理打ち切りの後で必要に応じて行なえばよいと考えられる。
ここで、通常考える技術である、複数ノードからのWrite RDMA により受信側ノードに情報を集める方法を使用する場合を考える。この場合、受信オーバヘッド削減のためデータが全て送信された後で受信を確認する限り、「閾値を越えた数のノードから所定の（通常は異常な）状態を受信した」事は、受信後の全データへの探索処理で定める事になる。
このようなケースにおいて、最悪の場合は、「ノード数×最小パケットサイズ」のメモリ全体へのアクセスとなる。平均的にも、少なくとも半分程度のメモリへのアクセスが必要になる。その理由は、異常な状態の個々のノードに対応する領域がアクセス順で先頭から数えて1/2 の地点の前にあるか後にあるかの確率が等しいとすると、１つの異常状態に対応するノードを検出するまでにアクセスするメモリ量の平均は全メモリ量の1/2 だからである。閾値をk として、その閾値k を越える数が発見されるまで探索を続けるとすれば、探索すべき平均メモリ量はk の増加関数になる。
以上により、通常考える技術では、例えばk = 1 で通常時には１つの管理対象の状態を見ればよい場合も、管理対象の総数に比例する通信量およびメモリアクセスが必要になり、かつ管理対象ごとに最小パケットサイズの通信量およびメモリ領域が必要になる。このための通信量の増加および処理負荷は少なくない。
しかし、所定の状態の分布状況が想定と異なる場合でも、想定より多くの管理対象が所定の状態にある事を検出した時点で処理を切り替える事は常に可能なので、処理時間に大きな差はない。すなわち、所定状態にある管理対象毎に割り込みを伴う通信を行う方法（前述した方法(X)）が想定外の状況で処理時間が増大してしまうのに対して、想定外の場合も安定した動作を実現しやすいという利点はある。
従って、「通常時には所定の状態にある管理対象が、閾値k 以下と想定される」状況下で、「想定外の状態での処理時間が通常時の場合の処理時間に較べて大差ない」事の利点を保ったまま、ネットワーク上の通信量および各ノードでの処理時にアクセスが必要なメモリ量を削減する事が課題となる。これが、後述するいくつかの実施形態が解決すべき、前述した技術課題３である。
以下の説明において、次のような監視方法は、「分解能がk である」と定義する。それは、特定の閾値k を越える数の管理対象に共通する特定の状態（通常は異常状態）に対しては個々の管理対象を必ずしも識別しないが、特定の状態の管理対象の数が閾値k 以下の場合は管理対象を識別する監視方法である。
なお、分解能がk の監視中にk より多くの管理対象について監視条件が成立した際の監視システムの挙動について、次の２つの考え方がある。どちらの考え方が適切であるかは状況に依存する。
(1) k 個より多くの対象も識別できる場合が多い方がよい。
例えば、計算された集団識別子が所定の大きさの領域に収まるため、全ての場合は無理だとしても、k 個より多くの個別識別子を分解できる場合が多いほど好ましい場合である。裏返せば、k 個より多くの管理対象が所定の状態にあって本来は個別識別子を知る必要がない場合に、集団識別子から個別識別子を求める計算を実行してしまう事が多くなる（この事が望ましくない場合もありうる）。
(2) k 個より多くの対象を識別する処理が不要ないし軽い場合が多い方がよい。
例えば、集団識別子の大きさだけからk 個より多くの個別識別子を含むと判定可能な場合（リダクション途中の演算のオーバーフローで判定可能な場合を含む）が多い方が好ましい場合である。裏返せば、k 個より多くの個別識別子が分かる場合は少ない（この事が望ましくない場合もありうる）。
例えば、ある管理対象の集合S を固定して、次のような処理を行うなら、分解能が上限kで制限されているコード化が使用できる。
Sのうちk 個より多くの管理対象で問題としている事象が発生した場合、S の使用自体をいったん取りやめる。
S の中で事象が発生したノードがk 個以下であれば個々のノードに対し何らかの措置を講じてS の使用を続行する。
あるノード全体の状態だけではなく、「あるノードの構成部品」や「あるノードが管理する一連の機器」等の状態の管理にも同じ方法が利用できるので、以下しばらく「管理対象」という一般的な表現を使用する。また、以下に説明する実施形態においては、「ノード」の管理という表現を使う場合もある。つまり、通知は、管理を担当するノードにより、各管理対象毎に行われる。
＜全ての実施形態に共通の技術的要素＞
図１（ｂ）は、後述するいくつかの実施形態において１つ以上のノード１０２内の１つ以上の管理対象１０１から受信側ノード１０３に情報を集約する方式１０５を説明する図である。図１（ｂ）に示されるように、管理対象１０１が所定の状態である場合には、コード化されたデータ（後述する個別識別子）が通知され、この通知に対してリダクションの演算が実行されてデータ量が削減されたデータ（後述する集団識別子）が受信側ノード１０３に通知される。また、管理対象１０１が所定の状態でない場合には、使用するリダクションの演算の単位元が通知され、この通知に対してリダクションの演算が実行される。すなわち、単位元が通知されることにより、この単位元を入力としたリダクションの演算結果は変化しない。
後述するいくつかの実施形態は、メモリを共有しない分散環境での情報集約手法に関するものであり、図１（ｂ）に示されるように、情報の管理対象１０１が情報通知元のノード１０２と一致している場合が、典型例である。すなわち、ノード１０２全体の（ある観点での）「状態」をノード１０２自身が通知する場合、管理対象１０１が、そのノード１０２自体と考える。しかし、ノード１０２を構成する特定種類の複数の部品に関する情報集約の場合に適用した場合など、より一般的な状況を考えて、管理対象１０１と通知元ノード１０２を概念上は区別する。
しかし、管理対象１０１がノード１０２自体で集団識別子の通知処理がノード１０２間で階層化されている場合と、ノード１０２上の複数の管理対象１０１についての情報の集約は、情報集約技術としては同等なので、分かりやすさを重視する場合、管理対象１０１が情報通知元ノード１０２自体と想定しても差し支えない場合が多い。
＜第１の実施形態＞
図４は、情報集約システムを構成する計算機の第１の実施形態のブロック図である。第１の実施形態は、以下に示す(1)から(6)の技術内容を有する。
(1) 分散システム内の複数の管理対象に対して定められた通知対象事象に対し、当該事象が発生した対象のコード化された識別子を情報として集約する事で、システム全体としての状態を管理する仕組みである。個々の管理対象に対応するコード化された識別子を、以下では「個別識別子」と呼ぶ。
(2) 「対象のコード化された識別子（個別識別子）を情報として集約する仕組み」を、以下では、「識別子集約機構４０１」と呼ぶ。個別識別子は識別子集約機構４０１への入力となる。
(3) 識別子集約機構４０１において、識別子の集約を、集団通信の一形態である「リダクション４０４」によって行う。このリダクション４０４は、ネットワーク上の通信量を削減すること、および、集約された情報を受信するノード（図１（ｂ）の１０３）上の、受信に必要なメモリ量および受信に必要なCPU 時間（メモリアクセス時間を含む）を削減することを目的とする。
本実施形態における識別子集約機構４０１は、管理対象を個別識別子にコード化する機能である「識別子のコード化体系４０３」と「リダクション４０４」との組み合わせを、計算機システム上で具体化したものと言える。
ここでリダクション４０４は分散並列システム上の集団通信(collective communication)の一種で、「複数ノード（図１（ｂ）の１０２）に分散配置されたデータを入力とし、演算結果を、それらのノードの１つあるいは全てに出力として返す操作を指す。すなわち、リダクション４０４は、ノード間の一連の通信と演算の組み合わせである。本実施形態では、リダクション４０４の「メカニズム」としての仕組みは、従来から知られている手法を利用する。リダクション４０４についての本実施形態での独自の追加部分は、どういうデータを、どのように「リダクション」の対象とするかという点に関するポリシーにある。
例えば、リダクション通信でのパケットフォーマットの詳細は、本実施形態では問わない。
「識別子のコード化体系４０３」により定まる個別識別子から、リダクション４０４により計算された結果を、以下では「集団識別子」と呼ぶ。リダクション４０４が集団通信(collective communication) の典型である事を意識し、英語で(collective identifier) と呼ぶ意図で、リダクション４０４の計算結果を「集団識別子」と呼ぶ。
集団識別子の計算に使用された個別識別子を、以下では（その集団識別子の）「生成因子」あるいは単に「因子」と呼ぶ。演算が乗法の場合は、普通の数学用語としての「因子(factor)」に一致する。ただし、本出願ではbitwise or （ビット単位の論理和演算）や加法などの、乗法以外の演算をリダクション４０４に使う場合に対しても、「生成因子」あるいは「因子」という用語を使用する。
(4) 上記の目的(3) を達成するための「識別子のコード化体系とコード化された識別子への演算方法」が、本実施形態の技術的要素である。その技術的要素には、次の２つの側面がある。
識別子（のコード体系）、および各コードに対するアルゴリズムの面での技術。
システムに固有の「ノード間演算装置」（リダクション４０４の実現に使用される特別なネットワーク、ないしネットワークに接続された特別な装置）の利用方法に関する技術。
(5) リダクション４０４により、個別識別子から識別子集約機構４０１により複数の管理対象に対応する集団識別子を計算する際、情報通知を担当するノード（図１（ｂ）の１０１に対応）は、「送信側ノード」と呼ぶ。また、情報の集約を担当するノード（図１（ｂ）の１０３に対応）は、「受信側ノード」と呼ぶ。
図５は、第１の実施形態における送信側ノードにおける識別子集約機構４０１（図４）の処理の例を示すフローチャートである。図５のフローチャートの処理は、後述する図７の送信起点ノード７０１のCPU７０１−１または中継ノードとして機能する受信・中継ノード７０２のCPU７０２−１によって実行される。また、入力パラメタ１また２等の作業領域は、送信起点ノード７０１のメモリ７０１−２または受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、自ノードが通信の起点ノードであるか否かが判定される（ステップＳ５０１）。
ステップＳ５０１の判定がＮＯ（図中「ｎ」）であるならば、受信済みの値を格納する入力パラメタ１に、受信済みの値（集団識別子）が格納される（ステップＳ５０２）。
ステップＳ５０１の判定がＹＥＳ（図中「ｙ」）ならば、受信済みの値は無いため、入力パラメタ１に、既定値が格納される（ステップＳ５０３）。ここで、既定値は、リダクション４０４に使用する演算の単位元が好ましい。例えば、演算が加法演算またはbitwise or演算であれば、既定値は０が好ましい。演算が乗法演算であれば、既定値は１が好ましい。自ノードが通信の起点ノードであって、受信済みの値がなければ、入力パラメタ１に単位元が格納されることにより、入力パラメタ１がリダクション４０４の演算に影響を与えないようにされる。
次に、自ノードが管理する管理対象において通知すべき条件が成立したか否かが判定される（ステップＳ５０４）。
ステップＳ５０４の判定がＹＥＳならば、自ノードの状態を格納する入力パラメタ２に、自ノードにおける管理対象（または自ノードそのもの）に対応する個別識別子が格納される（ステップＳ５０５）。
ステップＳ５０４の判定がＮＯならば、入力パラメタ２に、既定値が格納される（ステップＳ５０６）。ここでの既定値も、ステップＳ５０３の場合と同様に、リダクション４０４に使用する演算の単位元が好ましい。自ノードが管理する管理対象において通知すべき条件が成立していなければ、入力パラメタ２に単位元が格納されることにより、入力パラメタ２がリダクション４０４の演算に影響を与えないようにされる。
その後、リダクション４０４に使用する２項演算が、入力パラメタ１および入力パラメタ２に対して実行される（ステップＳ５０７）。２項演算の詳細については、後述するいくつかの実施形態において詳述する。
最後に、ステップＳ５０７での演算結果が、次の転送先への送信内容である集団識別子とされて出力される（ステップＳ５０８）。その後、図５のフローチャートで例示される送信側ノードにおける識別子集約機構４０１の処理が終了する。
第１の実施形態における識別子集約機構４０１の効果は、計算される集団識別子に必要な通信量およびメモリ量がそれぞれ、通知担当ノードから情報が集約されるノードに個別に情報を通知する際に必要な通信量およびメモリ量の合計のそれぞれより少ない事に由来する部分が大きい。
なお、どのノードも情報通知を担当し、かつ情報を集約する場合もある。すなわち送信側ノード、受信側ノードは、必ずしも物理的に特定のノードを指すとは限らず、単にシステム内の役割に対する呼び方である。
集団通信用語では、どのノードも情報通知と情報集約の両方を担当する場合は、単純に情報をそのまま集めるならAllgather、リダクション４０４を行うなら、Allreduce と呼ぶ。Allreduce の実現方法は大別して次の２つある。第１の実現方法は、特定ノードへの集約（reduce）と複数ノードへの放送(broadcast: 同じ内容のデータの一対多通信）を組み合わせる方法である。なお、同じ内容のデータの一対多通信は、文脈によっては一般的な場合をmulticastと呼び、broadcast という用語が「ネットワークの物理的な１セグメント内の全ノードへの一斉通信」という特殊な場合に対してのみ使われる場合もある。第２の実現方法は、集約の過程でノード間が情報を相互に交換する事により、通信処理終了後に集約に参加したノード間で情報が共有されるようにする方法である。例えば、情報集約過程が「各段階で２ノードずつ互いに持っている情報を交換する」事で実現されている場合である。これらの実現方法は、通信メカニズム上の区別であるため、本実施形態では、どちらが用いられていてもよい。
(6) 受信した集団識別子から監視中の状態にある管理対象を特定する仕組みを「識別子分析機構４０２」と呼ぶ。識別子分析機構４０２は、次の２つの部分からなる（図４参照）。第１の部分は、受信した集団識別子から（図４の識別子のコード化体系４０３に基いて）「生成因子」である個別識別子を特定し復元する処理である。第２の部分は、個別識別子から、その管理対象（図１（ｂ）の１０１）を特定する処理である。
図６は、第１の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の処理の例を示すフローチャートである。図６のフローチャートの処理は、受信側ノードとして機能する後述する図７の受信・中継ノード７０２のCPU７０２−１によって実行される。また、作業領域W等は、受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、ノード間のリダクション４０４における集団識別子が受信される（ステップＳ６０１）。
次に、集団識別子が作業領域Wに格納される（ステップＳ６０２）。
次に、作業領域Wが示す値がリダクション４０４の演算における単位元となったか否かが判定される（ステップＳ６０３）。
ステップＳ６０３の判定がＮＯならば、集団識別子から個別識別子が１つ特定される（ステップＳ６０４）。この特定の具体的な手法としては、図４の識別子のコード化体系４０３に依存して例えば以下の手段を用いる。
bit（ビット）操作演算
素因数分解
「集団識別子と（その生成因子である）個別識別子の対照表」の検索
対照表の検索が必要な範囲を限定する事で検索を高速化する「ハッシュ関数」
集団識別子から（その生成因子である）個別識別子を少なくとも１つ求める「完全ハッシュ関数」
これらの手段の詳細については、後述するいくつかの実施形態において詳述する。
その後、ステップＳ６０４で特定された個別識別子に対応する管理対象が処理（特定）される（ステップＳ６０５）。この特定の具体的な手法としては、図４の識別子のコード化体系４０３に依存して例えば以下の手段を用いる。
bit 操作演算
「個別識別子と管理番号の対照表」の検索
対照表の検索が必要な範囲を限定する事で検索を高速化する「ハッシュ関数」
個別識別子から管理対象番号を求める「完全ハッシュ関数」
次に、リダクション４０４に使用した演算の逆演算で、ステップＳ６０４において作業領域Wから特定された個別識別子が取り外される（ステップＳ６０６）。その後、ステップＳ６０３の処理に戻って、上述のステップＳ６０３からステップＳ６０６までの処理が繰り返し実行される。
ステップＳ６０３の判定がＹＥＳになると、図６のフローチャートで例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
本実施形態は、上述の(1)-(6) を骨子とする仕組みを、例えば図７の構成を備える情報集約システム上で実現する。本実施形態を実現する情報集約システムの最小限の要件は、「CPU、メモリおよびネットワーク・インターフェースを持つ個々の計算機（ノード）がネットワークにより相互結合された構成」である。すなわち、図７から図１０に示されるように、送信起点ノード７０１と受信・中継ノード７０２が、スイッチまたはルータである中継装置７０３と通信線７０４を含むネットワークにより相互接続されている。なお、図７は、第１の実施形態に従った計算機システムの例示であり、このシステムに含まれるノード７０１、７０２または中継装置７０３の数は、任意であってよい。そして、送信起点ノード７０１は、CPU７０１−１、メモリ７０１−２、およびネットワーク・インターフェースであるNIC７０１−３を備える。また、受信・中継ノード７０２は、CPU７０２−１、メモリ７０２−２、およびNIC７０２−３を備える。なお、受信・中継ノード７０２は、メモリ７０２−２の記憶領域の使用形態によって、タイプ１（集団識別子の受信領域）またはタイプ２（集団識別子の受信領域と識別子の表の記憶領域）に分類される。
図７において、送信起点ノード７０１は、図１のノード１０２に対応し、図１の管理対象１０１を含む。または、送信起点ノード７０１そのものが管理対象１０１であってもよい。
図８は、このようなノードにより管理される管理対象の説明図である。ノードにより管理される管理対象は、図８（ａ）に示されるように当該ノードの状態であってよく、図２（ｂ）に示されるように当該ノードの各構成部品の状態であってよい。また、ノードにより管理される管理対象は、図２（ｃ）に示されるように当該ノードの構成部品以外の管理対象物であってよく、図２（ｄ）に示されるように当該ノードのメモリ内の特定データであってよい。図２（ｂ）〜図２（ｄ）に示されるように、状態が管理される管理対象は、情報通信元のノードとは概念上区別され得る。しかしながら、情報通信元のノードにより管理される複数の管理対象の状態情報が後述のリダクション４０４（図４）の処理と同様の情報集約処理によって情報通信元のノードおいて集約されるならば、図２（ａ）に示されるように両者を概念上一致させた場合と同様に説明し得る。そこで、説明を明確にするために、ノードにより管理される管理対象を便宜的に図２（ａ）に示されるような当該ノードの状態であるものとして、以下では説明する。
送信起点ノード７０１において、CPU７０１−１は、それが内蔵する制御プログラムを実行することにより、メモリ７０１−２を作業領域として使用しながら、図５のフローチャートで例示される識別子集約機構４０１の処理を実行する。この結果、送信起点ノード７０１は、自ノードで発生した個別識別子（または前述した単位元）に対するリダクション４０４（図４）の演算結果を、集団識別子として次の受信・中継ノード７０２に転送する。ステップＳ５０６の説明で前述したように、自ノードが管理する管理対象において通知すべき条件が成立していなければ入力パラメタ２に単位元が格納されてリダクション４０４の演算が実行される。この結果、この場合にはリダクション４０４の演算の出力は入力から変化せず、集団識別子は変化しないで次の受信・中継ノード７０２に転送される。
図７において、受信・中継ノード７０２は、中継ノードとして動作するときは、送信起点ノード７０１ともなり得る。この場合、受信・中継ノード７０２は、送信起点ノード７０１または中継ノードとして機能する他の受信・中継ノード７０２から集団識別子を受信する。そして受信・中継ノード７０２において、CPU７０２−１は、それが内蔵するプログラムを実行することにより、メモリ７０２−２を作業領域として使用しながら、図５のフローチャートで例示される識別子集約機構４０１の処理を実行する。この結果、受信・中継ノード７０２は、受信した集団識別子と自ノードで発生した個別識別子に対するリダクション４０４（図４）の演算結果を、新たな集団識別子として次の受信・中継ノード７０２に転送する。
受信・中継ノード７０２は、受信ノードとして動作するときは、図１のノード１０３に対応し、他の送信起点ノード７０１または受信・中継ノード７０２から集団識別子を受信する。そして、受信・中継ノード７０２において、CPU７０２−１は、それが内蔵するプログラムを実行することにより、メモリ７０２−２を作業領域として使用しながら、図６のフローチャートで例示される識別子分析機構４０２の処理を実行する。この結果、受信・中継ノード７０２は、受信した集団識別子から、個別識別子およびそれに対応する管理対象を特定する。
第１の実施形態の最も基本的なポイントは、次の２点である。
本実施形態での管理対象の個別識別子とは、通し番号などではなく、特定の方法でコード化されたデータである事。
受信側に送信されるデータが個々の個別識別子自体ではなく、条件が成立している管理対象に対応する個別識別子を入力として、リダクションにより計算される集団識別子である事。
これらは、図５のフローチャートで例示される図４に示される識別子集約機構４０１の処理によって実現される。図９は、管理対象を図４の識別子のコード化体系４０３によって個別識別子にコード化し、その個別識別子と状態とから図４のリダクション４０４により集団識別子を計算する動作の説明図である。図９において、定数の前の0bは2進数表記である事を意味する。
図４の識別子のコード化体系４０３は、図９（ａ）に示されるように、個々の管理対象に対応する各個別識別子を、当該管理対象に対応する位置のbitがonにされたデータによってコード化する。すなわち、所定の条件を満たす管理対象に対しては、その管理対象に対応する個別識別子がリダクションの入力として与えられ、そうでない管理対象に対しては、全てのビットフィールドに0が入力された単位元が個別識別子として与えられる。
また、図４の「リダクション４０４」は、図９（ａ）に示されるように、コード化された個別識別子を入力としてbitwise orにより集団識別子を演算する。ただし、この計算に使用する演算機能は、「各ノードからの入力データが高々1 bitのみonであり、他はoffである」という条件を満足すればよい。したがって、乗法（図９（ｂ））、bitwise exclusive or（ビット単位の排他論理和演算）、整数の加法、または浮動小数点の加法（ただし、仮数部の桁数の範囲での整数加算として使用する）が、集団識別子の計算に使用されてもよい。また、入力データ全てに対してbit反転(bitwise not)を各ノードが施しておくことでbitwise andを使用して集団識別子が計算されてもよい。この場合、受信側ノードにおいて最終結果をbit反転するか、bit のon/off の意味を逆にしてデータを解釈すればよい。
このようにして、第１の実施形態では、「複数のノードからの情報を、１つのパケット／メッセージ内にたたみ込む」事により、前述した「技術課題１」が解決される。すなわち、集団識別子を用いて各ノードからの状態情報がリダクションされる。これによって、ネットワーク（図７の通信線７０４）上での通信量は、各送信側ノード（図７の送信起点ノード７０１等）からの状態情報を単に集約して受信する場合と比較して、大幅に削減され得る。同様に、情報を集約する受信側ノード（図７の受信・中継ノード７０２）において受信に必要なメモリ量および通信処理時間は、各送信側ノード（図７の送信起点ノード７０１等）からの状態情報を単に集約して受信する場合と比較して、大幅に削減され得る。図１０は、リダクションによる情報集積でのメモリ使用量削減の効果の説明図である。図１０（ａ）は、本出願人が通常考える、状態情報を受信側ノードが単に各送信側ノードから集約して受信する場合の説明図である。これに対して図１０（ｂ）は、集団識別子を用いてリダクションされた状態情報を受信側ノードが各送信側ノードから集約して受信する場合の説明図である。状態情報を受信側ノードが単に各ノードから集約して受信する場合（図１０（ａ））、各管理対象の状態情報を受信するために受信側ノードに必要とされるメモリ量は、最小書き込みサイズ（2 bits）×管理対象（4つ）となる。一方、集団識別子を用いてリダクションされた状態情報を受信側ノードが各送信側ノードから集約して受信する場合（図１０（ｂ））は、次のようになる。各管理対象の状態情報を受信するために受信側ノードに必要とされるメモリ量は、最小書き込みサイズ（4 bits）×管理対象数（4つ）／領域内のビット数(4 bits)で足りる。
本実施形態ではさらに、場合に応じて、メッセージに含める情報の内容に工夫する事、つまり、図４の識別子のコード化体系４０３により、メッセージに使用されるネットワーク上での通信効率およびメモリ領域の使用効率を高めることができる。以下にコード化方法についての基本的な考え方について説明する。
通知対象事象の性質に適したコード化の工夫によって、ネットワーク上での通信に必要な通信量、ならびに、情報集約ノードでの受信に必要なメモリ量および通信処理時間の改善度を大きくすることができる。下記に定義する意味の「分解能」は、コード化に際して考慮すべき「通知対象事象の性質」として特に重要である。
正の整数k に対し「通知対象事象が同じ時点で発生した管理対象の数がk 以下の時、かつ、その時に限り、図４の識別子分析機構４０２が受信した集団識別子から通知対象事象が発生したノードを特定する事ができる」場合を仮定する。この仮定が成立するとき、識別子分析機構４０２の（識別子集約機構４０１、個別識別子、集団識別子を含む「システム」としての）「分解能」がk であると定義する。通知対象事象が発生しうる管理対象の数をN とするとN ≧ k となる。
以下の説明においてさらに、
N = k の場合、識別子分析機構４０２は「分解能」が「完全」
（あるいは制限がない）。
N > k の場合、識別子分析機構４０２の「分解能」が（上限k で）制限されている。
という表現も用いる事にする。分解能が制限される場合、所定の長さのメッセージ内で伝達すべき情報に「全管理対象についての監視すべき状態の成立、不成立の区別」全てを含める必要がない。このため、同じ長さのメッセージ領域に他の情報、具体的には、監視すべき状態が成立した対象の識別子の一部についての情報を含めれば、なにかしら判別できる情報を送ることができる。複数の情報が入っている（１列に２ビット以上立っている）ときは、監視状態にある管理対象のうちのどれかで異常が発生したかがわかればよいような場合に対応できる。図１１は、集団識別子の分解能の概念の説明図である。集団識別子の分解能が完全な場合、図１１（ａ）に示されるように、全ての状態の組み合わせに対し監視状態にある管理対象とそうでない対象が特定される。集団識別子の分解能が制限されている場合、図１１（ｂ）に示されるように、監視状態にある対象数が上限を越えない場合は、対象が特定される。一方、監視状態にある対象数が上限を越えた場合は、対象が特定されない。
図１２は、分解能が完全な場合と制限されている場合における、リダクションによる情報集積での通信量およびメモリ使用量削減の効果の説明図である。例えば図１２（ａ）に示されるように、N個（図中では３個）の管理対象について、分解能を制限せずに各管理対象での監視状態の成立／不成立という1ビットの情報を受取るには、少なくともN ビット（図中では3ビット）が必要である。しかし、例えば図１２（ｂ）に示されるように、分解能k が制限されている（k < N) 場合には、N bit より小さい領域で、N 個より多くの管理対象からの監視状態に関する情報を受信する事が原理上可能である。図１２（ｂ）では、分解能に上限1 を設定して3 bits の領域で5 個の管理対象の状態を受信する場合を示している。本実施形態は、主として図４の識別子のコード化体系４０３の工夫により、実際にそれを実現する。
本実施形態では、分解能が制限される場合に、「ある領域に格納可能な識別子の集合の数値としての特性」を情報圧縮に利用している。
本実施形態では、分解能が制限される場合には、後述する第５から第９の実施形態等による図４の識別子のコード化体系４０３の工夫により、前述した技術課題２を解決している。また、完全な分解能が必要なケースにおいては、第４または第１０の実施形態で後述するように、管理対象を（必要なら複数の階層に）グループ分けしたものを新たな管理対象と見なすことにより、前述した技術課題２を解決している。
以上のようにして、第１の実施形態によれば、情報集約型通信の所要時間を削減することが可能となる。特に、受信あるいは中継に必要なネットワーク上の通信量、及び、各ノードでのメモリ領域アクセス量とメモリアクセスに伴うオーバヘッドが大幅に削減される。
また、第１の実施形態によれば、中継ノードおよび受信ノードでの参照メモリ領域が小さくなる事で、システム全体として見たメモリバス帯域やキャッシュの使用量も削減されると、状態監視＋状態の共有処理に関連する負荷が下がる。これにより、システム全体でのスループットが向上する効果もある。
第１の実施形態によれば、集団識別子の使用により、ネットワーク上での通信量、及び、情報集約ノードで受信に必要なメモリ量および通信処理時間は、各ノードからの状態情報を単に集約して受信する場合と比較して、大幅に削減される。
第１の実施形態により、特に必要な「分解能」に上限がある場合、図１２（ｂ）で説明した考え方により、通信量およびメモリ使用量を削減することが可能となる。
さらに、受信に必要なメモリ量の削減は、受信と並行して行われる（受信と独立の）計算処理によるメモリアクセスと受信時のメモリアクセスの競合を減らす事を通じて、計算処理と受信処理がオーバラップして実行されるシステムでの総合的な性能を改善する事による、派生的な効果も大きい。
図４の識別子のコード化体系４０３の詳細については、後述するいくつかの実施形態で詳細に説明する。
＜第２の実施形態＞
次に、第２の実施形態について説明する。
第２の実施形態の基本的な機能構成は、図４で説明した第１の実施形態に係る構成と同じである。また、第２の実施形態の全体的なシステム構成も、図７で説明した第１の実施形態に係る構成と同じである。さらに、第２の実施形態における識別子のコード化体系４０３およびリダクション４０４（ともに図４参照）の基本的な機能も、図９で説明した第１の実施形態に係る機能と同様である。
第１の実施形態で図８（ａ）を用いて説明したように、図４の識別子のコード化体系４０３は、個々の管理対象に対応する各個別識別子を当該管理対象に対応する位置のbitがonにされたデータによってコード化する。この場合の個々の管理対象に対応するbit位置は、例えば以下の(1)〜(5)のように定められる。
(1)管理対象（ノード、サブシステム、ジョブ...）数がN個である情報集約システム内でのbit単位の情報共有に際して、N bitsの連結なメモリ領域、又は区分的に連結な領域を用意する。連結な領域が用意される場合、１回のbit操作命令の適用対象となる大きさs bits（多くの場合、CPU（の演算器）がサポートする整数の大きさ）ごとに連結な領域が区分して扱われるならば、x番目の領域は、先頭からs×x bits (s×x/9 bytes）目として特定される。区分的に連結な領域の場合に、１回のbit 操作命令の適用対象となる大きさs bits毎に連結な領域が区分して扱われるならば、まずx番目の領域の先頭アドレスを（ポインタを格納した表等により）特定する。
(2)前述のN bitsのメモリ領域をreduction或いはatomic operationによる更新単位m bits 毎に分割する。分割後のbit領域数をnとする。例えば、1024個のノードに対応する1024 bitsに対し、atomic operationが128 bits単位でしか行えない場合、8個の128 bitsの領域を用意する。なお、atomic operationについてのアラインメント制約が16 bytes(=128 bits)単位でもある場合、16 byte境界にある領域を使用する。Nがmの整数倍でない場合には、領域末尾にダミービットを追加してmの整数倍にする。
(3)i番目（iは、１〜Ｎの整数）の個別識別子をiとし、m bit毎に分割後のn個のbit領域の番号j及び各m bitsの領域内のbit番号をkとして、iと(j,k)とを１対１に対応付ける。例えば、連結領域の場合、j = ((i-1)/m)+1, k = i-j*m というように対応付ける。この場合、逆写像は、i = (j-1)*m + kとして得られる。情報集約システム内での個別識別子と管理対象番号とは、「下位の桁を取る」等の代数的な変換により行うか、管理対象番号と個別識別子との対応表を作成することに対応付けられる。
(1)〜(3)での処理を図１３を用いてさらに説明する。図１３は、管理対象番号と受信側ノードのメモリ領域内の集団識別子格納領域のbit位置との対応関係の説明図である。図１３に示すように、情報集約システム内で管理対象とされるノードは、整数領域s内のbit数以下の数のノードの集合に分割され、ノードの集合と整数領域とが対応付けられる。また、N bitsのメモリ領域は、m bitsのビットフィールドに分割され、ノードの集合内の管理対象番号（ノード番号）と整数領域内のビット番号とが対応付けられる。管理対象番号と個別識別子とは対応付けられるため、個別識別子とメモリ領域内の所定位置の1 bitとが対応付けられる。
(1)〜(3)の上述の処理は、情報集約システムの運用開始前に計算機により予め実行される。図１４は、管理対象とbit位置とを対応付ける計算機の構成例を示す図である。図１４に示すように、計算機は、CPU１４０１、メモリ１４０２、入力装置１４０３、表示装置１４０４、外部記憶装置１４０５、記録媒体１４０９にデータを書き込み可能な記録媒体書き込み装置１４０６、及び通信インタフェース１４０７を含む。これらはバス１４０８により相互に接続される。管理対象とbit位置とを対応付けは、CPU１４０１により実行され、実行結果は、表示装置１４０４に表示され、記録媒体書き込み装置１４０６を介して記録媒体１４０９に記録される。記録媒体１４０９に記録された上述の対応関係を示すデータは、図７のシステム構成で管理対象の識別を必要とする送信起点ノード７０１や受信・中継ノード７０２のメモリ７０１−２や７０２−２内に、特には図示しない記録媒体読み取り装置を介して記録され得る。
図１５は、演算が乗法の場合における受信側ノードが持つ個別識別子表の例を示す図である。（ａ）から（ｄ）が使用される素数または素数冪であり、（ｅ）と（ｆ）が対応関係を示す表である。また、（ｇ）は管理対象番号とガウス整数での「素数」（素元）の実部および虚部との対応関係、（ｈ）は管理対象番号とアイゼンシュタイン整数での「素数」（素元）の１の係数およびωの係数との対応関係を示す表である。
図１６は、演算が加法の場合における受信側ノードが持つ識別子表の例を示す図である。図１６は、図４のリダクション４０４の機能で使用する演算は加法、分解能の上限は２、識別子のフィールド長は７ビットである場合の例示である。（ａ）は、個別識別子と管理対象番号の対照表である。（ｂ）は、集団識別子とその生成因子である個別識別子のビットマップとの対照表である。このビットマップでは、監視条件が成立するときに値が１、不成立のときに値が０をとる。（ｃ）は、集団識別子と「生成因子として含まれる最大の個別識別子」の対照表である。（ｄ）は、集団識別子と「生成因子として含まれる最小の個別識別子」の対照表である。
上記図１５および図１６ともに、各識別子表は、図４の識別子のコード化体系４０３を実現するものであり、各識別子表を表すデータは、図７において受信側ノードとして機能する受信・中継ノード７０２のメモリ７０２−２上に展開される。
図４の識別子分析機構４０２が加法を演算として図１６の対照表を使用する場合、「受信した集団識別子の生成因子である個別識別子」を得るためには、集団識別子と生成因子である個別識別子の少なくとも１つ、あるいは（ビットマップ、配列、連結されたリストなどで表現された）複数の個別識別子と対応付ける図１６（ｃ）または（ｄ）のような対照表が必要になる。
分解能が2 以上の場合、対照表のエントリ数が個別識別子の数より大きくなるため、対照表全体を保持するために必要なメモリ７０２−２（図７）の記憶容量は大きくなる。従って、ハードディスク記憶装置などの二次記憶媒体が必要になる事もありうる。しかし、本実施形態における識別子の検索（集団識別子から生成因子の個別識別子を求める処理や、個別識別子から管理対象の番号を求める処理）１回あたりのメモリ参照量は例えば、後述する実施形態で説明する「ハッシュ関数」の手法により抑えることが可能である。
(4)図７の送信起点ノード７０１や受信・中継ノード７０２のCPU７０１−１や７０２−１が実現する図４の識別子のコード化体系４０３の機能は、次のような処理を実行する。識別子のコード化体系４０３は、m bits毎に区分された第j領域に対して第k bitをonにするデータを、必要に応じて（例えばある管理対象の状態フラグがonのときに）、ReductionないしAtomic Operationへの引数として与える。例えば、1024個の管理対象に対応する1024 bitsに対して、atomic operationが128 bits単位でしかデータ処理を行えない場合、ノード番号130のノードは、２番目の128 bits領域へのbitwise or演算を第2 bitをonにしたデータで行う。これにより、識別子のコード化体系４０３は、当該ノードでの管理対象についての条件成立を通知する。ここで、m bitsに区分された領域内でのbit番号は、どちらから数えてもよい。特に、m bitsが使用する計算機のword長として、その計算機アーキテクチャのEndianでの番号の付け方とbit 番号の付け方とが同じである必要はない。例えば、受信側ノードで集団識別子から個別識別子を特定する処理（の高速化）に都合がよい方が選ばれてよい。
図１７は、第２の実施形態における送信側ノードにおける識別子集約機構４０１（図４）による処理の例を示すフローチャートである。
ここでは、
集団識別子=｛全てのリダクション演算結果格納済ビットフィールドの値｝
個別識別子=(ビットフィールド番号, ビットフィールド内のビット位置)
であるとする。
識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１または受信・中継ノード７０２のCPU７０１−１は、当該ノードが管理する管理対象のビットフィールド番号をビットフィールド番号に入力する（ステップＳ１７０１）。
当該ノードが図７の送信起点ノード１７０１（送信側ノード）である場合（ステップＳ１７０２の判定がＹＥＳ）、図７のCPU７０１−１は、ビットフィールドの初期値として0（ゼロ）を入力する（ステップＳ１７０３）。一方、当該ノードが通信の起点ノードではない、すなわち中継ノードとして機能する図７の受信・中継ノード７０２である場合（ステップＳ１７０２の判定がＮＯ）、次の処理が実行される。CPU７０２−１は、ビットフィールドの初期値として前段のノードから受信した値を入力する（ステップＳ１７０４）。
自ノードが管理する管理対象において通知すべき条件が成立した場合（ステップＳ１００５の判定がＹＥＳ）、CPU７０１−１または７０２−１は、ステップＳ１７０３又はステップＳ１７０４で入力されたビットフィールド値と管理対象に対応するビットとをor演算する（ステップＳ１７０６）。一方、当該ノードが管理する管理対象において通知すべき条件が成立しない場合（ステップＳ１７０５の判定がＮＯ）、CPU７０１−１または７０２−１は、ステップＳ１７０７の処理へ進む。CPU７０１−１または７０２−１は、NIC７０１−３または７０２−３を介して、演算結果を集団識別子として次の転送先のノードへの送信内容として送信し（ステップＳ１７０７）、一連の識別子集約機構４０１の処理を終了する。
(5)中継ノード又は受信ノードは、受信されたN bits（n個のm bits領域）を参照することにより、管理対象（システム、サブシステム、ジョブ、装置等）の全体の情報を得る。なお、情報を集約する全ノードが所定の領域を更新したことを確認するには、例えば、各ノードが情報を更新した後でバリア同期が実行されるか、同期機能を含むreduction操作が行われればよい。
上述した(1)〜(5)の処理によって、各ノードは、管理対象毎に1 bitの状態情報を集団識別子に含めて受信側ノードに通知できる。また、任意長のデータは、ビット列に分解して通知できる。ただし、reductionの演算対象となるデータ領域のbit数をmとすると、m bitsより大きいデータについては、m bits単位に分けて処理される。
図１８は、第２の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の集団識別子全体に渡る受信処理の例を示すフローチャートである。識別子分析機構４０２の処理が開始されると、図７の受信・中継ノード７０２のCPU７０２−１は、ビットフィールド番号の初期値として1を入力する（ステップＳ１８０１）。現在のビットフィールド番号がビットフィールド数以下である場合（ステップＳ１８０２の判定がＹＥＳ）、CPU７０２−１は、自ノードにより受信された集団識別子内の当該ビットフィールド番号のビットフィールドに対する処理が実行される（ステップＳ１８０３）。
ステップＳ１８０３での処理が終了すると、CPU７０２−１は、ビットフィールド番号に１を加算し（ステップＳ１８０４）、ステップＳ１８０２での処理に戻る。
ビットフィールド番号がビットフィールド数を超えた場合（ステップＳ１８０２の判定がＮＯ、CPU７０２−１は、一連の識別子分析機構４０２の処理を終了する。
図１９は、図１８のステップＳ１８０３の詳細処理である、第２の実施形態における受信側ノードにおける識別子分析機構４０２による集団識別子を構成する個々のビットフィールドの受信処理の例を示すフローチャートである。
所定のビットフィールド番号のビットフィールドに対する処理が開始されると、CPU７０２−１は、所定のビットフィールド番号のビットフィールドの値を取り出し、取り出されたビットフィールド値をメモリ７０２−２内の作業領域Wに格納する（ステップＳ１９０１）。
作業領域Wに格納された値が0（ゼロ）ではない場合（ステップＳ１９０２の判定がＮＯ、CPU７０２−１は、個別識別子内の1が現れるビットBを作業領域WからLeading Zero Count（LZC）又はTrailing Zero Count（TZC）の次のビット位置を見て特定する（ステップＳ１９０３）。ここで、LZCとは、Number of Leading Zero（NLZ）を求める操作であり、NLZとは、Most Significant Bit（MSB）から最初に1が現れるまで数えた0の数を指す。また、TZCとは、Number of Trailing Zero（NTZ）を求める操作であり、NTZとは、Least Significant Bit（LSB）から最初に1が現れるまで数えた0の数を指す。
CPU７０２−１は、特定された個別識別子に対応する管理対象番号を特定し、特定された管理対象番号の管理対象に対して事前に定められた処理を実行する（ステップＳ１９０４）。CPU７０２−１は、ステップＳ１９０３で特定されたビットBの値を0（ゼロ）にオフし（ステップＳ１９０５）、ステップＳ１９０２での処理に戻る。
作業領域Wに格納された値が0（ゼロ）になった場合（ステップＳ１９０２の判定がＹＥＳ）、CPU７０２−１は、所定のビットフィールド番号のビットフィールドに対する一連の処理を終了し、図１８のステップＳ１８０３の処理を終了する。集団識別子は、単位元＝０（図１７のステップＳ１７０４参照）の状態からビット単位のor演算によって個別識別子が順次追加されてゆく（図１７のステップＳ１７０６）。従って、図１９のフローチャートでは、ビット単位or演算の逆演算（ステップＳ１９０３）によって個別識別子が順次特定されてそのビットがオフにされてゆき（ステップＳ１９０５）、最後は単位元＝０にもどる。よって、ステップＳ１９０２の判定がＹＥＳになると、図１９のフローチャートの処理が終了する。
各ノードのデータを表すビット列を有限体GF(2)のベクトルと見なし、複数ノードのデータを表すベクトルの集合から行列を作ると、第２の実施形態に従った送信側ノードのデータ送信は、次のような仮想的な転置行列に基づく通信方法にあたる。
本出願人が通常考えるデータ集約通信では、各送信側ノードに対応するデータを、下記のように、受信側ノードが元のまま「各ノード毎に一つ」の形で、受け取る。
node01 | b11 b12 ... b1m (node01 に対応する「行ベクトル」）
node02 | b21 b22 ... b2m (node02 に対応する「行ベクトル」）
... ... ...
node0N | bN1 bN2 ... bNm (node0N に対応する「行ベクトル」）
一方、第２の実施形態に従った受信側ノードは、全ての送信側ノードから送信されたデータの「同じ種類のデータの同じ位置のビットをノード順に並べたもの」を受信する。個々のノードからbitデータのまとまりを受信側ノードが読む場合、再び下記のような行列と見なした時の各行を見ることによって（リダクションによる送信結果の）転置後の行列から転置前の行列の各列を再現できる。
第1bit | b11 b21 ... bN1 (第1bitに対応する「列ベクトル」）
第2bit | b12 b22 ... bN2 (第2bitに対応する「列ベクトル」）
...
第mbit | b1m b2m ... bNm (第mbitに対応する「列ベクトル」）
第２の実施形態に従った情報集約システムによれば、第１の実施形態の場合と同様に、情報集約型通信の通信量および所要時間を削減できる。さらに、受信あるいは中継に必要な各ノードでのメモリ領域のアクセス量とメモリアクセスに伴うオーバヘッドが大幅に削減される。中継ノードおよび受信ノードでの参照メモリ領域が小さくなることで、システム全体として見たメモリバス帯域やキャッシュの使用量も削減されると、状態監視及び状態の共有処理に関連する負荷が下がり、システム全体でのスループットが向上する効果も得られる。
さらに、受信側ノードが各送信側ノードからの1 bitの状態情報を集積して、所定の状態が発生した管理対象に対してのみ特定の処理を行う場合、次のような技術的効果が得られる。所定の状態が発生した管理対象に対してのみ特定の処理を実行する場合、gatherによって各ノードから集めたデータを直接使用する方法よりも、整数領域のbit演算によるreduction により、bit 位置をノードに対応させたデータを参照して処理する方が高速である。なぜなら、gather により管理対象の状態情報を受信側ノードに集積した場合、各々の管理対象の情報は、最小パケット長ないしwrite RDMA の最小長程度に離れた領域にある。このため、受信側ノードは、各管理対象が所定の状態にあることの判定に際して、load命令を管理対象毎に発行する必要がある。一方、実施形態に従ったリダクションを伴う集積方法に従えば、整数を表す領域をm bitsとすると、m個の管理対象の状態が予め１つの整数に統合されている。このため、load命令発行回数が1/mになり、単位時間あたりのキャッシュミスの発生率が大幅に抑えられ、処理が高速化される。
また、複数bits の情報を集積する場合も含めた技術的効果を、使用するメモリ領域の大きさを中心に更に詳述する。第２の実施形態のように、リダクション操作が可能な大きさの領域のビット全てを有効利用すれば、「個々のノードからのパケットに送信元のノードの情報全てを入れてwrite RDMA を使う」場合に比べ、受信用のメモリ領域を小さくし得る。
まず、各ノードから通知すべき情報が1 bitとし、write RDMAで書き込める最小単位をW bitsとし、送信側ノード数をNとする。各ノードがwrite RDMAで情報を書き込む方法では、受信側ノードでは、NW bitsのメモリ領域が必要になる。一方、本実施形態での所要領域は、N = qm + r (0≦r<W) と書くとき、(qm) bits 以上((q+1)m) bits未満、すなわち、Nbits 以上(N+m) bits 未満となる。N、W、及びmは、正の整数であり、Wとmは、同程度の大きさである。N>1であれば、常にN+W < NWである。したがって、1 bitの通知（ある事象発生の有無）での第２の実施形態におけるメモリ効率は、各ノードからwrite RDMAで通知を行う場合と比較してNW/(N+W)倍であり、N >> Wならば、W倍程度となる。Wは、数十bits から百数十bits 程度であり得るので、千ノードより大規模な情報集約システムでは、N >> Wと考えてよい。
各ノードから通知すべき情報がX bitsである場合、各ノードがwrite RDMAで情報を書き込む方法では、W bits単位に見て有効利用されていない部分がY bits あれば、YN bits が冗長になるので、一般に冗長ビット数のオーダは、Nの程度で、ランダウの記号でO(N)と書かれる。特にX = 1の場合、Y = W-1であり、(W-1)N bits が冗長となる。一方、第２の実施形態において各ノードから通知すべき情報がX bits の場合、1bit の通知に必要な領域をX組用意することになる。冗長ビット数が最大になるのは、各bitの転送毎に見るとNをmで割った余りrが1になる場合である(m-1) bitsであるから、X 組使う場合は、X(m-1) bitsである。すなわち、第２の実施形態では、ノード数Nが増加しても冗長ビット領域を一定の大きさ以下に止めておく効果があり、N >> X ならば、各ノードがwrite RDMAで情報を書き込む方法と比較して所要メモリ領域を著しく小さくできる。仮に、N及びXが同程度の数である場合であっても、第２の実施形態に従えば、冗長ビット数が少なくなり、メモリ効率が良くなり得る。なぜなら、Nがmで割り切れる場合、1 bitを転送する際の冗長ビット数は、0であり、従って、任意のX > 1 についてX bitsを転送する際の冗長ビットも0になる。Nをmで割った余りrがmに近い場合、1 bitを転送する際の冗長ビット数は、m-rとなり、各ノードがwrite RDMAで情報を書き込む方法における冗長ビット数と第２の実施形態の冗長ビット数との比は、((W-1)/N) / X(m-r)となる。したがって、(m-r) < (X(W-1)/N) であれば、((W-1)/N) / (X(m-r))) > 1となり、第２の実施形態の方が所要メモリ領域が小さくなる。例えばN = Xの場合には、m-r < W-1ならばよい。
＜第３の実施形態＞
次に、第３の実施形態について説明する。
第３の実施形態の基本的な機能構成は、図４で説明した第１の実施形態に係る構成と同じである。
第３の実施形態に従った情報集約システムは、第２の実施形態に従った情報集約システムと同様に、各管理対象に対応する個別識別子を管理対象の通し番号に対応するビットとする。しかしながら、第３の実施形態に従った情報集約システムでは、第１または第２の実施形態に係る図７とは、構成が異なる。第３の実施形態では、図２０、図２１、図２２に示されるように、図４のリダクション４０４におけるbit演算を、ノード内のCPU７０１−１や７０２−１ではなく、Atomic Operationやネットワークのreduction機能等のノード間演算装置を用いて実現する。
図２０は、第３の実施形態に従った情報集約システムの第１の構成例を示す図である。図２１は、第３の実施形態に従った情報集約システムの第２の構成例を示す図である。図２２は、第３の実施形態に従った情報集約システムの第３の構成例を示す図である。
図２０、図２１、または図２２の情報集約システムの構成例において、図７の場合と同じ機能を有する部分には、同じ番号を付してある。
図２０、図２１、または図２２に示すように、第３の実施形態に従った情報集約システムでは、第１または第２の実施形態に従った情報集約システムとは異なって、送信起点ノード７０１のCPU７０１−１や受信・中継ノード７０２のCPU７０２−１には、図４の識別子集約機構４０１や識別子分析機構４０２が含まれない。一方、第３の実施形態に従った情報集約システムでは、個別識別子を集団識別子にまとめる識別子集約機構４０１を実行する独立筐体型のノード間演算装置２００１が、図２０に示されるようにノード外の中継装置７０３に接続され得る。また、図２１に示すように、ノード間演算装置２１０１または２１０２が、送信起点ノード７０１または受信・中継ノード７０２内の各構成要素とは別個に、各ノード内に実装され得る。さらに、図２２に示すように、ノード間演算機能が、送信起点ノード７０１または受信・中継ノード７０２内のNIC２２０１または２２０２と一体化されて実装され得る。
図４のリダクション４０４の機能は、例えば、Message Passing Interface（MPI）規格でMPI_reduceという名のAPI で定義される処理を指し、個別のデータを指定した２項演算の反復により演算前と同じ型の１つのデータに縮約することを指す。例えば、指定する２項演算が加法であれば、対応するリダクションの結果は、全ノードのデータの総和となる。MPI規格では、MPI_reduceによるリダクションで指定可能な演算として、加法以外にも乗法、bitwise or、「最大値と場所の対」等を指定するマクロが定義されている。
分散メモリシステムの環境における上記のリダクション４０４の性能は、ノード間の通信時間によって決まり、演算の所要時間は、無視できる割合になる。しかしながら、システム規模の増大に伴って、リダクション４０４は、入力情報を持つ全ノード間での、複数段階の中継動作を伴う処理になり得る。
ノード間の通信時間の相当部分は、ネットワーク装置の主記憶装置へのアクセスオーバヘッド、すなわち、IOバスをデータが通過する時間と、IO処理を制御し演算を行うためのCPU時間である。CPU上で演算を行うためには、まずメモリに格納された演算対象のデータをCPUに取り込む必要があり、演算結果をメモリに再び格納する必要がある。さらに、ネットワーク上で複数段の中継処理をしながらリダクション４０４の演算をCPU上で行う場合には、IOバスとメモリバスをデータが各段の中継について２回通過することになる。これに対し、ノード間演算機能を有するネットワーク装置の内部で演算が行われれば、IOバスとメモリバスをデータが通過することによるオーバヘッドは削減され、リダクション性能は、大幅に向上する。
第３の実施形態に従った情報集約システムにおいて、識別子の集約処理の手順は、bit演算がノード間演算装置により実行される点を除いて第１の実施形態と同様である。ただし、ノード間演算装置で利用可能な演算の種類は、CPU上のソフトウェアによって演算が実行される場合と比較して限定されるため、ノード間演算装置で利用可能な機能を用いて演算処理を実現するように工夫を要する。
以下に示す文献[1]から[5]は、上述ような機能を持つ装置に関する技術である。
[1] A. Gara et al,"Overview of the Blue Gene/L system architecture",IBM Journal of Research and Development VOL. 49 NO. 2/3 March/May 2005, p.7-8.
この文献[1]では、「複数ノード上のデータに対する演算を CPUとは独立に行う装置」の例であるBlue Gene/Lの Collective Network の機能が開示されている。ノード間演算機能は、各ノードの「Collective Network 用ネットワーク・インターフェース」に内蔵されている。
[2] 石畑宏明,「高機能・高性能システムインターコネクト技術の開発」 p.3 [平成26年4月1日検索]、インターネット
(URL: http://ngarch.isit.or.jp/psi/images/event/hiroaki_ishihata_20061220.pdf)
[3] 清水俊幸,「コレクティブ通信をサポートする高機能スイッチの開発」 p.2,p10 [平成26年4月1日検索]、インターネット
(URL:http://ngarch.isit.or.jp/psi/images/event/toshiyuki_shimizu_20080218.pdf)
上記文献[2],[3]では、「複数ノード上のデータに対する演算をCPUとは独立に行う通信装置」の中で「独立筐体型のノード間演算装置」の一例である「高機能スイッチ」の機能と内部構造が開示されている。
[4] Y. Ajima, S. Sumimoto, T. Shimizu,"Tofu: A 6d mesh/torus interconnect for exascale computers",IEEE Computer, Vol. 42, No. 11, pp.36-40 (2009)
[5] Y. Ajima, T. Inoue, S. Hiramoto, T. Shimizu, Y. Takagi,"The Tofu Interconnect",IEEE Micro, Vol. 32, Issue 1, p.21-31(2012)
上記文献[4],[5]では、スーパコンピュータ「京」(The K computer) 独自のネットワークであるTorus fusion (tofu)のICC(InterConnect Controller:ネットワーク・インターフェースとルータを兼ねる）のTBI(Torus Barrier Interface)の機能が開示されている。TBIは、本出願における図２２のノード間演算機能を内蔵したNIC２２０１または２２０２の例である。文献[2],[3]での「高機能スイッチ」と実現形態は異なるが、機能的には同等である旨が文献[4]で述べられている。
第３の実施形態では、上記文献[1]から[5]に開示されているようなハードウェア機構を、ノード間演算装置２００１（図２０）、２１０１または２１０２（図２１）、NIC２２０１または２２０２（図２２）として利用できる。
reduction機能をサポートするネットワーク装置（ノード間演算装置）は、整数の加法、乗法、bitwise {and, or, exclusive or}、max, min、浮動小数点の加法等の比較的多様な種類の演算機能を持つ場合が多い。しかしながら、サポートされる演算の種類、対応されているデータ型、及び一度に操作できるデータの大きさや個数は、ネットワーク装置の種類によって異なる。サポートされるデータの大きさやデータ数の範囲内ではAtomic Operationやreductionが実現できない場合、階層化、複数領域の使用、及び反復使用等によって適用範囲を広げる必要があり得る。そこで、第２の実施形態で説明した、使用可能な演算のいずれかで、ネットワーク装置がサポートしている演算を使用する。
また、並列処理でのreductionに関するAPI標準であるMPI規格でのリダクション機能は、同期機能を含意するため、並列処理環境のネットワーク装置が提供するリダクション機能には、完了時の同期機能が含まれる場合が多い。この場合、受信側ノードは、全ての送信側ノードからのデータが揃った事を同期完了により知ることができる。
一方、例えばInfiniBandのFetch and Addのように、他のノードが行った演算の完了が通知されないノード間演算機能が用いられる場合には、送信側の全ノードのデータが揃ったタイミングを別の方法で知る必要がある。そこで、送信側ノードと受信側ノードとの間では、次の(a)又は(b)のような同期手続きが行われる。
(a)全送信側ノードと受信側ノードとの間で、次のようにバリア同期を実行する。すなわち、送信側ノードは、自ノードからの個別識別子コードの送信完了後、バリア同期を開始する。受信側ノードは、バリア同期を最初から開始しておく。
(b)受信側ノードが送信側ノードの更新する特定の領域を監視する。すなわち、送信側ノードは、自ノードからの個別識別子コードの送信完了後、受信側ノード上の領域（初期値は0）に対し、Fetch and Andで、自ノードが情報通知を担当する管理対象の数を加える。受信側ノードは、送信側ノードがFetch and Addで更新する領域を監視し、領域内のデータが管理対象の数に一致したら終了と判定する。
なお、送信側の全ノードが直接受信側ノードの領域にFetch and Add を実行する事は（カウンタがオーバーフローする事がなくても）性能的に得策とは限らないので、Fetch and Add による同期を複数階層に分けて段階的に実施した方が有利な場合もある。この階層化はソフトウェアよって行われるが、各階層の演算をネットワーク側のハードウェアが割り込みによるCPU への通知に伴うオーバヘッドなしでデータが集約される事、およびこれらの機構を使わずにCPU 上のソフトウェアがでリダクションを行う場合と比較すれば、１階層で集約可能なノード数を大きくとれる事も、第３の実施形態における性能上の利点となる。なぜならば、ノード間演算機構やFetch and Add を使わない場合は、１階層あたりのノード数と同じ回数、情報集約に関しての上位ノード側が通信処理を反復する必要があるため、大規模なシステムでは、各段での遅延が大きくなり過ぎる事を防ぐため、１階層での集約ノード数を２や３などの小さい数にせざるを得ず、中継段数が増える傾向になるからである。
第３の実施形態に従った情報集約システムによれば、第１または第２の実施形態に従った情報集約システムと同様の前述した技術的効果が得られる。また、第３の実施形態に従った情報集約システムによれば、通信完了までの実時間が短縮され、受信側ノード（階層的な処理をする場合の中間ノードを含む）の負荷が軽減できる。
＜第４の実施形態＞
次に第４の実施形態について説明する。
本実施形態は、第１、第２，第３の実施形態を前提に、受信側ノードが集団識別子を受信した後の処理の高速化に関する実施形態である。
各管理対象のデータは1 bit で代表される。対応する管理対象が所定の状態にある場合、管理対象に対応する位置のbit がon (1) であり、そうでない場合off (0) とする。
受信のための集団識別子の記憶領域は、各々が「整数」として処理できる複数のm bits領域から構成されるとする。
「所定の状態にある管理対象に対し特定の処理を行う」場合「各mbits 領域中のbit を全て順に見て、1ならば処理を行い、0 ならば次に進む」という処理が、よく行われる。
しかし、この方法では、第１の実施形態において説明した図３のように、ほとんど全てのビットが0の疎なbit列で示されるように、比較的少数のノードが所定の状態にある場合に、多くの条件判定とbit 参照を、結局は処理を行わないノードに対応するbit に対しても行う事になる。
すなわち、このような種類の処理では、所定の状態にある管理対象が比較的少数である時、結局は処理を行わない管理対象に対応する領域を多く参照するために、キャッシュミスと引き続くメモリ参照が多発して、受信側ノードの処理時間が大きくなる。
所定の状態にある管理対象が比較的少数の場合、「予め管理対象のグループに対応する複数の領域のlogical or を取り、結果が0 となるグループは飛ばして処理する」事でbit 操作回数が減って高速化される可能性がある。しかし、この方法では全管理対象に対応する領域へのload 命令が発行されるという点では変わりがないので、大幅な高速化は期待できない。
そこで、例えば、各グループ毎に代表のノードで「取りまとめ」を行うことを考える。例えば、前述した第３の実施形態のように、InfiniBand 等のFetch and Add を利用するリダクションを使用する実施形態において、もともと「取りまとめ」ノードが存在する場合には、この方法を使用する際に追加で必要になるシステム資源は少ないため、この方法も考えられる。
本実施形態では、管理対象を（必要なら複数の階層で）グループ分けしたものを新たな管理対象と見なす。図２３は、管理対象（ノード）のグループ化の階層の説明図である。また、図２４は、管理対象のグループ化階層と各サブグループに対して「割当てられた識別子」の対応関係の説明図である。また、図２５は、図２４の具体例である。本実施形態では送信側ノードで予めグループ内の管理対象に対してlogical or を実行しておく。すなわち、図２３に示されるように、管理対象を階層的にグループに分ける。次に、図２４および図２５の具体例に示されるように、「グループ内に一つでも所定の状態にある管理対象がある」場合、そのグループを管理するノードが、グループに対応するbit位置をon、他のbit 位置（他のグループに対応するbit 位置）をoffにしたデータを作る。そして、このようなデータを入力として、元々の管理対象の状態通知とは別にreduction を行う。
以上の処理は、「管理対象のグループ」を「（仮想的な）上位の管理対象」に設定した事に他ならず、送信側ノードでの処理手順には、一部のノードでの管理対象が増える以外には、グループ分けをしない第１、第２，または第３の実施形態場合と同様の処理が実行される。すなわち、第４の実施形態では、集団識別子を格納すべき記憶領域に、グループ用の領域を指定するのみでよい。
受信側ノードは、各グループ（上位の管理対象）に対応する領域内のbit のon / off に基いて、グループ内の（下位の）管理対象に対する領域参照の必要性を判定し、参照不要な領域を飛ばして処理を行う。すなわち、図２５の具体例に示されるように、各階層の管理領域でbit on の位置を枝とした木構造として扱う。
特に、最下層の識別子領域の探索の高速化のみを目的にグループ分けを行う場合には、後述するように、この木構造に対し深さ優先探索を行う事で、探索中に保持すべきメモリ領域の大きさを節約する事ができる。
図２６は、階層的なグループ分けで疎なビット列の０でないビットの検索範囲を限定する際の送信メッセージと受信領域の例を示す図である。図２６において、定数の前の0xは16進数表記である事を意味する。図２６に示されるように、階層ごとに、
第ｎ階層領域アドレス｜領域内のビット
という識別子送信メッセージフォーマットで、集団識別子の送信パケットを生成すればよい。「第ｎ階層」は、第１階層、第２階層、第３階層、・・・を示す。「第ｎ階層領域アドレス」は、受信側ノードにおけるメモリ（例えば、図７の受信・中継ノード７０２のメモリ７０２−１）における、集団識別子の記憶領域の第ｎ階層に対応するアドレスを示す。「領域内のビット」は、「第ｎ階層領域アドレス」は、第ｎ階層に対応する集団識別子のビット列である。あとは、各階層ごとに、第１、第２、または第３の実施形態で説明したようにして、自ノードの管理対象に関する個別識別子のビット情報をセットすればよい。
図２７は、第４の実施形態における送信側ノードにおける識別子集約機構４０１（図４）による階層的にグループ化された集団識別子の送信処理の例を示すフローチャートである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１または中継ノードとして機能する受信・中継ノード７０２のCPU７０１−１または７０２−１は、グループ階層番号の初期値として1を入力する（ステップＳ２７０１）。現在のグループ階層番号が既定のグループ階層数以下である場合（ステップＳ２７０２の判定がＹＥＳ）、CPU７０１−１または７０２−１は、自ノードにより受信された「グループ階層番号」が示す現グループ階層での個別識別子から図４のリダクション４０４により集団識別子を求める（ステップＳ２７０３）。
ステップＳ２７０３での処理が終了すると、CPU７０１−１または７０２−１は、グループ階層番号を１増やして（ステップＳ２７０４）、ステップＳ２７０２での処理に戻る。
グループ階層番号が既定のグループ階層数を超えた場合（ステップＳ２７０２の判定がＹＥＳ、CPU７０１−１または７０２−１は、一連の識別子集約機構４０１の処理を終了し、グループ階層化された集団識別子を送信する（ステップＳ２７０５）。
図２８は、第４の実施形態における受信側ノードにおける識別子分析機構４０２（図４）による深さ優先探索を伴う受信処理の例を示すフローチャートである。「深さ優先探索」とは、木構造の階層構造において、階層ごとに横方向に探索するのではなく、階層の最下層まで行ったら最下層管理対象の処理を行い、その後また第１階層に戻り次の最下層の探索を行う処理である。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子分析機構４０２の処理が開始されると、図７の受信・中継ノード７０２のCPU７０２−１は、グループ階層番号の初期値として1を入力する（ステップＳ２８０１）。現在のグループ階層番号が既定のグループ階層数以下である場合（ステップＳ２８０２の判定がＹＥＳ）、CPU７０２−１は、自ノードにより受信された「グループ階層番号」が示す現グループ階層の次階層にゼロでない領域があるか否かを判定する（ステップＳ２８０３）。
ステップＳ２８０３の判定がＹＥＳならば、CPU７０２−１は、図２９で後述する「下層識別子領域の探索」の処理により、現グループ階層の１つ下の階層のゼロでない領域を求める（ステップＳ２８０４）。
その後、グループ階層番号を１増やして（ステップＳ２８０５）、ステップＳ２８０２の処理に戻る。
グループ階層番号がグループ階層数に達して最下層となり、ステップS２８０２の判定がＮＯになると、CPU７０２−１は、ステップＳ２８０４により最下層から取り出されている個別識別子より、管理対象を抽出する処理を実行する（ステップＳ２８０６）。その後、CPU７０２−１は、ステップＳ２８０１の処理に戻り、他のグループ階層に対する探索を続行する。
図２９は、図２８のステップＳ２８０４の下層識別子領域の探索の処理の詳細処理の例を示すフローチャートである。
まず、CPU７０２−１は、図２８のグループ階層番号によって指定されたグループ階層（これを「g」とする）に対応する指定された領域番号のビットフィールドの値を取り出し、メモリ７０２−２の作業領域 W(g) に格納する（ステップＳ２９０１）。
次に、CPU７０２−１は、作業領域W(g)の内容が0（ゼロ）であるか否かを判定する（ステップＳ２９０２）。ステップＳ２９０２の判定がＹＥＳならば、CPU７０２−１は、後述するＳ２９０６の処理に移行する。
ステップＳ２９０２の判定がＮＯならば、CPU７０２−１は、個別識別子内の1が現れるビットBを作業領域W(g)からLZC又はTZC（図１９のステップＳ１９０３の説明を参照）の次のビット位置を見て特定する（ステップＳ２９０３）。
次に、CPU７０２−１は、グル―プ階層番号、階層内の識別子領域番号、およびBから次の階層の識別子領域番号 rを求める（ステップＳ２９０４）。
その後、CPU７０２−１は、ステップＳ２９０３で特定されたビットBの値を0（ゼロ）にオフする（ステップＳ２９０５）。
ステップＳ２９０５の処理の後またはステップＳ２９０２の判定がＮＯの場合、CPU７０２−１は、次の階層の識別子領域番号 rと作業領域W(g)の内容を呼び出し元のプログラム（図２８）に通知する（ステップＳ２９０６）。その後、CPU７０２−１は、図２９のフローチャートの処理を終了し、図２８のステップＳ２８０４の処理を終了する。
第４の実施形態において、以上の動作に加えて、各階層の管理対象に対応する一つのm bits の（整数として扱う）領域内のbit 参照に際して「1 が比較的少ない」場合の高速化を目的とする処理について説明する。この処理の詳細については、下記文献[6]に開示されている。
[6] Henry S. Warren,"Hacker's Delight (2nd Edition)",2012/9/14
この文献は、指定された整数領域内のbitの数え上げ(Population Count) や、整数領域の先頭ないし末尾にある0 であるbits の数え上げLZCやTZCおよび3, 5, 7 など特定の定数での除法について、現在知られている高速なアルゴリズムを開示している。このアルゴリズムは、一般的な計算機で実現することができる。
整数データ領域内で、次のようなbit 演算を高速に実行する手段が知られている。
(a) 整数領域内の1 (bit on) の数を調べる。
(b) 整数領域の末尾（LSB: Least Significant Bit）から数えて最初に1 が現れるbit 位置を求める。
(c) 整数領域の先頭（MSB: Most Significat Bit) から数えて最初に1 が現れるbit位置を求める。
なお、最初に1 が現れるbit 位置を求める事は、最初に1 が現れるまでの0 の数を求める事と同等である事に注意しておく。関連する用語、略語を定義しておく。
Population Count: 領域内の1 の数を調べる操作
NTZ: Number of Trailing Zero: LSB から最初に1 が現れるまで数えた0の数
TZC: Trailing Zero Count: NTZ を求める操作
NLZ: Number of Leading Zero: MSB から最初に1 が現れるまで数えた0 の数
LZC: Trailing Zero Count: NLZ を求める操作
なお、前述の手段(a)の高速演算を手段(b)の高速演算の実現に利用する場合などもある。例えば、32 bits 整数領域内の1 の数は、判定やループを含まない、下記のような5回の代入の繰り返し演算が知られている。ここでbits は32 bits の整数領域、= は代入、& はbitwise and、「a>>b」はaのb bitsのshift（ビットシフト処理）を表し、定数の前の0xは16進数表記である事を意味する。
bits = (bits & 0x55555555) + (bits >> 1 & 0x55555555);
bits = (bits & 0x33333333) + (bits >> 2 & 0x33333333);
bits = (bits & 0x0f0f0f0f) + (bits >> 4 & 0x0f0f0f0f);
bits = (bits & 0x00ff00ff) + (bits >> 8 & 0x00ff00ff);
bits = (bits & 0x0000ffff) + (bits >>16 & 0x0000ffff);
また、CPU が「所定の整数領域内の1 の数を求める命令」(例えば、Intel 社製CPU のSSE 命令の一つであるPOPCNT 命令など）を備える場合、その命令を使用する事で領域内の1 の数は高速に求められる。
前述の手段(b)は、現在の一般的なCPUでの負の数の表現形式が「２の補数」に基づくため、例えば「((x & (-x))-1)」に対するpopulation countにより、NTZを求める事ができる。
前述の手段(c)は手段(b)に比べると、多くのCPUが備える一般的な命令で高速実行する事が難しいとされている。例えばSun Microsystemsが開発し現在SPARC International Inc. が登録商標を保有するSPARC64 IXfx などのCPU が備えるLZC 命令を使用する方法がある。
また、整数とIEEE754 で規定された浮動小数点数の変換がレジスタ間で直接行えるCPUでは、浮動小数点形式への変換での指数部が「２を底とする対数の整数部分」である事を利用した比較的高速な計算方法が知られている。
第２の実施形態の手順(4)で説明した「個別識別子の特定処理（の高速化）に都合が良い方を選ぶ」とは、例えば、受信側ノードがLZC命令を備えるならLSBから、そうでない場合MSBから、管理対象の番号とbitを対応させていく事を指す。
1であるbitが比較的少ない場合、「LZCないしTZCを利用して、1であるbitを順次求めて管理対象を特定する」方法は、「1 bitずつ参照位置をずらし、そのbitが1か否か判定するループ」による方法と比較すれば、いずれにせよ高速である。
LZCを使うかTZCを使うかを、受信側ノードでどちらが高速に実行できるかを基準に選択する事は、システムとしての最適化の一環としての意味を持つ。
以上説明した第４の実施形態によれば、「所定の状態の管理対象」の割合が少なく、m bits の整数領域単位で見て、1であるbitが１つも存在しない領域が多いと想定される場合、管理対象を階層的にグループ化して、「上位の管理対象」についての判定を先に行う事で、処理を高速化することが可能となる。
＜第５の実施形態＞
次に、第５の実施形態について説明する。本実施形態では、個別識別子のコード化方法について説明する。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。
図４の「リダクション４０４」で使用する演算は、第１の実施形態において図９（ｂ）を用いて説明したように、乗法演算により、素数だけでなく、「素数冪の数で、冪の指数自体が再び素数冪である数」を使って、個別識別子の割当てを行う。特に、「冪の指数自体が２の冪」の場合が、「所定の大きさ以下の個別識別子」の数を増やす観点からは、最も効率がよい。
本実施形態は、第１の実施形態で説明した分解能が完全である必要がない（固定の上限k より多くの管理対象が所定の状態になった場合は、それらの管理対象を識別する必要がない）事を前提とする。
乗法による「リダクション」でコード化された個別識別子から計算された集団識別子からは、例えば各個別識別子による除法により、その個別識別子が乗法の因子として含まれているか否かを判定することができる。例えば、個別識別子を「互いに素な整数」ないし「全て異なる素数」を選んでおく事で、集団識別子から個別識別子を乗法の因子として取り出すことが可能となる。
個別識別子の割当てについては、第１の実施形態で図９（ｂ）、図１２（ｂ）、図８の（ａ）、（ｂ）、（ｃ）、（ｄ）を用いて説明した場合と同様である。
まず、分かりやすい例として、次の条件を満たすような整数を個別識別子として割り当てる場合を考察する（より一般的な割当て方法については後述する）。
「異なる管理対象に対応する整数は、共通の素因数を持たない。」
この条件は、次のように言い換える事もできる。
「異なる管理対象に対応する整数は、互いに素である。」
例えば、異なる管理対象に異なる素数を割り当てれば、上記の条件は満たされる。
ここで、所定の状態にある管理対象には個別識別子を対応させ、そうでない管理対象に1を対応させておいて、集団識別子は乗法によるリダクション４０４で与える。なお、格納用の領域は任意の個別識別子k 個以下の積についてはオーバーフローしない大きさにする。例えば、大きい順にk個の個別識別子を取り、それらの積を格納可能な大きさにする。
「個別識別子が共通の素因数を持たない」という条件は、集団識別子となった積でオーバーフローが起きていない場合に、「ある管理対象の所定の事象を通知した」事が「管理対象の個別識別子が集団識別子を割り切る」事で判定可能である事を保証する。
このように、分解能が上限k で制限されている場合、k 個より多くの識別子に対する演算がオーバーフローする可能性を許容して、k 個以下での演算結果からは入力となった識別子を復元できる演算、例えば整数の乗法によるリダクションや整数あるいは浮動小数点数の加算を利用する。なお「オーバーフロー」は、通常の計算での発生時は計算手順の誤りを示す場合が多いが、本実施形態では、「複数の管理対象の状態を一括して受け取る情報通知経路」の一つとして、「オーバーフロー」を積極的に活用していることになる。
本実施形態は、分解能に関する制約条件がある（完全である必要がない）事を利用して、同じ大きさの領域で、第１から第４の実施形態の場合に比べて、多くの管理対象に対応する（あるいは同数の管理対象に対して、より小さい領域で対応する）。
例えば、k = 2 、管理対象数が54 として、各管理対象に小さい順に素数を対応させた場合、53番目の素数は241,54番目の素数は251 で、241*251<(256*256)-1=2^16-1（「＾」は冪乗を表す）に注意すると、格納用領域は、16ビットで十分である。k=1とすると、16 bit領域で2^16-1より小さい素数の個数=6542個の管理対象に対応できる。
第１から第３の実施形態では、16bitで対応可能な管理対象は16個である。16<54<6542であるのは、kが小さくなるほど「複数の対象についての情報の、より少ない一部」しか送信する必要がないためである。例えば「2個以上の管理対象が所定の状態にある」事と「1個だけが所定の状態にある」事を区別する必要もないとして、「分解能がk=1」よりも条件を緩和すると、さらに多くの管理対象に対応できる事になる。例えば16 bit領域に格納できる0以外の任意の整数を個別識別子として、所定の状態にある管理対象は個別識別子、そうでない管理対象には0（ゼロ）を対応させて「最大値」でのリダクションを実行する事で、16bit領域で2^16-1=65535個の管理対象に対応できる。
図３０は、第５の実施形態における送信側ノードにおける識別子集約機構４０１（図４）の処理の例を示すフローチャートである。図３０は、第１の実施形態に係る図５のフローチャートにおいて、リダクション４０４の演算が加法から乗法に置き換えられたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１のCPU７０１−１または中継ノードとして機能する受信・中継ノード７０２のCPU７０２−１が実行する。入力パラメタ１または２等の作業領域は、送信起点ノード７０１のメモリ７０１−２または受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、自ノードが通信の起点ノードであるか否かが判定される（ステップＳ３００１）。
ステップＳ３００１の判定がＮＯであるならば、受信済みの値を格納する入力パラメタ１に、受信済みの値（集団識別子）が格納される（ステップＳ３００２）。
ステップＳ３００１の判定がＹＥＳならば、受信済みの値は無いため、入力パラメタ１に、乗法演算の単位元の値１が格納される（ステップＳ３００３）。自ノードが通信の起点ノード（図７の送信起点ノード７０１）であって、受信済みの値がなければ、入力パラメタ１に単位元が格納されることにより、入力パラメタ１がリダクション４０４の演算に影響を与えないようにされる。
次に、自ノードが管理する管理対象において通知すべき条件が成立したか否かが判定される（ステップＳ３００４）。
ステップＳ３００４の判定がＹＥＳならば、自ノードの状態を格納する入力パラメタ２に、自ノードにおける管理対象（または自ノードそのもの）に対応する個別識別子が格納される（ステップＳ３００５）。
ステップＳ３００４の判定がＮＯならば、入力パラメタ２に、単位元の値１が格納される（ステップＳ３００６）。自ノードが管理する管理対象において通知すべき条件が成立していなければ、入力パラメタ２に単位元が格納されることにより、入力パラメタ２がリダクション４０４の演算に影響を与えないようにされる。
その後、リダクション４０４に使用する乗法演算が、入力パラメタ１および入力パラメタ２に対して実行される（ステップＳ３００７）。
最後に、ステップＳ３００７での演算結果が、次の転送先への送信内容である集団識別子とされて出力される（ステップＳ３７０８）。その後、図３０のフローチャートで例示される送信側ノードにおける識別子集約機構４０１の処理が終了する。
図３１は、第５の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の処理の例を示すフローチャートである。図３１は、第１の実施形態に係る図６のフローチャートにおいて、リダクション４０４の演算が加法から乗法に置き換えられたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子分析機構４０２の処理が開始されると、受信側ノードとして機能する図７の受信・中継ノード７０２のCPU７０２−１が実行する。また、作業領域WやX等は、受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、ノード間のリダクション４０４における集団識別子が受信される（ステップＳ３１０１）。
次に、集団識別子においてオーバーフロー（図中「overflow」）が発生しているか否かが判定される（ステップＳ３１０２）。ステップＳ３１０２の判定がＹＥＳならば、受信処理は実質的に何も行われずに、図３１で例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
次に、ステップＳ３１０２の判定がＮＯならば、集団識別子が作業領域Wに格納される（ステップＳ３１０３）。
次に、作業領域Wが示す値がリダクション４０４の乗法演算における単位元の値１となったか否かが判定される（ステップＳ３１０４）。
ステップＳ３１０４の判定がＮＯならば、集団識別子から個別識別子が１つ特定され、その結果が作業領域Xに格納される（ステップＳ３１０５）。具体的には、集団識別子が各個別識別子で割り切れるかを判定して、割り切れた場合、その個別識別子の表す対象で所定の事象が発生したと判定して、その個別識別子を特定する。
その後、ステップＳ３１０５で作業領域Xに格納された個別識別子に対応する管理対象が処理（特定）される（ステップＳ３１０６）。この特定の具体的な手法は、第１の実施形態に係る図６のステップＳ６０５の場合と同様である。
次に、リダクション４０４に使用した乗法演算の逆演算すなわち除法演算で、ステップＳ３１０５において作業領域Wから特定され作業領域Xに格納された個別識別子が取り外される（ステップＳ３１０７）。すなわち、W/Xという除法演算が実行され、その結果が再び作業領域Wに格納される。その後、ステップＳ３１０４の処理に戻って、上述のステップＳ３１０４からステップＳ３１０７までの処理が繰り返し実行される。
作業領域Wが示す値がリダクション４０４の乗法演算における単位元の値１となった結果、ステップＳ３１０４の判定がＹＥＳになると、図３１のフローチャートで例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。集団識別子は、単位元＝１（図３０のステップＳ３００３参照）の状態から乗法演算によって個別識別子が順次追加されてゆく（図３０のステップＳ３００７）。従って、図３１のフローチャートでは、乗法の逆演算である除法演算（ステップＳ３１０７）によって個別識別子が順次取り去られてゆき、最後は単位元＝１にもどる。よって、ステップＳ３１０４の判定がＹＥＳになると、図３１のフローチャートの処理が終了する。
以上の第５の実施形態の動作において、「各ノードの識別子が互いに素」という条件と「整数論」という分野の数学でよく知られた「素因数分解の一意性」という事実により、判定の正しさが保証される。
ここまで、個別識別子は互いに素ないし全て素数としたが、より一般的な条件で個別識別子の割当てが可能な事を説明する（「互いに素」あるいは「素数」としたのは、説明を簡略にするためである）。
すなわち、任意の個別識別子a と集団識別子b に対し「a がb を割り切る」事と「a がb を計算する乗算の過程で使われた」事が互いに他の必要十分条件になればよい。後者が前者の十分条件である事は明らかなので、後者が前者の必要条件であればよい。
複数の個別識別子a1 とa2 が素因数p を共有しても、a1 がp を１つだけ、a2 がp を２つ含む（つまり、p^2 で割り切れ、p^3 では割り切れない）とし、他には素因数p を持つ個別識別子がないとする。素因数p がb に何回含まれるかによりa1 とa2 がb を計算する過程で使われたかどうかは、図３２の表のように決まるので、後者が前者の必要条件となる。
同様に、複数の個別識別子に共有されている素因数に対し、それぞれの個別識別子が素因数を含む個数が「任意の個別識別子の積の組み合わせの積を含む集団識別子から個別識別子を決定可能な数になっていれば、個別識別子が「互いに素」である必要はない。
例えば、素因数p に対して整数q の冪からなる集合Q={q^a|a=0,1,2,...}があって、「素因数p を共有する個別識別子の各々がp を含む回数」が、互いに異なるQ の要素であるならば、「集団識別子がp を含む回数」をq 進法で表したときの0 でない桁の任意の１つをa として、「素因数p をq^a回含む個別識別子」が、集団識別子の生成因子であると判定できる。
図３３から図３６は、図３１のステップＳ３１０５の個別識別子を特定する処理の、上述の理論に基づく詳細処理例を示すフローチャートである。
まず、図３３のフローチャートの処理について説明する。このフローチャートは、集団識別子からの素数冪の個別識別子成分の抽出の機能（Ａ）を実現するものである。
作業領域Wに、受信された集団識別子の成分が格納される（ステップＳ３３０１）。
次に、作業領域L に、個別識別子の成分リストが格納される（ステップＳ３３０２）。
次に、作業領域Lの先頭位置が、作業領域Xに格納される（ステップＳ３３０３）。
次に、ステップＳ３３０５で作業領域Xの値が作業領域Lの末端位置になったと判定されるまで、ステップＳ３３０７で作業領域L内の次の位置が順次作業領域Xに格納されながら、ステップＳ３３０６とＳ３３０７の処理が繰返し実行される。
すなわち、ステップＳ３３０６では、作業領域L内の作業領域Xが示す位置の個別識別子の成分が、作業領域Qに格納される。
そして、ステップＳ３３０７では、作業領域Qの値が作業領域Wの値を割り切るか否かが判定される。
ステップＳ３３０７の判定がＹＥＳであれば、処理を終了する。
ステップＳ３３０７の判定がＮＯであれば、ステップＳ３３０８で作業領域Xが示す作業領域L内の位置が更新されて、ステップＳ３３０５の処理に戻る。
以上の繰返し動作の結果、作業領域Xの値が作業領域Lの末端位置になりステップＳ３３０５の判定がＹＥＳとなると、処理を終了する。
上記フローチャートの処理において、作業領域Lのリストの探索結果は作業領域Qの値で区別できる。作業領域Qの値が０（ゼロ）でないということは、個別識別子が作業領域Lのリスト内で見つかったということを示している。
次に、図３４のフローチャートの処理について説明する。このフローチャートは、集団識別子からの素数冪の個別識別子成分の抽出の機能（Ｂ）を実現するものである。
作業領域Wに、受信された集団識別子の成分が格納される（ステップＳ３４０１）。
次に、作業領域pに、作業領域Wの素因数の１つが格納される（ステップＳ３４０２）。
次に、作業領域pの値が格納される（ステップS３４０３）。
次に、作業領域fに、値１が格納される（ステップＳ３４０４）。
次に、作業領域Wの値を作業領域pの値で除算した結果が、作業領域Vに格納される（ステップＳ３４０５）。
次に、ステップＳ３４０６で作業領域pの値が作業領域Vの値を割り切らなくなったと判定されるまで、ステップS３４０７からＳ３４０９の処理が繰り返し実行される。
すなわち、作業領域pの値が作業領域Vの値を割り切った結果ステップＳ３４０６の判定がＹＥＳになると、ステップＳ３４０７で、作業領域Vの値を作業領域pの値で除算した結果が、作業領域Vに格納される。
次に、ステップＳ３４０８で、作業領域pの値に作業領域ｑの値を乗算した結果が作業領域ｑに格納される。この作業領域qの値は、作業領域Wに含まれる作業領域pの素数についての最大冪因子である。つまり、W/qが素数pの因子を含まず、fを指数として、q=p^fである。
そして、ステップＳ３４０９で、作業領域fの値が+1される。
以上の繰返し処理の結果、作業領域pの値が作業領域Vの値を割り切らなくなった結果ステップＳ３４０７の判定がＮＯになると、処理を終了する。
次に、図３５のフローチャートの処理について説明する。このフローチャートは、図３４のフローチャートに引き続いて実行され、集団識別子からの素数冪の個別識別子成分の抽出の機能（Ｃ）を実現するものである。
まず、作業領域gに図３４における作業領域fの値が格納される（ステップＳ３５０１）。
次に、個別識別子になる素数冪因子の値が作業領域Xに格納される（ステップＳ３５０２）。
次に、作業領域gの値であるか否かが判定される（ステップＳ３５０３）。
ステップＳ３５０３の判定がＹＥＳであれば、ステップＳ３５０２に戻って、個別識別子になる次の素数冪因子の値が作業領域Xに格納される。
ステップＳ３５０３の判定がＮＯになると、処理を終了する。
上述の図３５のフローチャートで示される処理の代わりに、LZC(g)（gへのleading zero count)をdとして MSBから数えた(d+1) ビット目を0にする手順が実行されてもよい。
次に、図３６のフローチャートの処理について説明する。このフローチャートは、集団識別子からの素数冪の個別識別子成分の抽出の機能（Ｄ）を実現するものである。
まず、TZC(g)の値が作業領域cに格納される（ステップＳ３６０１）。ここで、TZC(g)は作業領域gの値へのtrailing zero count（g内でLSB(Least Siginificant Bit)から数えた)連続してbitが0の数）である。作業領域gは、図３５のフローチャートでセットされたものである。TZC(g)の代わりに、LZC(g)（leading zero cunt）が用いられてもよい。
次に、p^(c+1)（素因数pを作業領域cの値に+1して得られる値で冪乗した値）が作業領域Xに格納される（ステップＳ３６０２）。
そして、作業領域gにおいて、LSBから数えて(c+1)ビット目の値が0（ゼロ）に変更される（ステップＳ３６０３）。
ここで述べた一般化された個別識別子の取り方の中で、領域の大きさを固定にして分解能kを大きくする際は、上記q を2 とした場合の｛全ての素数ないし素数の冪で指数が２の冪である数｝、記号で書けば、{p^(2^a)|pは素数、a=0,1,2,...}を個別識別子の成分の集合に使う事が有利である。第１の実施形態の説明した図９（ｂ）および図１５の(C)、(D)は、この場合を例示している。
一方、分解能k を固定し、k より多くの管理対象が所定の状態になった場合、なるべく早くオーバーフローが起こるようにするには「k 個までの積ではオーバーフローしない範囲の数」の中から、素数の冪以外の数も含めて大きい順に、必要な個数、個別識別子の集合に含めていく事が有利である。
以上のようにして、第５の実施形態によれば、必要な分解能k が比較的小さい場合、第１から第４の実施形態に比べ、メモリ領域を削減することが可能となる。
＜第６の実施形態＞
次に、第６の実施形態について説明する。
本実施形態は、第５の実施形態の発展形である。本実施形態での個別識別子の割当ては、第１の実施形態の説明において示した図１５の（ｅ）および（ｆ）に従う。
本実施形態では、第５の実施形態と同一のシステム構成で各ノードに複数の整数からなる順序付けられた組を対応させる。i,j をノード番号とし各ノードにm 個の数の組を対応させる。
すなわち、以下に示されるような、m 個の整数を要素とするベクトルを、管理対象の個別識別子とする。
Z(i) = (zi1, zi2, ..., zim)
Z(j) = (zj1, zj2, ..., zjm)
i≠j ならば、m 個の組の中で、少なくとも一つの場所の数が異なるとする。すなわち、「∨」で、論理式としてのor を表すと、
i ≠j ⇔ (zi1 ≠ zj1 ∨ zi1 ≠ zj1 ∨ ... ∨ zim ≠ zjm)
である。
ここで、ベクトルの各成分毎に、使われる整数の集合は同じであっても異なっていてもよいが、それぞれの集合毎に、異なる要素は互いに素であるとする。すなわち、
S1 = ｛ベクトルの第1成分用の整数の集合｝
...
Sm = ｛ベクトルの第m成分用の整数の集合｝
とする、S1, ..., Sm は、全て異なる２要素が互いに素であるような整数の集合である。
全ての成分が1 の場合を除いて、成分には1 が現れてもよい。
以下の説明において、一般にx 個の互いに素な整数の集合に現れる素因数の数は、x 以上であり、素因数の数がx 個になるのは、x 個の数全てが素数である場合に限る。
また、第５および第６の実施形態において、ノードの識別のための因数分解は、事前に定めた数の集合の要素により、reduction の結果が割れるかを順次試行していく処理に他ならない。
本実施形態は単一の数を使って管理対象を識別する第５の実施形態に比べ、使用するフィールド数は増加するが同一管理対象数のシステムに対して、比較的少数かつ大きさも小さい数からなる集合でノードの識別が可能になる。よって、各要素の因数分解を高速に行う事が可能になり、ノードの特定の処理時間が第５の実施形態に比べて、短縮される。
第５の実施形態で使用する数の集合S の要素数はノード数N 以上である必要があるが、本実施形態で使用する集合S1 ... Sm の要素数はN/m を越える最小の自然数でよい。どちらの実施形態でも、必要な除算の最大回数および平均回数は等しい。なぜならば、本実施形態では、各成分の因数分解をm 回繰り返すことになるが、各成分に必要な除算回数は1/m になるためである。
なお、ここまでの個別識別子の整数を互いに素としているが、第５の実施形態と同様「指数自体が素数冪であるような素数冪」の数を素因数に含むような、より一般的な割当て方法が可能である（ここまで「互いに素」としたのは、説明を簡略にするためである）。
ここで、これから後に説明他の実施形態と共通する基本原理について言及しておく。
第５および第６の実施形態は共に、「自然数についての素因数分解の一意性」という共通の原理に基づく。相違点は、「各ノードに割り当てる識別子が単一の数か、複数の数の組か」のみである。
0 と負の数を含めた（通常の意味の）整数全体についても、0 を分解の対象から除外して、「+1,-1は素因数と見なさない（言い換えれば、負の数の積での符号の各因数への付き方の違いでは異なる分解と見なさない）」事に注意すると、素因数分解の一意性が成立する。
一般的な集合で定義された「乗算」で、整数の場合と同様な意味での「一意的」な「素因数分解」が可能な場合、その集合での「素数」に関する条件を第５および第６の実施形態と同様に設定して、識別子をコード化する事ができる。（一般に、1や-1のような、「逆数も整数である数」は「素因数」には含めない）。
整数の場合と同様な意味で「一意的」な「素因数分解」が可能な集合の例としては、任意の「体」の要素を係数とする多項式のなす集合がある。多項式の集合において「既約多項式」が「素数」に相当する。
ここで、「体」とは、四則演算が定義され、加法、乗法共に交換法則と結合法則を満たし、0, 1 を含み、0 以外の全要素に対し「掛けて1 になる数」である「逆元」が存在する集合を指す。
「体」としては「有理数全体」、「実数全体」、あるいは「複素数全体」、有限体GF(q)（ただしq は集合としての要素数）などがある。なお、「有理数全体」、「実数全体」、あるいは「複素数全体」の集合が「体」である事を強調する際「有理数体」、「実数体」、あるいは「複素数体」と呼ぶ。
「素因数分解の一意性」の成り立つ乗法を持つ集合は、整数や「体」係数の多項式以外にもある。そのような集合の一種である「代数的整数」を利用した実施形態については、第７の実施形態の説明で後述する。
図３７は、上述の理論に基づく、第６の実施形態における送信側ノードにおける識別子集約機構４０１（図４）の処理の例を示すフローチャートである。このフローチャートにおける処理の基本的な考え方は、前述した図５（第１の実施形態）、図１７（第２の実施形態）、図３０（第５の実施形態）などと同様である。図３７は、第１の実施形態に係る図５のフローチャートにおいて、リダクション４０４の演算が加法から乗法に置き換えられ、かつ上述の理論に基づいて個別識別子および集団識別子がベクトル化されたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１のCPU７０１−１または中継ノードとして機能する受信・中継ノード７０２のCPU７０２−１が実行する。入力ベクトル１または２等の作業領域は、送信起点ノード７０１のメモリ７０１−２または受信・中継ノード７０２のメモリ７０２−２に記憶される。
本実施例での識別子は整数の順序付けられた集合である。ここでは、「順序付けられた集合」を「ベクトル」と呼び、「順序つけられた集合」の要素である整数を成分と呼ぶ。識別子がベクトルである事を強調する際は、「個別識別子ベクトル」、「集団識別子ベクトル」、さらに両者を合わせ「識別子ベクトル」と呼ぶ。識別子ベクトル間の演算は、対応する位置の成分間の演算で定める。
図３７において、まず、自ノードが通信の起点ノードであるか否かが判定される（ステップＳ３７０１）。
ステップＳ３７０１の判定がＮＯであるならば、受信済みの値を格納する入力ベクトル１に、受信済みの集団識別子ベクトルが格納される（ステップＳ３７０２）。
ステップＳ３７０１の判定がＹＥＳならば、受信済みの値は無いため、入力ベクトル１の全成分に、乗法演算の単位元の値１が格納される（ステップＳ３７０３）。
次に、自ノードが管理する管理対象において通知すべき条件が成立したか否かが判定される（ステップＳ３７０４）。
ステップＳ３７０４の判定がＹＥＳならば、自ノードの状態を格納する入力ベクトル２に、自ノードにおける管理対象（または自ノードそのもの）に対応する個別識別子ベクトルが格納される（ステップＳ３７０５）。
ステップＳ３７０４の判定がＮＯならば、入力ベクトル２の全成分に、単位元の値１が格納される（ステップＳ３７０６）。
その後、入力ベクトル１，２の全成分の間で、リダクション４０４に使用する乗法演算が実行される（ステップＳ３７０７）。
最後に、ステップＳ３７０７での演算結果が、次の転送先への送信内容である集団識別子ベクトルとされて出力される（ステップＳ３７０８）。その後、図３７のフローチャートで例示される送信側ノードにおける識別子集約機構４０１の処理が終了する。
図３８は、上述の理論に基づく、第６の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の処理の例を示すフローチャートである。このフローチャートにおける処理の基本的な考え方は、前述した図６（第１の実施形態）、図１８（第２の実施形態）、図３１（第５の実施形態）などと同様である。図３８は、第１の実施形態に係る図５のフローチャートにおいて、リダクション４０４の演算が加法から乗法に置き換えられ、かつ上述の理論に基づいて個別識別子および集団識別子がベクトル化されたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子分析機構４０２の処理が開始されると、受信側ノードとして機能する図７の受信・中継ノード７０２のCPU７０２−１が実行する。また、作業領域ベクトルWやX等は、受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、ノード間のリダクション４０４における集団識別子ベクトルが受信される（ステップＳ３８０１）。
次に、集団識別子ベクトルにおいてオーバーフロー（図中「overflow」）が発生しているか否かが判定される（ステップＳ３８０２）。ステップＳ３８０２の判定がＹＥＳならば、受信処理は実質的に何も行われずに、図３８で例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
次に、ステップＳ３８０２の判定がＮＯならば、集団識別子ベクトルが作業領域ベクトルWに格納される（ステップＳ３８０３）。
次に、作業領域ベクトルWの全成分値がリダクション４０４の乗法演算における単位元の値１となったか否かが判定される（ステップＳ３８０４）。
ステップＳ３８０４の判定がＮＯならば、集団識別子ベクトルから個別識別子ベクトルが１つ特定され、その結果が作業領域ベクトルXに格納される（ステップＳ３８０５）。
その後、ステップＳ３８０５で作業領域ベクトルXに格納された個別識別子ベクトルに対応する管理対象が処理（特定）される（ステップＳ３８０６）。
次に、リダクション４０４に使用した乗法演算の逆演算すなわち除法演算が作業領域ベクトルWと作業領域ベクトルXの各成分に適用され、ステップＳ３８０５において作業領域ベクトルWから特定され作業領域ベクトルXに格納された個別識別子が取り外される（ステップＳ３８０７）。その後、ステップＳ３８０４の処理に戻って、上述のステップＳ３８０４からステップＳ３８０７までの処理が繰り返し実行される。
ステップＳ３８０４の判定がＹＥＳになると、図３８のフローチャートで例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
一般に、除算を実行するには被除数と除数をメモリからfetch する必要があり、実施形態５では、成分の集合を全て同じにすれば、メモリからfetch すべき除数の数が1/m になり、N >> m （N がm に比べて十分大きい）となる大規模システムでは除数がキャッシュヒットする回数が多くなる利益の方が、被除数が1 個からm 個になる事により、キャッシュミス回数が多くなる損失を上回る。よって、N >> m であれば、本実施形態の方が計算処理時間の面で第５の実施形態よりも有利である。
また、N が十分大きい場合、使用メモリ量に関しても、本実施形態は不利にならない。なぜならば、「x 以下の素数の数」を表す関数をπ(x) と書くと、整数論で「素数定理」と呼ばれる事実によりπ(x) と(x/log(x)) の比はx→∞のとき1 に収束する事が知られているからである。
つまり、「素数の密度」（π(x) /x ）が対数関数の逆数1/log(x) 程度になる（ここでの対数は自然対数）。すなわち、ノード数が多くなって成分の素因数として使える素数を追加する場合、平均的には指数関数的に大きくする必要がある。このため、オーバーフローせずに格納するために必要なメモリ領域のビット数は、本実施形態で比較的小さな素数ないし素数の冪の複数の組による個別識別子の集合を使う方が、単一の素数ないし素数の冪による第５の実施形態に比べて小さくなる場合が増えていく。
＜第７の実施形態＞
次に、第７の実施形態について説明する。
整数の乗法以外でも、ある集合内の演算が「複数要素の演算結果から元の要素を復元できる」という意味で整数の乗法と共通する性質を持つなら、その演算を図４の機能の実現に利用することができる。特に、「素因数分解の一意性」が成立する乗法を持つ集合を使って、通常の整数での乗法を使用する場合と、ほぼ同じ方法で図４の機能の各演算を実施できる。
第７の実施形態での個別識別子の割当ては、第１の実施形態の説明において示した図１５の（ｇ）および（ｈ）に従う。
任意の「体」について、その「体」を「係数体」とする「ベクトル空間」が、要素である「ベクトル」の間に交換法則、結合法則を満たす加法と、指定した体の要素をスカラーとする「スカラー倍」の演算を持つ集合として定義される。
有理数体を含む体で、ベクトル空間として有限次元である体K は「（有限次元）代数体」(algebraic number field) 呼ばれる（以下では「有限次元」を省略する）。K に含まれる「代数的整数」全体をO_K と書く。（ここで「代数的整数」とは最高次の係数が１の整数係数の既約多項式をf(x) として、方程式f(x) = 0 の根になる複素数の事を指す）。
O_K は加法、減法、乗法について閉じている集合になる事が知られているので、O_K にの中で、「素数」の役割を果たす数をp|ab → p|a ∨ p|b （ここで「x | y」はx はyを割り切る事、「→」は「ならば」、「∨」は「または」の意味である）で定義する。
この定義により、O_K での「素因数分解の一意性」が成り立つ条件や実例が、「代数的整数論」と呼ばれる数学の一分野で、良く知られている。よって「素因数分解の一意性」が成り立つ任意のO_K を使って、第５または第６の実施形態と類似した方法で、図４の機能の各演算を実施できる。
その際のポイントは、代数体K が有理数体上有限次元である。従って、その次元をn として、K からn 個の要素k1,k2,...,knを適切に選んで、任意のK の要素を、有理数係数の線形結合{c1*k1+c2*k2+...cn*kn|ciは有理数、ki∈K (i=1,2,...n)}として表せるので格納用の領域を固定長にできる事である。さらに、O_K の要素係数が全て整数になるk1,...,knを選んでn 個の整数の組とO_K の要素を１対１対応させる。代数体K は有理数体に１つの代数的整数α（および、その冪）を付け加えて得られる事が知られている。従って、このようなk1,...,knは、「最高次の係数が１の整数係数の既約多項式f(x)」を１つ取り、f(α)=0を満たすをαを使って、k1=1,k2=α,...,kn=α^(n-1)として定めればよい。
ここで、k1,...,knは（有理数体上のベクトル空間として）、K の基底である。なお、n 個のK の要素が基底である事の必要十分条件は、有理数体上のベクトル空間の要素として「線形独立」である事なので、{k1,...,kn}の選び方は１通りではない。特に断らなければ、K に含まれる代数的整数αにより、{1,α,...,α^(n-1)}としておく。
以下では、n=2 であるような例を２つ示す。一般のn についても原理は同じである。
まず、虚数単位i はx^2+1=0の根なので、代数的整数である。有理数体に虚数単位i を追加して得られる体Q[i]は、有理数体上、２次元のベクトル空間となる。
集合Z[i]=｛実部と虚部の係数が共に整数である複素数｝を「ガウス整数」という。ガウス整数は、K=Q[i]に対する上述したO_K の例である。ガウス整数について「素因数分解の一意性」が成立する事が知られている。
例えば、「ガウス整数」中では、2=(1+i)×(1-i)のように2 は２つのガウス整数の積として表されるので、2 は「ガウス整数としての素数」ではない。しかし、1+i,1-iは（実数部、虚数部の絶対値を考えれば明らかなように）「ガウス整数の中での「素数」」になる。そして、2 を「ガウス整数の中での素数」に分解する方法は、この２つのガウス整数の積への分解に限られる。
ガウス整数を実数部と虚数部に分けて２つの通常の整数用の領域に格納し、各管理対象の個別識別子を、「ガウス整数の中での「素数」」についての条件で第５、第６の実施形態での素数についての条件を置き換えて設定する。そうすると、「ガウス整数としての積（複素数としての積）」を２項演算とするリダクションにより、集団識別子を求める事ができる。なぜならば、２つのガウス整数A,Bに対し、あるガウス整数C を取ってA=B×Cとできるか否かは、B の複素数としての逆数Dを取ってD×Aの係数が実部、虚部ともに整数であるか否かで判定できるからである。前述したガウス整数内での素因数分解の一意性により、どの個別識別子の積で生成されたかの判定も、第５，第６の実施形態と同様に実行できる。
なお、ガウス整数同士の間では、商と余りを生成する除法が定義され、この除法での余りが0 か否かで、集団識別子（の成分）が個別識別子（の成分）で割り切れるか否かで判定する事も可能である事が知られている。
次に、ω=(-1+i√3)/2 (i は虚数単位)とおくと、ωはx^2+x+1=0 の根なので代数的整数である。ωを有理数体に追加した体Q(ω) は、有理数体上２次元のベクトル空間になる。なぜならば、加法と乗法について Q[ω]={A+Bω|A,Bは有理数}が閉じている事は明らかなので、除法についても閉じていれば、Q(ω)=Q[ω]となるので有理数体上２次元である事が分かるからである。特に逆数について閉じていればよい。a+bω≠0である任意の２つの有理数a,b に対し、1/(a+bω)=(a+bω^2)/(a^2-ab+b^2)=((a-b)-ω)/(a^2-ab+b^2)∈ Q[ω]と確認できる。
集合Z[ω]={a+bω|a,bは通常の整数｝を「アイゼンシュタイン整数」という。
(a + bω)*(c + dω) = ac + (bc+ad)ω + bdω^2
にω^2=-1-ωを代入すると、以下のように計算できる。
(a + bω)*(c + dω) = (ac-bd) + (bc+ad-bd)ω
従って、「アイゼンシュタイン整数」同士の積は「２つの整数の組」の間の演算として表せるので、２つの通常の整数用の領域によって「アイゼンシュタイン整数」１つを保持しておき、「アイゼンシュタイン整数」を個別識別子とする事ができる。
２つのアイゼンシュタイン整数A,B に対し、あるアイゼンシュタイン整数C が存在してA=B×CであるかはB の複素数での逆数D に対しD × A がアイゼンシュタイン整数であるかにより判定される。下記等式から任意のアイゼンシュタイン整数B の逆数D に対し、あるアイゼンシュタイン整数E と通常の整数Z の組によりD=(E/Z)と表せるので、A=B×Cと書けるか否かはE×Aの係数がZ で割り切れるか否かにより判定できる。
(a + bω)*(a + bω^2) = a^2 -ab + b^2
∴1/(a + bω) = (a + bω^2)/(a^2 -ab + b^2 )
「アイゼンシュタイン整数」の中でも「素因数分解の一意性」が成立する。
また、「アイゼンシュタイン整数」の中で商と余りを生成する除法が定義され、この除法での余りが0 か否かでも「割り切れるか否か」の判定ができる事が知られている。
以上から「アイゼンシュタイン整数」（ないし、その組）を個別識別子とし、積によるリダクションで集団識別子を求めることにより、図４の演算機能を実現する事ができる。
一般のn 次代数体でも、最高次の係数が1のn 次既約多項式f(x) についてf(x)=0の根をαとして、O_K の要素を{1,α,α^2,...,α^(n-1)}の整数係数の線形結合として表しておく。これにより、O_K の要素同士の積は、f(α)=0によりα^n をαのn 次より小さい冪の線形結合で置き換える事で、「n 個の整数の組」の間の演算として表現できる事が分かる。
任意のn 次代数体K と、その中の代数的整数の集合O_K に対し、下記(a),(b)を満たす（「（γの）ノルム」と呼ばれる）関数N(γ)が存在する事が知られている。
(a) K の任意の要素に対して、(1),(2)が成り立つ。
(1) K の任意の要素γに対し、N(γ)は有理数となる。
(2) K の任意の２要素γ1，γ2に対し、N(γ1×γ2)=N(γ1)×N(γ2)
(b) O_K の任意の要素βに対しては、(a)に加えて、次の(1),(2)も成り立つ。
(1) N(β)は整数となる。
(2) βの逆数δは、あるO_K の要素εによりδ = (ε / N(β)) と表される。
例えば、ガウス整数a+biに対してはN(a+bi)=a^2+b^2、アイゼンシュタイン整数a+bωに対しては、N(a+bω)=a^2-ab+b^2である。
よって、一般のn 次代数体K についても、その中の代数的整数全体O_K に対して素因数分解の一意性が成立すれば、O_K の要素（ないし、その組）を個別識別子として積によるリダクションで集団識別子を求めて、図４の演算機能を実現する事ができる。ここで、ノルムの性質(b)-(2)により「個別識別子が集団識別子を割り切る」事を判定する。素因数分解の一意性により、個別識別子に含まれる素因数の性質を第５，第６の実施形態と同様に選べば、「割り切れる」事によって、「その個別識別子が集団識別子を計算する過程で使われた」事が保証される。
ただし、一般のn 次代数体K の中の代数的整数O_K について素因数分解の一意性は成立するとは限らない。また、O_K の中では、商と余りを生成する除法を定義して、その除法の余りが0 である事によって割り切れるか否かを判定できるとは限らない。
しかし、代数的整数O_K について素因数分解の一意性が成立するための必要十分条件は、よく知られている。「素因数分解の一意性」が成立する任意のO_K から、第５，第６の実施形態と同様の「素数」についての条件により、個別識別子の集合を定める事ができる。
図３９から図４１は、第７の実施形態の処理の例を示すフローチャートである。
第５または第６の実施形態において図４の識別子集約機構４０１のリダクション４０４を実現するリダクション演算は、図３０のステップＳ３００７または図３７のステップＳ３７０７）で実行されている。これらのリダクション演算では、個別識別子が「普通の整数としての素数か素数ベキ」である。これに対して、本実施形態における個別識別子は、有理数体でない代数体が１つ固定され、その代数体の中での「素元」（代数的整数としての素数）になっている。具体的には、ガウス整数としての素数などが用いられる。これらの関係より、第５の実施形態における「普通の整数の積、商」であるところが、本実施形態における「代数的整数の積、商」になる。これらを踏まえて、本実施形態における図９は、例えば第５の実施形態における図３０のステップＳ３００７または第６の実施形態における図３７のステップＳ３７０７の処理を置き換えるものである。
また、第５または第６の実施形態において図４の識別子分析機構４０２の「集団識別子から生成因子の個別識別子を復元する処理」は、図３１のステップＳ３１０７または図３８のステップＳ３８０７で実行されている。本実施形態における図４０は、これらの処理を置き換えるものである。
さらに、本実施形態における図４１は、図４０の処理を、別の形態で一般化したフローチャートである。
まず、図３９のフローチャートの処理の前提として、代数体K の基底が以下の性質を満たす代数的整数αにより、{1,α,α^2,…,α^(n-1)}として与えられている。
f(x)=x^n+a_(n-1)×x^(n-1)+....a_k*x×k+...+a_0
f（α)=0
そして、代数的整数β，γを、αの多項式で次式のように表しておく。
g(x)=b_m^x^m+b_(m-1)*x^(m-1)+....b_1*x+b_0
β=g(α)
h(x)=c_l^x^l+b_(l-1)*x^(l-1)+....c_1*x+c_0
γ=h(α)
以上のようにして定義される代数的整数β，γを用いて、図３９のフローチャートが動作する。
まず、代数的整数βの係数ベクトルが作業領域Bに格納される（ステップＳ３９０１）。
次に、代数的整数γの係数ベクトルが作業領域Cに格納される（ステップＳ３９０２）。
さらに、代数的整数１，２の積の係数ベクトルが演算され、その係数ベクトルが作業領域Dに格納される（ステップＳ３９０３）。
以上の図３９のフローチャートにより、例えば第５の実施形態における図３０のステップＳ３００７または第６の実施形態における図３７のステップＳ３７０７の処理が置き換えられる。
次に、図４０のフローチャートの処理について説明する。
まず、被除数の係数ベクトルが作業領域bに格納される（ステップＳ４００１）。次に、除数の係数ベクトルが作業領域cに格納される（ステップＳ４００２）。
さらに、dの逆数がe/N(c)の形で表される(eはKの代数的整数、N(c)はcのノルム)（ステップＳ４００３）。
次に、e×b の係数ベクトルが作業領域fに格納される（ステップＳ４００４）。
そして、作業領域fのベクトル成分がN(c)の各成分で割り切れるか否かが判定される（ステップＳ４００５）。
以上の図４０のフローチャートにより、例えば第５の実施形態における図３１のステップＳ３１０７または図３８のステップＳ３８０７の処理が置き換えられる。
次に、図４１のフローチャートの処理について説明する。このフローチャートでは、iの値が、ステップＳ４１０１で０（ゼロ）にリセットされた後、ステップＳ４１１０で+1ずつインクリメントされながら、ステップＳ４１０３でmに達したと判断されるまで、０からmまで変化させられる。また、iの１つの値ごとに、jの値が、ステップＳ４１０２で０にリセットされた後、ステップＳ４１０９で+1ずつインクリメントされながら、ステップＳ４１０４でlに達したと判断されるまで、０からlまで変化させられる。
このようにして変化するiとjを用いて、ステップＳ４１０５でi+jの値がn以上であると判定されると、ステップＳ４１０６で、代数的整数αに対してi+jの値を冪乗とする演算結果α^(i+j)の係数が作業領域dに格納される。
そして、ステップＳ４１０７で、α^(i+j)の中のα^nがf(α)=0の関係式でαのn-1次以下の冪の項で置き換えられる。
その後、ステップＳ４１０８で、α^(i+j)の項からの係数が乗算結果係数格納用領域Dの各項に加えられる。
以上の処理がiとjがインクリメントされながら繰返し実行される。
コード化された識別子に対する演算を効率的に行うためには、識別子をCPU やノード間演算装置がサポートする、特定の固定長の領域、ないし、それらの領域の組に格納しておく必要がある。「ガウス整数」や「アイゼンシュタイン整数」などの代数的整数の中での「素数」（素元）は、係数の大きさが一定の範囲で比較すると通常の素数より多数ある。従って、本実施形態により、代数的整数を使用すると、同じ大きさの領域を使って分解能k を大きくするような個別識別子の割当てが比較的容易になる。
さらに、「整数用領域を２つ使って２進数での桁数が２倍の整数を表わす」方法と比較すると、「ガウス整数」や「アイゼンシュタイン整数」（のような有理数体上２次元の代数体の中の代数的整数）の集合では、比較的絶対値が小さい数の範囲内で両方の領域が有効に使える。２つの整数領域で桁数が２倍の整数を表す場合、上位桁を表すために使う領域は片方の領域だけでは表せない大きさの整数を使わない限り個別識別子の格納に使用されない。このため、「ガウス整数」や「アイゼンシュタイン整数」を個別識別子とする方が、同じ程度の計算量を前提としたメモリ効率の比較で、桁数２倍の領域で通常の整数を個別識別子とするより有利である。
同様の事が、有理数体上n次元の代数体の中の代数的整数をn個の整数用領域を使って表す方法と、「整数用領域をn 個使って２進数での桁数がn 倍の整数を表わす」方法と比較する場合にも成り立つ。
＜第８の実施形態＞
次に、第８の実施形態について説明する。
乗法を演算とするリダクションの利用のために図４の識別子のコード化体系４０３があれば、各識別子の対数を使って乗法を加法に変換する事で、加法をサポートするノード間演算装置を使って実現する事、およびそれによる高速化が可能である。ただし、個別識別子として利用する数の選定に際して、以下のような注意、工夫が必要になる。以下に、その詳細について説明する。
「最も近い整数を選んで因数分解する場合に浮動小数点演算での誤差の累積による誤判定がない事を、事前に検証するか、精度保証付き演算などで保証する。対数を取る際にデータは浮動小数点形式になるので、その後の計算では整数での計算における「等しい」事の判定は、「誤差が事前に定めた値（例えば「machine epsilon」と呼ばれる値）より小さい」事で置き換える必要がある。データを伝送上の都合に従って、そのまま、ないし固定小数点形式（整数形式）に変換して和を取り、その結果を浮動小数点形式に戻したものを指数関数への入力とする事で、対数を取る前の積を復元する、という一連の処理の各過程で誤差が累積する。
浮動小数点形式での演算での桁落ち誤差の影響を小さくするためには、元の（対数を取る前の）数を、「同じ程度の大きさ」にしておく事が有効である。この場合、個別識別子の範囲を「最大値を決めて降順に定める」方針が有利である。
本実施形態も、第５から第７の実施形態と同様に、分解能が正の整数k を上限として制限される場合に適用される。
本実施形態では個別識別子の対数を利用するが、複素数の対数関数を利用する場合の記述は、原理的に共通点が多いとは言え煩雑になるため、以下、個別識別子は通常の正の整数とする。
第５、第６の実施形態で整数の乗法で実現した機能を、本実施形態では加法により実現する。ただし、浮動小数点の加法を使用する場合と整数（固定小数点）の加法を使用する場合の両方がある。
第５の実施形態は第６の実施形態で成分の数が１の場合と見なす事ができる。一方、第６の実施形態は、第５の実施形態をベクトルの複数の成分に対して実施したと見なすことができる。本実施形態では記述を簡略化するため、以下では１つの成分について説明する。
第５，第６の実施形態と同様に、各管理対象（例えば各ノード）に対し個別識別子を割当て、集団識別子を第５，第６の実施形態の場合と同様に「整数の乗法でのリダクション結果」と定義する。ただし、本実施形態は「整数の乗法でのリダクション結果」を、対数を経由する加法でのリダクション操作を使用して求める（「積の対数」が「対数の和」である事に基づく）。
ただし、対数の底の冪である数以外の対数は整数ではないので、浮動小数点形式にする際に誤差が生じ、さらに、対数の浮動小数点数での加法を計算する際にも誤差が生ずる事を考慮すると、識別子の割当て時に工夫を要する。
集団識別子から個別識別子を求める計算手順自体は、「積の対数」が「対数の和」である事を利用する事を除き、第５、第６の実施形態と同様である。個別識別子の対数の計算を個別識別子割当時に行っておき、通知する側のノードが対数値を記憶しておく事により、情報通知時には対数計算を不要にできる。個別識別子の値の対数への変換後、あるいは、対数への変換後さらに定数倍して整数形式にした変換後の値は、「変形個別識別子」と呼んで本来の個別識別子と区別する。同様に「変形個別識別子」に対するリダクション（総和）の結果は、「変形集団識別子」と呼んで本来の集団識別子と区別する。
(a) 浮動小数点の加法を使用する場合
(1) 情報を通知する各ノードで管理対象の個別識別子の対数を取るか、予め記憶しておいた個別識別子の対数をリダクションへの入力として用意する。後者の方法では、送信側ノードで対数を計算する必要がない。情報を集約するノードが管理対象の個別識別子の対数の加法によるリダクション結果を受け取るようにリダクション操作を行う。
(2) 情報を集約するノードは対数の総和から、個別識別子の積を復元する。元データは整数なので、指数関数によって対数から復元した結果に最も近い整数を取る事で、集団識別子を求める。
(3) 集団識別子を割り切る個別識別子を求める。
(b) 整数の加法を使用する場合
(1) 情報を通知する各ノードで管理対象の個別識別子の対数を取る、あるいは予め記憶済の個別識別子の対数をリダクションへの入力として用意する。ここで「用意」とは、浮動小数点形式の個別式識別子の対数を定数倍して整数に変換するあるいは、予め定数倍して整数に変換しておいたデータ入力にする事を意味する。後者の方法では、送信側ノードが浮動小数点演算を行う必要がない。
(2) 情報を集約するノードが「管理対象の個別識別子の対数を定数倍し、整数に変換した数」の加法によるリダクション結果を受け取るようにリダクション操作を行う。ここでは、「ある桁までの固定小数点形式とした後、小数点以下の桁数m に対し2^m を掛けて、「対数の近似値を整数形式で表現する」事を「整数に変換する」と呼んでいる。
(3) 情報を集約するノードは(2) のリダクション結果を浮動小数点形式に戻し、(2) で整数形式への変換で使用した大きさ調整用の定数2^m で割って、大きさも元に戻す。
(4) 情報を集約するノードは、浮動小数点形式に戻した「個別識別子の対数の総和」から、元の個別識別子の積である集団識別子を復元する。元データは整数なので、指数関数によって復元した結果に最も近い整数を取る事により、集団識別子を求める。
(5) 集団識別子を割り切る個別識別子を求める。
本実施形態のポイントは、対数を取る操作自体、および結果を有限桁数で表現する事に伴う誤差による誤判定を排除する事にある。言い換えれば誤差の大きさを判定結果に及ぼさない程度に小さくする事が、高速な実現の鍵になる。（「多倍長計算」を使用すれば、誤差をいくらでも小さくできるが、メモリ領域の所要量や通知する側のノードを含めてメモリアクセス量が増加するため、固定長領域での演算による実現が、性能上有利である）。
「精度保証付き演算」により誤差の範囲を制限する手法もあるが、より単純な方法は予め定めておく個別識別子の集合に対し、上記(a), (b) の手順で所定の状態にある個別識別子を復元可能な事を実際に計算して確認しておく事である。この計算は、個別識別子の集合を定める際に行えばよい。例えば事前に十分多くの要素を持つ個別識別子の集合を用意しておけば、上記の精度確認計算はシステムが動作する際の性能には悪影響を及ばさない。
動的に管理対象を増やす必要があるシステムにおいても、使用可能な個別識別子のプールから切り出して使う事で、運用時に精度確認計算する事は避けられる。
確認計算は、例えば、分解能k の場合、個別識別子を大きい方からk 個とった積をU(k) として、U(k) を越えない積を与える個別識別子の組合わせ全てについて、(a), (b) の手順での誤差によって誤判定が起こらない事を確認しておけばよい。
ここで、上記の精度確認計算で誤判定となる場合が検出された場合、個別識別子の集合を取り替えるか、その組み合わせでの集団識別子の値を、正しい個別識別子の組と合わせて「例外値リスト」に格納しておき、集団識別子から個別識別子を計算する際に例外値リストを確認する処理を最初に行う事で対応する。
大きさが極端に違う浮動小数点形式の数の加算では、桁落ちにより有効数字が失われやすい事を考慮すると、浮動小数点形式の数の加算を使う場合の本実施形態では、個別識別子の大きさを、可能な範囲内で、なるべく揃える事が望ましい。
また、計算量が比較的大きい除算を行う必要がない数値の大きさで判定できる場合を多くするためには、全ての個別識別子を条件を満たす範囲で、なるべく大きく取る方が有利であるため、例えば「個別識別子になりうる数の中から大きい順に個別識別子を選ぶ」事が有効である。
例えば、用意された領域に格納できる最大の整数をz として、z のk 乗根をz^(1/k)=yとおき、y から降順に、個別識別子とする数（あるいは、個別識別子の候補としてプールしておく数）を取り出す。
一方、「分解能k より多くの個別識別子を区別する場合を多くしたい」場合は、個別識別子をなるべく小さく取る方が有利であるため、例えば「必要な個数の個別識別子を、区間の最大値から出来るだけ離す」事が有効である。
ただし、対数をとる前の整数の候補から小さい順に選ぶと、「誤差を小さくするため大きさを揃える」観点からの条件を満たしにくい。例えば、必要な個別識別子の個数から定まる区間の端点となる数（最小と最大）の桁数の差が浮動小数点ないし定数倍をかけて整数（固定小数点）に変換する際の有効数字の桁数の範囲より小さくなるように選ぶ。
誤差が大きくなる組み合わせを含む数を個別識別子として使用しない事により、例外値リストへの登録数を減らす事も可能である。さらに、受信時の個別識別子の探索処理の高速化の観点からは、例外値リストの大きさ（要素数）は、なるべく小さい方が有利である（例外値リストの大きさが結果的に0 の場合（すなわち、例外値リストが必要なくなる場合）も、論理的にはありうる）。
図４２は、上述の理論に基づく、第８の実施形態における送信側ノードにおける識別子集約機構４０１（図４）の処理の例を示すフローチャートである。このフローチャートにおける処理の基本的な考え方は、前述した図５（第１の実施形態）、図１７（第２の実施形態）、図３０（第５の実施形態）、図３７（第６の実施形態）などと同様である。図３７は、第５、第６の実施形態に係る図３０または図３７のフローチャートにおいて、リダクション４０４の演算が乗法から対数の加法に置き換えられ、かつ第６の実施形態の場合と同様に、個別識別子および集団識別子がベクトル化されたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１のCPU７０１−１または中継ノードとして機能する受信・中継ノード７０２のCPU７０２−１が実行する。入力ベクトル１または２等の作業領域は、送信起点ノード７０１のメモリ７０１−２または受信・中継ノード７０２のメモリ７０２−２に記憶される。
なお、本実施例での識別子は整数の順序付けられた集合である。ただし、送信側ノードが保持しているのは必ずしも本来の個別識別子自体ではなく対数あるいは対数と定数倍後の整数への変換を行った変形個別識別子であり、受信側ノードは受信した変形集団識別子から本来の集団識別子を復元して個別識別子を取り出す。ここでは、「順序付けられた集合」を「ベクトル」と呼び、「順序つけられた集合」の要素である整数を成分と呼ぶ。本来の個別識別子と本来の集団識別子の総称が「識別子」であり、変形個別識別子と変形集団識別子の総称が「変形識別子」である。識別子ベクトルあるいは変形識別子間の演算は、対応する位置の成分間の演算で定める。
図４２において、まず、自ノードが通信の起点ノードであるか否かが判定される（ステップＳ４２０１）。
ステップＳ４２０１の判定がＮＯであるならば、受信済みの値を格納する入力ベクトル１に、受信済みの変形集団識別子ベクトルが格納される（ステップＳ４２０２）。
ステップＳ４２０１の判定がＹＥＳならば、受信済みの値は無いため、入力ベクトル１の全成分に、対数加法演算の単位元の値０が格納される（ステップＳ４２０３）。
次に、自ノードが管理する管理対象において通知すべき条件が成立したか否かが判定される（ステップＳ４２０４）。
ステップＳ４２０４の判定がＹＥＳならば、自ノードの状態を格納する入力ベクトル２に、自ノードにおける管理対象（または自ノードそのもの）に対応する変形個別識別子ベクトルが格納される（ステップＳ４２０５）。
ステップＳ４２０４の判定がＮＯならば、入力ベクトル２の全成分に、単位元の値０が格納される（ステップＳ４２０６）。
その後、入力ベクトル１，２の全成分の間で、リダクション４０４に使用する対数加法演算が実行される（ステップＳ４２０７）。
最後に、ステップＳ４２０７での演算結果が、次の転送先への送信内容である変形集団識別子ベクトルとされて出力される（ステップＳ４２０８）。その後、図４２のフローチャートで例示される送信側ノードにおける識別子集約機構４０１の処理が終了する。
図４３は、上述の理論に基づく、第８の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の処理の例を示すフローチャートである。このフローチャートにおける処理の基本的な考え方は、前述した図６（第１の実施形態）、図１８（第２の実施形態）、図３１（第５の実施形態）、図３８（第６の実施形態）などと同様である。図４３は、第５、第６の実施形態に係る図３１または図３８のフローチャートにおいて、リダクション４０４の演算が乗法から対数の加法に置き換えられ、かつ第６の実施形態の場合と同様に個別識別子および集団識別子がベクトル化されたものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子分析機構４０２の処理が開始されると、受信側ノードとして機能する図７の受信・中継ノード７０２のCPU７０２−１が実行する。また、作業領域ベクトルWやX等は、受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、受信された変形集団識別子ベクトルにおいてオーバーフロー（図中「overflow」）が発生しているか否かが判定される（ステップＳ４３０１）。ステップＳ４３０１の判定がＹＥＳならば、受信処理は実質的に何も行われずに、図４３で例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
次に、ステップＳ４３０１の判定がＮＯならば、変形集団識別子ベクトルが作業領域ベクトルVに格納される（ステップＳ４３０２）。
次に、作業領域ベクトルVの各要素が例外値に含まれるか否かが判定される（ステップＳ４３０３）。
ステップＳ４３０３の判定がＮＯならば、作業領域ベクトルVの各要素値ごとに、指数演算が実行され（これを「exp(V)」と表記する）、その演算結果に最も近い整数が、作業領域ベクトルWの対応する要素に格納される（ステップＳ４３０４）。
作業領域ベクトルVのいずれかの要素についてステップＳ４３０３の判定がＹＥＳならば、その要素について例外値での誤差を補正した値が、作業領域ベクトルWの対応する要素に格納される（ステップＳ４３０５）。このステップで必要な例外値リストの作成処理について、図４４から図４６のフローチャートを用いて後述する。
次に、作業領域ベクトルWの全成分値が、リダクション４０４の対数加法演算領域から乗法演算領域に戻された状態（ステップＳ４３０４参照）での単位元の値１となったか否かが判定される（ステップＳ４３０６）。
ステップＳ４３０６の判定がＮＯならば、集団識別子ベクトルから個別識別子ベクトルが１つ特定され、その結果が作業領域ベクトルXに格納される（ステップＳ４３０７）。
その後、ステップＳ４３０７で作業領域ベクトルXに格納された個別識別子ベクトルに対応する管理対象が処理（特定）される（ステップＳ４３０８）。
次に、リダクション４０４に使用した対数変換前の乗法演算の逆演算すなわち除法演算が作業領域ベクトルWと作業領域ベクトルXの各成分に適用され、ステップＳ４３０７において作業領域ベクトルWから特定され作業領域ベクトルXに格納された個別識別子が取り外される（ステップＳ４３０９）。その後、ステップＳ４３０６の処理に戻って、上述のステップＳ４３０６からステップＳ４３０９までの処理が繰り返し実行される。
ステップＳ４３０６の判定がＹＥＳになると、図４３のフローチャートで例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
図４４および図４５は、図４３のステップＳ４３０５での補正処理に必要な例外値リストの作成処理の例を示すフローチャートである。
まず、整列済の個別識別子成分リストが作業領域Lに格納される（ステップＳ４４０１）。
次に、誤差チェックが必要な個識別子の成分個数の上限値が算出され、作業領域Kに格納される（ステップＳ４４０２）。この処理の詳細については、図４６のフローチャートを用いて後述する。
次に、作業領域Lの要素からK個を取り出す組み合わせのリストが作成され、作業領域Uに格納される（ステップＳ４４０３）。
次に、作業領域Uの先頭位置が作業領域Xに格納される（ステップＳ４４０４）。
次に、ステップＳ４４０５で作業領域Xが作業領域Uの末端位置と判定されるまで、図４５のステップＳ４４１３で作業領域Xに作業領域Uの次の位置が順次格納されながら、図４４のステップＳ４４０６から図４５のステップＳ４４１２までの処理が実行される。
まず、ステップＳ４４０５の判定がＮＯになると、作業領域U内の作業領域Xが示す現在の位置の個別識別子の組が、作業領域Tに格納される（ステップＳ４４０６）。
次に、作業領域Tに対応する変形個別識別子の組（要素が対数)が、作業領域Sに格納される（ステップＳ４４０７）。
次に、作業領域Tに対応する集団識別子が作業領域tに格納される（ステップＳ４４０８）。
次に、作業領域Sの順序を変えた和のうち最小値を取った値min(Σ(S))に対し、指数関数で変換が実行されることにより、対数の効果がキャンセルされ、その演算結果が作業領域sに格納される（図４５のステップＳ４４０９）。
ステップＳ４４０９の演算結果がオーバーフローしたか否かが判定される（ステップＳ４４１０）。
ステップＳ４４１０の判定がＹＥＳならば、Ｓ４４１３へ移行する。
ステップＳ４４１０の判定がＮＯならば、作業領域sの値に最も近い整数は作業領域tの値か否かが判定される（ステップＳ４４１１）。
ステップＳ４４１１の判定がＹＥＳならば、Ｓ４４１３へ移行する。
ステップＳ４４１１の判定がＮＯならば、作業領域sの値と作業領域T の値の対が、例外値リストに登録される（ステップＳ４４１２）。
その後、作業領域U内の次の位置が作業領域Xに格納され（ステップＳ４４１３）、ステップＳ４４０５に戻る。
以上のステップＳ４４０５からステップＳ４４１３までの繰返し処理の結果、ステップＳ４４０５の判定がＹＥＳになったら、例外値リストの作成処理が終了する。
図４６は、図４４のステップＳ４４０２の、誤差チェックが必要な個識別子の成分個数の上限値を算出して作業領域Kに格納する処理の詳細例を示すフローチャートである。
まず、整列済の個別識別子成分リストが作業領域Lに格納される（ステップＳ４６０１）。ここで、作業領域Lは、最小要素が先頭になるように整列される。
次に、分解能の上限値が作業領域kに格納される（ステップＳ４６０２）。
次に、作業領域Lの先頭位置が作業領域Yに格納される（ステップＳ４６０３）。
次に、作業領域ｆに値1が格納される（ステップＳ４６０４）。
次に、作業領域Kに、作業領域kの値が初期値として格納される（ステップＳ４６０５）。
次に、作業領域Yの位置が作業領域Lの末端位置になったか否かが判定される（ステップＳ４６０６）。
ステップＳ４６０６の判定がＮＯならば、作業領域L内の作業領域Yが示す現在位置の要素が作業領域gに格納される（ステップＳ４６０７）。
次に、作業領域fの値に作業領域gの値を乗算した結果が作業領域fに格納される（ステップＳ４６０８）。
ステップＳ４６０８の演算結果がオーバーフローしたか否かが判定される（ステップＳ４６０９）。
ステップＳ４６０９の判定がＹＥＳならば、処理が終了する。
ステップＳ４６０９の判定がＮＯならば、作業領域Kの値が+1インクリメントされる（ステップＳ４６１０）。
作業領域L内の次の位置が作業領域Yに格納され（ステップＳ４６１１）、ステップＳ４６０６の処理に戻る。
以上のステップＳ４６０６からステップＳ４６１１までの繰返し処理の結果、ステップＳ４６０６の判定がＹＥＳになると、図４６のフローチャートの処理が終了し、作業領域Kに誤差チェックが必要な個識別子の成分個数の上限値が格納され、図４４のステップＳ４４０２の処理が終了する。
以上説明した第８の実施形態は、ノード間演算機構（Reduction あるいはAtomic Operation 機能）として加法のみ利用できる場合に特に有効である。ノード間演算機構を使わずに、各ノードがCPU 上で演算を行う場合と比較すると、第３の実施形態で説明したように、ノード間演算機構を使う方が、性能的に有利であるからである。
なお、各ノードの個別識別子の対数は、予め計算して各ノードに配布しておく事が可能であるため、指数関数や対数関数の計算、および例外値リストの表を引く操作は、受信側で実行できればよく、送信側ノードでは、そのための演算装置や表を格納するメモリは不要である。
＜第９の実施形態＞
次に、第９の実施形態について説明する。
上述した第８の実施形態では、集団識別子を求めるリダクションは加法で行い、個別識別子を取り出す際に（対数関数の逆関数である指数関数によって変換した後）除法を使用したが、本実施形態では、加算結果を元に表を引く事で個別識別子を取り出す。
いわば、本実施形態の計算方法は、第８の実施形態で全ての集団識別子を「例外値リスト」に登録した場合に相当する。ただし、本実施形態での個別識別子は、「第５，第６の実施形態での個別識別子」から求めたものである必要はなく、例えば、次の条件(P) かつ(Q) を満たす「加算が定義された集合」の要素であればよい。
(P) 所定の大きさの領域での計算でオーバーフローしない個別識別子の組み合わせによる和は全て異なる
(Q) k 個より多くの個別識別子の和は全て特定の数より大きく、k 個以下の個別識別子の和は全て異なる。
例えば、整数の加算に対して上記性質を持つ集合は、識別子を格納する領域に格納可能な数の上限をa として、次のように選ぶ事ができる。
k = 1 の場合: a/2 以上a 以下の整数全ての集合を個別識別子の集合として使用できる。
k ≧ 2 の場合: a/k 以下の範囲で、以下のように集合S の要素を大きい方から追加する。こうして求めたS の任意の部分集合は個別識別子の集合として使用できる。
(1) 集合S を｛[a/k]+1｝ という１要素の集合とする。ここでの記号[x] は、「ガウスの記号」で、x を越えない最大の整数を意味する。a がm bits 領域とすると、a=2^m-1と表される。[a/k]+1から降順に連続してk 個の整数を選んで和をとってもオーバーフローしない（すなわち、和がa 以下である）事は、容易に確かめられる。
(2) 集合S の最小値をb として、b 未満の正の整数c でS∪{c}が前述の条件(P) かつ(Q) を保つか否かをb-1 から始めて降順に試していく。条件を保つ整数c が見つかれば、S∪{c}を改めてS とおき(2) を繰り返す。必ずしもb-1 以下の正の整数全てを試す必要はなく、事前に定めた大きさ、あるいは事前に定めた個数の個別識別子候補が見つかった時点で処理を終了してもよい。例えば、「k+1 個の和ではオーバーフローする」大きさでの打ち切りや（システムの管理対象の数より十分大きい）必要な数の個別識別子が得られた時点での打ち切りなど。
k≧2の場合、a が「m bit 領域に格納可能な整数」とするとき、分解能が完全な場合は、管理対象数の上限であるm 個より多くの管理対象に使用できるためには、S の要素数がmより大きい事も確認する必要がある。
例えば、分解能の上限k=2として、7bits 領域での{64,63,62,60,57,52,44,35}という集合は8 要素であり、条件を満たす。(上記の手順(1),(2)でa=127)
まず、第１の実施形態の説明で示した図１６（ｂ）を見れば、「２要素の和」が全て異なる事が確かめられる。また、３要素以上の和が全て7 bits 領域ではオーバーフローする事は35+44+52=131>127つまり、小さい方からの３要素の和が7 bits 領域ではオーバーフローする事から明らかである。
上記の例で降順に調べている理由は「k 個を越える数の和がオーバーフローする範囲では、k個以下の組み合わせの和を計算するだけでよい」事を利用して、確認の計算量を減らす事を意図している。ただし、個別識別子の集合を用意するのは、システムが運用される時ではなくシステムの設計時点であるため、個別識別子の集合を決定するための計算時間はシステム運用時の性能には影響を及ぼさない。
集団識別子の生成時に使用された個別識別子を調べるための表、あるいはハッシュ関数では、ある集団識別子を生成する個別識別子の中の少なくとも１つを与えれば、改めて表を引く、あるいはハッシュ関数を適用しなおして、残りの個別識別子も順次求める事ができる。例えば、ある集団識別子を生成する個別識別子のうち最大の数を与える表かハッシュ関数を事前に用意しておけば、受信した集団識別子を生成した個別識別子を全て求める事ができる。
図４７は、上述の理論に基づく、第９の実施形態における送信側ノードにおける識別子集約機構４０１（図４）の処理の例を示すフローチャートである。図４７は、第１の実施形態に係る図５のフローチャートの場合と同様にして、リダクション４０４の演算として加法が使用され、かつ個別識別子および集団識別子がベクトル化されたものである。ただし、本実施形態における加法演算は、前述した条件(p)および(q)を満たすものである。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子集約機構４０１の処理が開始されると、図７の送信起点ノード７０１のCPU７０１−１または中継ノードとして機能する受信・中継ノード７０２のCPU７０２−１が実行する。入力ベクトル１または２等の作業領域は、送信起点ノード７０１のメモリ７０１−２または受信・中継ノード７０２のメモリ７０２−２に記憶される。
本実施例での識別子は整数の順序付けられた集合である。ここでは、「順序付けられた集合」を「ベクトル」と呼び、「順序つけられた集合」の要素である整数を成分と呼ぶ。識別子ベクトル間の演算は、対応する位置の成分間の演算で定める。
図４７において、まず、自ノードが通信の起点ノードであるか否かが判定される（ステップＳ４７０１）。
ステップＳ３４０１の判定がＮＯであるならば、受信済みの値を格納する入力ベクトル１に、受信済みの集団識別子ベクトルが格納される（ステップＳ４７０２）。
ステップＳ４７０１の判定がＹＥＳならば、受信済みの値は無いため、入力ベクトル１の全成分に、加法演算の単位元の値０が格納される（ステップＳ４７０３）。
次に、自ノードが管理する管理対象において通知すべき条件が成立したか否かが判定される（ステップＳ４７０４）。
ステップＳ４７０４の判定がＹＥＳならば、自ノードの状態を格納する入力ベクトル２に、自ノードにおける管理対象（または自ノードそのもの）に対応する個別識別子ベクトルが格納される（ステップＳ４７０５）。
ステップＳ４７０４の判定がＮＯならば、入力ベクトル２の全成分に、単位元の値０が格納される（ステップＳ４７０６）。
その後、入力ベクトル１，２の全成分の間で、リダクション４０４に使用する加法演算が実行される（ステップＳ４７０７）。
最後に、ステップＳ４７０７での演算結果が、次の転送先への送信内容である集団識別子ベクトルとされて出力される（ステップＳ４７０８）。その後、図４７のフローチャートで例示される送信側ノードにおける識別子集約機構４０１の処理が終了する。
図４８は、上述の理論に基づく、第９の実施形態における受信側ノードにおける識別子分析機構４０２（図４）の処理の例を示すフローチャートである。このフローチャートにおける処理の基本的な考え方は、受信側ノードは集団識別子をキーとする個別識別子（成分）構成表を引いて、個別識別子（成分）を取り出すという点である。個別識別子および集団識別子は前述したようにベクトル化されている。機能ブロックおよびシステム構成は、第１の実施形態における図４および図７を例として説明する。もちろん、図２０、図２１、図２２等のシステム構成が採用されてもよい。図４の識別子分析機構４０２の処理が開始されると、受信側ノードとして機能する図７の受信・中継ノード７０２のCPU７０２−１が実行する。また、作業領域ベクトルWやX等は、受信・中継ノード７０２のメモリ７０２−２に記憶される。
まず、ノード間のリダクション４０４における集団識別子ベクトルが受信される（ステップＳ４８０１）。
次に、集団識別子ベクトルにおいてオーバーフロー（図中「overflow」）が発生しているか否かが判定される（ステップＳ４８０２）。ステップＳ４８０２の判定がＹＥＳならば、受信処理は実質的に何も行われずに、図４８で例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
次に、ステップＳ４８０２の判定がＮＯならば、集団識別子ベクトルが作業領域ベクトルWに格納される（ステップＳ４８０３）。
そして、作業領域ベクトルWの各成分について、図１６（ｂ）に例示されるような、集団識別子と生成因子である個別識別子のビットマップとの対照表を引いて、個別識別子が特定される（ステップＳ４８０４）。この対照表は、例えば受信・中継ノード７０２のメモリ７０２−２に保持されている。
その後、図４８のフローチャートで例示される受信側ノードにおける識別子分析機構４０２の処理が終了する。
図４９および図５０は、第９の実施形態において、加法のリダクションで集団識別子の成分を求めた場合の、受信側ノードで使用する個別識別子成分の対応リストの作成処理の例を示すフローチャートである。この処理は、図７の受信・中継ノード７０２以外の計算機によって実行されてよい。
まず、整列済の個別識別子成分リストが、作業領域Lに格納される（ステップＳ４９０１）。
次に、各成分での誤差チェックが必要な個識別子の成分個数の上限値が算出され、作業領域Kに格納される（ステップＳ４９０２）。この処理の詳細については、図５１のフローチャートを用いて後述する。
次に、作業領域Lの要素からK個を取り出す組み合わせとそのK個の要素の総和の対のリストが、作業領域Uに格納される（ステップＳ４９０３）。
次に、作業領域Uが、その要素の和について先頭を最小にするように整列される（ステップＳ４９０４）。
次に、作業領域Uの先頭位置が、作業領域Xに格納される。
図５０のフローチャートに移り、作業領域Xが示す位置が作業領域Uの末端位置であるか否かが判定される（ステップＳ４９０６）。
ステップＳ４９０６の判定がＮＯならば、作業領域Xの値が作業領域Zに格納される。
次に、作業領域U内の次の位置が、作業領域Xに格納される（ステップＳ４９０８）。
次に、作業領域Xの値が示す位置の要素の和が算出され、作業領域S(X)に格納される（ステップＳ４９０９）。
次に、作業領域Zの値が示す位置の要素の和が算出され、作業領域S(Z)に格納される（ステップＳ４９１０）。
作業領域S(X)と作業領域S(Z)の値が等しいか否かが判定される（ステップＳ４９１１）。
ステップＳ４９１１の判定がＹＥＳならば、作業領域Xの値が示す作業領域Uの値U(X)と作業領域Zの値が示す作業領域Uの値U(Z)の２組が相互に識別不可能と判明した場合に対して、予め定められている処理が実行される（ステップＳ４９１２）。例えば、対照となる値の対照表への登録が禁止される。
ステップＳ４９１１の判定がＮＯならば、ステップＳ４９１２の処理はスキップされる。
その後、ステップＳ４９０６の処理に戻り、作業領域Xの値が示す次の位置に対する処理が続行される。
作業領域Xが示す位置が作業領域Uの末端位置に到達した結果ステップＳ４９０６の判定がＹＥＳになると、図４９および図５０のフローチャートの処理を終了して、対照表の作成を終了する。
図５１は、図４９のステップＳ４９０２の、各成分での誤差チェックが必要な個識別子の成分個数の上限値を算出して作業領域Kに格納する処理の詳細例を示すフローチャートである。このフローチャートは、第８の実施形態において対数の加法による乗算を利用する場合の例外値リストの作成処理において前述した図４６のフローチャートの処理と、ほとんどの処理が同じである。すなわち、ステップＳ４６・・・で始まる処理は、図４６の場合と同じ処理である。図５１が図４６と異なるのは、図４６のステップＳ４６０８に対応する図５１のステップＳ５１０１で、作業領域fの値と作業領域gの値とを、乗算ではなく加算して、新たな作業領域fの値を算出する点である。これは、第９の実施形態におけるリダクション４０４の演算が乗算ではなく加算であるからである。その他の上限値算出のアルゴリズムは図４６の場合と同じである。
上述した図４９から図５１のフローチャートをベースとして、前述した図１６（ｂ）の対照表を作成する具体的な手順について、以下に説明する。
＜処理フロー＞
初期集合を、
S={64}
とする。
64+63=127
なのでオーバーフローしない。ゆえに、
S={64,63}
としてもよい。
ここで、Sの最小値63を取る。
64+63,64+62,63+62はすべて異なるので、
(P) 所定の大きさの領域での計算でオーバーフローしない個別識別子の組み合わせによる和は全て異なる
(Q) k 個より多くの個別識別子の和は全て特定の数より大きく、k 個以下の個別識別子の和は全て異なる。
という条件が満たされる。このため、62を追加可能である。ゆえに、
S={64,63,62}
としてもよい。ただし、
S={64,63,62,61}とはできない。なぜならば、
64+61=63+62
であるからである。よって、61がスキップされる。
S={64,63,62,60}
としてもよい事は、以下のように確認できる。
前の３要素のなす部分集合に２つとも入っている場合は、確認済である。最小の和は下から２つの和、
63+62=125
である。少なくとも１つはみ出す場合、一方の要素は60である。最大の要素64との和が 124なので、前の３つの中からどれを選んで和をとっても、前の３つから２つとったものの和より小さいので、一致しない。また、前のものとの和は全部異なる。
一般に前の要素との差が1以上なので、
S={64,63,62,60,59}
とできない事は、
63+59=62+60
から明らかである。よって、59がスキップされる。
S={64,63,62,60,58}
とできない事は、
64+58=62+60
から明らかである。よって、58もスキップされる。
S={64,63,62,60,57}
とできる事は、前の４要素のなす部分集合に２つとも入っている場合は、確認済である。少なくとも１つはみ出す場合、一方の要素は57である。最大の要素64との和が121なので、前の３つの中からどれを選んで和をとっても、前の３つから２つとったものの和より小さいので、一致しない。また、前のものとの和は全部異なる。
以下、同様の処理が実行されることにより、図１６（ｂ）の対照表ができあがる。
以上説明した第９の実施形態は、ノード間演算機構（Reduction あるいはAtomic Operation 機能）として加法のみ利用できる場合に特に有効である。ノード間演算機構を使わずに、各ノードがCPU 上で演算を行う場合と比較すると、第３の実施形態で説明したように、ノード間演算機構を利用する方が、性能的に有利であるためである。
＜第１０の実施形態＞
次に、第１０の実施形態について説明する。
第５から第８の実施形態では、送信側ノードから受信側ノードに送るデータは「分解能が上限k を持つ」という条件により、第２から第４の実施形態に比べて、小さい領域で多数の管理対象の情報を受信できる。分解能が完全である第２から第４の実施形態の方法では、管理対象と同数のbit 数が必要となる。
しかし、第５から第８の実施形態では、集団識別子から個別識別子を求める際に別途識別子の表を参照する必要があるため、何らかの方法でとりうる個別識別子の範囲を限定しないと、識別すべき管理対象と対応しない個別識別子の領域を含め、識別子の表のメモリ領域へのアクセスが増える。
本実施形態では、識別子の集合を複数のグループに分けておき、各ノードは管理対象の識別子が所属するグループを別のリダクションで管理対象自体の識別子とは別に通知する。ここまでの基本的な考え方は第４の実施形態と同様であり、グループを上位の（仮想的な）管理対象として、各グループ（管理用の、仮想的な）の個別識別子を別途設定する。本実施形態ではさらに、以下の処理を実行する。
グループの識別に際して、同一グループに属する管理対象には「同じ領域の同じ位置のビットがon である個別識別子」を割当てれば、bitwise or 演算により「グループ内の少なくともどれか１つの管理対象が監視している状態にある」事を、リダクションにより通知できる。すなわち、複数の管理対象の状態のlogical or を通知できる。
bitwise and （ビット単位の論理積演算）ないし乗法を使用する場合、「not ( A and B) ←→ (not A) or (not B)」というド・モルガンの法則を利用すればよい。すなわち、条件が成立する管理対象に対して0 を入力とし、そうでない場合は1 を入力としてbitwise and ないし乗法を行った結果をbit 反転すればよい。
加法を使用する場合は、単に「グループ用の集団識別子の格納領域」を別に持てばよい。（個別識別子が全て正なら足し算するだけで値が入ったか（変化したか）どうかが分かり、初期値0 として結果が0 でない値になるかオーバーフローした場合、少なくとも１つの入力が0 でない事が分かるので、「グループ用の個別識別子」を個々の管理対象の識別子と別に定める必要もない。「グループ用の個別識別子」は「グループ用の集団識別子の格納領域」を見るためのものであり、上記の場合、「グループ用の個別識別子」を与えなくても「グループ用の集団識別子の格納領域」は演算可能である。
グループの集団識別子の計算では管理対象数が小さくなるため、全ての管理対象の識別子を順次試すより、平均的な参照範囲を減らす事ができる。
グループの集団識別子としては、第２，第３の実施形態のものを使用する方法（第４の実施形態と全く同様）でもよく、第５から第９の実施形態を適用してもよい。なお、第２、第３の実施形態に対するグループの識別子についても、第５から第８の実施形態の方法を適用することは可能である。
図５２は、本実施形態において、bitwise or 演算で階層的にグループ化された識別子の送信処理の例を示すフローチャートである。
まず、各グループ階層の個別識別子からbitwise or 演算でのリダクションでグループの集団識別子が求められる（ステップＳ５２０１）。
次に、最下層での（本来の管理対象の）個別識別子について乗法によるリダクションの集団識別子が求められる（ステップＳ５２０２）。
そして、両方の集団識別子が、次の転送先に送信される（ステップＳ５２０３）。
図５３は、本実施形態において、bitwise or 演算で階層的にグループ化された識別子の受信処理の例を示すフローチャートである。
まず、各グループ階層の集団識別子から深さ優先探索により最下層の乗法を演算とする個別識別子成分のリストが特定される（ステップＳ５３０１）。深さ優先探索を伴う受信処理の具体的なアルゴリズム例は、第４の実施形態において図２８のフローチャートを用いて前述した。
そして、特定された個別識別子成分のリストに基いて、乗法でのリダクションの集団識別子から個別識別子（の成分）が特定される（ステップＳ５３０２）。
図５４は、本実施形態において、乗法演算で階層的にグループ化された識別子の送信処理の例を示すフローチャートである。
まず、各グループ階層の個別識別子からグループの集団識別子が求められる（ステップＳ５４０１）。
そして、各階層の集団識別子が、次の転送先に送信される（ステップＳ５４０２）。
図５５は、本実施形態において、乗法演算で階層的にグループ化された識別子の受信処理の例を示すフローチャートである。
まず、現在処理する階層を示す作業領域gに値1が格納される（ステップＳ５５０１）。
次に、作業領域ｇが示す階層の集団識別子（成分)が、作業領域W（ｇ）に格納される（ステップＳ５５０２）。
次に、作業領域gが示す階層の値が、グループ階層数よりも大きくなったか否かが判定される（ステップＳ５５０３）。
ステップＳ５５０３の判定がＮＯならば、作業領域W（ｇ）が1（乗法演算の単位元）でないか否かが判定される（ステップＳ５５０４）。
ステップＳ５５０４の判定がＹＥＳ（W(g)が値1でない）ならば、作業領域W(g)内の個別識別子成分の１つが、作業領域qに格納される（ステップＳ５５０５）。
次に、作業領域gが示す階層の値がグループ階層数に等しいか否か、すなわち最下層であるか否かが判定される（ステップＳ５５０６）。
ステップＳ５５０６の判定がＹＥＳならば、最下層識別子に固有の処理、すなわち、最下層から取り出されている個別識別子より管理対象を抽出する処理が実行される（ステップＳ５５０７）。
ステップＳ５５０６の判定がＮＯば、ステップＳ５５０７の処理はスキップされる。
その後、作業領域W(g)を作業領域qで除算した結果が、新たに作業領域W(g)に格納される（ステップＳ５５０８）。
最後に、作業領域gの値が+1インクリメントされる（ステップＳ５５０９）。その後、ステップＳ５５０２の処理に戻り、次の階層に対する受信処理が実行される。
作業領域gが示す階層の値がグループ階層数よりも大きくなった結果ステップＳ５５０３の判定がＹＥＳになると、受信処理が終了する。
以上説明した第１０の実施形態によれば、任意の分解能k に対して、個別識別子の探索範囲を限定してメモリアクセスに伴う処理時間を短縮することが可能となる。
＜第１１の実施形態＞
次に、第１１の実施形態について説明する。
集団識別子から個別識別子を特定する過程で表を引く場合、ないし個別識別子から管理対象を特定する処理で表を検索する場合に、検索処理の高速化が課題となる。
特に、「分解能が上限k で制限される場合」でかつ演算を乗法とする際の基本的アイデアは、「素因数分解の一意性」を利用して、乗法でのリダクションで計算された集団識別子から、個別識別子を取り出す事である。従って、「素因数分解」の所要時間がシステムの処理性能の高速化に際して重要な因子となる。
「素因数分解の一意性」が成立する集合として、通常の意味の整数ではなく「代数的整数」を使用する事で、係数が同じ大きさの範囲内で個別識別子として使用できる数を増やして、同じ分解能k を実現するために必要なメモリ使用量を削減する。ここで、普通の整数以外の集合（例えば「代数的整数」の集合）での「素数（に相当する要素）」は、関連する数学の文献において「素元」と呼ばれ、それらの集合での「素因数分解」は「素元分解」と呼ばれる事が多いが、本出願では「ある集合における「素数」」という呼び方を主に使用している。学術的な厳密性よりも分かりやすさを重視したためである。
本実施形態では、brute force method（因数となりうる数で順次割っていく事による因数分解の方法）を使う場合に、現れる素因数の範囲を別途通知する方法や整数での除算での余りの計算を利用して、「因数となりうる数」の集合を小さくして、その集合の要素を含む表を引くためのメモリアクセスに伴う処理時間を削減する。なお、brute force method では、因数となりうる数の表を引く過程で、管理対象の番号も合わせて求める事ができる。管理対象の番号自体を表の「主キー」にするか、表の各エントリに管理対象の番号を含めておく。また、割り算による余りをハッシュ値として、ハッシュ値毎に「因数となりうる数」の表を分割する事で、引くべき表の大きさを小さくすることができる。個別識別子の集合から規定される「集団識別子内の素因数の数の上限」の範囲内で、「集団識別子の除算での余り」に基いて、「個別識別子の余りの組み合わせ」を限定する事で、個別識別子を求めるために引くべき表を限定することができる。さらに、複数の数での割り算による余りの組み合わせにより、「因数となりうる数」の表を細分する事により、引くべき表の大きさを、さらに小さくすることができる。割り算の余りによる条件は、除数を互いに素にする事で「独立な条件」となるので、「互いに素な複数の除数による余りの組み合わせ」毎の表を作る事で細分できる。
以下に説明する本実施形態では、識別子から管理対象の番号を求める操作において、割り算による余りをハッシュ値とし、ハッシュ値毎に「因数となりうる数」の表を分割する事で、引くべき表の大きさを小さくする。すなわち、本実施形態では、「ハッシュ関数」を利用する事で、検索処理に際して参照が必要なメモリ領域の量を限定する。リダクション演算に乗法を使用し、集団子識別子の生成因子を「素因数分解」で求める場合は、使用する個別識別子全体の集合が「予め分かっている素因数の候補」なので、個別識別子全体の集合の個数をN として、O(N) 以下である。N が数万から数十万程度でも、システムによっては「許容範囲内」にできる。除算の剰余を利用したハッシュ関数で、O(N) のままでも、「定数係数」を小さくする事で「許容範囲内」にできる場合がある。
個別識別子から管理対象の番号を求める際に「個別識別子に使われる素数の表」を引く場合、大きさ順に表を整列して（線形探索（Linear Search）でなく２分探索（binary search）を使用して）表の大きさNに対しての探索時間をlog_2(N) 程度に抑えられる。
さらに、逆引きできる表や計算式（ハッシュ関数）、ないし、それらの組み合わせにより、探索範囲を狭める事もできる。以下では、本実施形態で利用可能なハッシュ関数の例を挙げておく。
例えば、ハッシュ関数として個別識別子領域の下位4 bits ないし下位8 bitsの値を使い、予め個別識別子に使う素数を下位4 bits あるいは8 bits 毎に別の表にしておく事ができる。
各ハッシュ値（下位4 bits ないし8 bits の値）毎の表の大きさが平均化されるように個別識別子に使う素数の集合を選んでおけば、探索すべき表の大きさを1/15 、ないし1/255 程度に小さくできる。
第５，第６の実施形態で、k=2として、32 bit 領域を使用する場合に、個別識別子を2^16-1より小さく2^(32/3) より大きい素数（例えば、1627以上の素数）を個別識別子とすると、3個以上の個別識別子の積はオーバーフローするので、集団識別子の数が２個以下であるとしてよい。
また、1627^2>2^16-1なので、集団識別子の大きさによって、2個の個別識別子が含まれる場合と、1個の個別識別子しか含まない場合を区別できる。
1個の個別識別子しか含まないと判れば、k=1の場合と同様な手法により探索範囲を減らす事ができる。
2個の個別識別子を含む場合、集団識別子の平方根r を計算する。個別識別子の一方はr より大きく他方はr より小さいので、どちらかの一方の範囲で探索すればよい。
さらに、個別識別子の大きさを出来るだけ揃えておくと、含まれる個別識別子は集団識別子の平方根に近くなるので、最初に割り切れるか試す素数は「平方根になるべく近い素数」として、大きさで昇順、ないし降順に試していく方法が有効になる。
任意の分解能k とm bits 領域の組み合わせについて、2^(m/k) を下限とする範囲の素数を個別識別子に使い、少なくとも１つの個別識別子が集団識別子のk 乗根より大きいあるいは小さい事を利用して探索範囲を限定できる。個別識別子の大きさを揃えておく事の効果も、k=2の場合と同様である。
また、奇数の素数だけを個別識別子とし、さらに下位2 bits を参照して4 で割った余りが1 の素数と3 の素数について個別に表を作成しておく事で個別識別子の表の探索範囲を限定する事が、次のようにして可能である。
集団識別子を4 で割った余りが3 の場合、一方の素数を4 で割った余りが３，他方を4 で割った余りが1 なので、素数の表を「4 で割った余り」を基準に２つ分けておけば、どちらの表にも必ず個別識別子が含まれるので、片方の表の範囲内を最初に探索する事で探索範囲が半分程度になる。集団識別子を4 で割った余りが1 の場合は、片方の表の範囲内を最初に探索する方法では、その表に個別識別子が含まれない場合の探索時間が大きくなるので、最初から全個別識別子候補を含む表を探索する方が、探索時間が平均化される。
なお、個別識別子を4 で割った余りがどちらかを、各ノードがlogical or のリダクションを並行して通知しておけば、２つの個別識別子を4 で割った余りが一致している場合も余りがどちらかが判定できるので、探索範囲が半分程度になる。これは、第４の実施形態で説明した方法の一例である）。
2の冪以外で割った余りによって、個別識別子を分けておく事もできる。例えば、３で割った余り、５で割った余り、７で割った余りなどで分けておく。個別識別子の素因数となる素数の分布は、例えば各余りについて均等にする、あるいは、逆に特定の余りになる素数だけを個別識別子の素因数にするなどの条件を、個別識別子の探索手順に合わせて付加しておく事ができる。
例えば３で割った余りは1 または2 で、２つの数の積の余りが1 の場合は元の２つの余りが等しい事が分かるだけだが、2 の場合は、少なくとも一方の余りが１で他方が2と分かるので、どちらか一方を検索すれば、必ず素因数が見つかる事になる。従って、探索範囲が半分程度になる。
２つの数を４で割った余りによるハッシュ値と３で割った余りによるハッシュ値のどちらも同じになる確率は（各々の余りを持つ個別識別子の割合を均等にすれば）1/4 程度となり、３で割った余りによるハッシュ関数と併用すれば、3/4 程度の割合で探索時間が半分程度になる。他の数の余りによるハッシュ値も併用すれば、さらに大きな割合で探索時間を減らすことも出来る。
一般に演算器による計算の命令あたり（時間の観点での）コストはメモリ参照コストに比べて数桁小さいため、演算器による計算が必要な処理を追加して、メモリ参照コストを減らす事で高速になる場合がしばしばある。除算は、演算器を使用する処理の中では比較的コストが高いが、例えば3, 5, 7 での除算に対しては、第４の実施形態で引用した文献[6]などで開示されている比較的高速なアルゴリズムが知られている。このため、除算（ないし余りを求める）処理の時間は、探索範囲を減らす効果に較べて、十分小さいと期待できる。
他の数の除算での余りについても、同様に試行済の除算での余りについての条件から探索範囲を狭められる場合がある。すなわち、個別識別子の集合をQ={q_1,q_2,...,q_i}としてQ-{q_1}={q_2,...,q_i}の各要素をq_1 で割った余りで分類し、Q_1,Q_2,...,Q_jとしておくと、q_1 での集団識別子の除算の余りについての条件からQ_1,Q_2,...,Q_jの中で、集団識別子の生成因子を含まないものを特定できる場合がある。
さらに、個別識別子の集合を、ハッシュ関数による探索範囲の削減効果が大きくなるように、事前に調整する事が可能である。あるハッシュ関数の値で「衝突」が起こって探索が必要になる個別識別子の表から「衝突」の多い方から順に個別識別子の候補を、実際に使用する個別識別子の表から除外していけば、「衝突」の減少により、平均探索範囲は減少する。
図５６は、本実施形態における個別識別子リストの探索処理の例を示すフローチャートであり、ハッシュ値で個別識別子表を限定して検索する一般的な処理の例を示す。
まず、個別識別子のハッシュ値が、作業領域hに格納される（ステップＳ５６０１）。
次に、作業領域hが示すハッシュ値に対応する個別識別子の表が、作業領域Lに格納される（ステップＳ５６０２）。
そして、個別識別子あ作業領域L内で検索され、管理対象の番号が求められる（ステップＳ５６０３）。
図５７は、本実施形態における個別識別子リストの探索処理の例を示すフローチャートであり、集団識別子のハッシュ値で個別識別子のハッシュ値の範囲を限定して個別識別子の表を限定する処理の例を示す。
まず、集団識別子のハッシュ値が作業領域Hに格納される（ステップＳ５７０１）。
次に、作業領域Hにより定まる個別識別子表の候補リストが、作業領域Gに格納される（ステップＳ５７０２）。
次に、作業領域Gから先頭の個別識別子表が取り出され、作業領域Xに格納される（ステップＳ５７０３）。
次に、作業領域X内で集団識別子に含まれる個別識別子が探索される（ステップＳ５７０４）。
個別識別子が見つかったか否かが判定される（ステップＳ５７０５）。
ステップＳ５７０５の判定がＮＯならば、探索処理が終了する。
ステップＳ５７０５の判定がＹＥＳならば、作業領域Gの内容が空か否かが判定される（ステップＳ５７０６）。
ステップＳ５７０６の判定がＮＯならば、探索処理が終了する。
ステップＳ５７０６の判定がＹＥＳならば、作業領域Gから次の個別識別子リストが取り出され（ステップＳ５７０７）、ステップＳ５７０４に戻って次の探索が続行される。
図５８は、本実施形態における個別識別子リストの探索処理の例を示すフローチャートであり、集団識別子のハッシュ値による個別識別子表候補リストの作成処理の例を示す。
まず、個別識別子表を定めるインデックスの組のリストＪが、空リストで初期化される（ステップＳ５８０１）。
次に、除数リストが、作業領域Qに格納される（ステップＳ５８０２）。
次に、集団識別子のハッシュ値リストが、作業領域Hに格納される（ステップＳ５８０３）。
次に、作業領域Qまたは作業領域Hが、空であるか否かが判定される（ステップＳ５８０４）。
ステップＳ５８０４の判定がＮＯならば、作業領域Q、Hから除数とハッシュ値の対が取り出され、作業領域の対(q,h)に格納される（ステップＳ５８０５）。
次に、qを法として、積の剰余がhの場合に、因子となりうる数のqに関する剰余の対のリストが、作業領域X（ｑ,h）に格納される（ステップＳ５８０６）。
最後に、全ての組合わせでJの各要素の末尾に、作業領域X(q,h)の各要素が追加されたリストが、改めてJとされる（ステップＳ５８０７）。
その後、ステップＳ５８０４に戻って、処理が続行される。
最後に、ステップＳ５８０４の判定がＹＥＳになると、処理が終了する。
図５９は、第１１の実施形態における個別識別子リストの探索処理の例を示すフローチャートであり、識別子のハッシュ値リストとして複数の除数による剰余の組を使用する例を示す。
まず、除数リストが、作業領域Qに格納される（ステップＳ５９０１）。
次に、作業領域Qが空か否かが判定される（ステップＳ５９０２）。
ステップＳ５９０２の判定がＮＯならば、作業領域Qから除数qが取り出され、識別子のqに関する剰余rが求められ、そのｒがハッシュ値リストに追加される（ステップＳ５９０３）。
その後、ステップＳ５９０２に戻って、処理が続行される。
最後に、ステップＳ５９０２の判定がＹＥＳになると、処理が終了する。
探索処理の具体例を以下に示す。
k=2 に固定し、使用する素数は５より大きい奇数とし、ハッシュ値を 「4 で割った余り」、「3 で割った余り」とします。適当な素数の集合を決めて、「４で割った余り」と「３で割った余り」の組み合わせで、４等分されるようにしておく。そうすると、２つの素数の積＝集団識別子の余りについては、以下のようになる。
（積の余り）
積を４で割った余りが 3 なら、一方の素数は４で割って余り１，
他方の素数は４で割って余り３
積を４で割った余りが 1 なら、どちらの素数も４で割った余りが同じ。
積を３で割った余りが２なら、一方の素数は３で割って余り１，
他方の素数は３で割って余り２
積を３で割った余りが 1 なら、どちらの素数も３で割った余りが同じ。
上記の積を３で割った場合、４で割った場合の余りの組み合わせ条件で分類した表に分けておけば、表の検索時間が 1/4 になる。
図５８のフローチャートの処理では、Q={3,4}（除数）、H={5,7,11,13,17}（素数）とすると、左が3で割った余り、右が4で割った余りを示すものとして、以下の出力を得る処理となる。
（出力）
5 -> (2,1)
7 -> (1,3)
11 -> (2,3)
13 -> (1,1)
17 -> (2,1)
図５９のフローチャートの処理では、Q={3,4}（除数）から以下４つのグループを作成する処理になる。
１．3で割ると1余り、4で割ると1余る
２．3で割ると2余り、4で割ると1余る
３．3で割ると1余り、4で割ると3余る
４．3で割ると2余り、4で割ると3余る
素数5と11を掛け合わせた数55(=5×11)は、3で割ると1余り、4で割ると3余る数であり、上記の３のグループに属する事になる。
以上説明した第１１の実施形態によれば、第１０の実施形態の場合と同様に、個別識別子の探索範囲を限定することが可能となる。
また、必要に応じて第１０の実施形態と併用する場合を含め、第１０の実施形態での「グループ（管理用／仮想的な）個別識別子」のリダクションに必要な通信を不要にするか、減少させる事により、図７の受信・中継ノード７０２のシステム資源所要量を、第１０の実施形態（単独）での場合に比べて、減らすことが可能となる。
本実施形態では通信データ量が増加せず、追加される計算のコストは、メモリアクセスのコスト（ここでは「メモリアクセスに伴う処理遅延」の意味）に比べて小さい範囲内に留まる。このため、特に複数ハッシュ関数の組み合わせを使う事で、メモリアクセスコストが大幅に削減される。
＜第１２の実施形態＞
次に、第１２の実施形態について説明する。
第１１の実施形態の場合と同様にして、集団識別子から個別識別子を特定する過程で表を引く場合、ないし個別識別子から管理対象を特定する処理で表を検索する場合を考える。第１１の実施形態で言及したハッシュ法の特別な場合として、次のデータの組に対して「回帰分析」あるいは「離散フーリエ変換」を適用して求めた近似式を利用することが可能である。
｛個別識別子の集合｝と｛管理対象の番号の集合｝
｛集団識別子の集合｝と｛個別識別子の集合｝
本実施形態では、「回帰分析」や「離散フーリエ変換」を利用して、識別子に関する検索処理での探索範囲を狭め、これによりメモリアクセス量を制限し高速化する。本実施形態も「ハッシュ関数」を使う方法の一種と考える事ができるが、第１１の実施形態の中で言及したハッシュ関数とは性質が大きく異なる。浮動小数点による計算を使用する点でも、整数演算による第１１の実施形態と異なる。
第１０の実施形態はリダクション４０４（図４）の際に使用する演算を乗法に限定したが、本実施形態はリダクション４０４に使用する演算が加法の場合も対象とする。本実施形態は、以下の探索範囲に適用することができる。
個別識別子（の成分）から管理対象の番号を求める際の探索範囲。目的変数（従属変数）の管理対象番号と説明変数（独立変数）の個別識別子の間の対応は１対１対応であり、原理上は「完全ハッシュ関数」もありうる。
集団識別子（の成分）から個別識別子（の成分）の探索範囲。集団識別子と個別識別子の対応は１対１でないため、例えば個別識別子間の順序関係により最小、最大その他の「代表の一つ」を決める事にすれば、その個別識別子に対して、集団識別子の関数として回帰分析を適用できる。個別識別子（の成分）間の順序関係は、例えば以下のような関係で定められる。数としての大小関係である。成分毎の大小関係と数成分間の辞書式順序による全体での大小関係である。および、代数的整数の「ノルム」、係数の間の大小関係と各係数に対応する（ベクトル空間としての「基底」に対する）辞書式順序による大小関係である。一般に１対１対応でない場合（逆関数が存在しない場合）一変数の一次式での回帰分析だけでは、有効な近似式は得られないため、非線形回帰分析を使用する。例えば、大きさの範囲ごとに複数の区間に分けると、各区間では１対１対応になり、線形の近似式が有効になる場合がありうる。離散フーリエ変換や、（周期関数や単調増加ではない関数で変換した変数を加えた）重回帰分析（による非線形の回帰分析式）は、１対１対応でない場合にも有効である。
本実施形態の説明に際し、第６の実施形態のように個別識別子が複数の成分を持つ場合を、成分が１つしかない第５の実施形態の場合と同じ計算法で取り扱う事ができる。そのために、個別識別子の成分には（管理対象の番号自体ではなく）管理対象番号を、各次元が対応する成分の集合の要素数に等しい多次元配列に格納し、個別識別子の成分と多次元配列のインデックスを対応させる。第５の実施形態で（１次元の）個別識別子と管理対象番号を対応させる処理と、第６の実施形態での個別識別子の各成分と多次元配列のインデックスの対応を求める処理は同等になる。
以下では、説明を簡単にするため、特に断らない限り、第５の実施形態の（成分数が１）として説明する。上述した同じ計算法になる言及により、こうしても一般性は損なわれない。
まず、個別識別子として使用する数を管理対象の番号と対応させる際、各々の表を大きさ順に整列し、２つの番号n1, n2 と対応する個別識別子p1, p2 に対し、次のどちらかが成立するようにしておく。
(1) n1 < n2 の時には常にp1 < p2
(2) n1 < n2 の時には常にp1 > p2
ここで、管理対象の番号と個別識別子の間で「回帰分析」を実行して、一次近似式を作成する。例えば、個別識別子を得た時に番号を知りたい場合、回帰分析で説明変数を個別識別子とする一次近似式を作る。
一次近似式がn = A*p + B として、この近似式での誤差が最大になる場合の誤差の絶対値をE とすると、個別識別子p が判明した時に対応する番号を得る際の探索範囲は、近似式から得た値に最も近い整数をｚ とすると区間[z-E-1,z+E+1]の内側に限定される。誤差の符号を考慮して「過小」である場合の最大誤差をE、「過小」である場合の最大誤差をF として探索範囲を区間[z-E-1,z+F+1] の内側に限定される。p の範囲をs 個の区間に区分して、各区間で符号を考慮した最大誤差｛(-E1,F1),...(-Ei,Fi),...(-Es,Fs)｝を求めれば、第i 区間での番号の探索範囲は[z-Ei-1,z+Fi+1]の内側に限定される。
以下のような手段（組み合わせ含む）により、上記の誤差を小さくする事ができる。
近似式で誤差が大きくなる数を取り除く。番号に抜けが許されない場合は、番号を振りなおして回帰分析をやり直す。
個別識別子をグループに分けて各グループごとに別の一次近似式を使用する（回帰分析の用語で、非線型回帰分析の一種である「局所線形モデル」の使用に相当する）。例えば、大きさで整列して大きさが近いものでグループ化する。
個別識別子と番号に、一次式以外の関数による非線形回帰分析を行う。例えば、一方ないし両方の集合の要素（あるいは、要素の成分）を累乗、対数関数、指数関数、三角関数、あるいはそれらの和などの式で変換した数の集合の一次式での回帰分析は、元のデータ集合間の非線形回帰分析になる。各々の変数を一次式以外の関数で１つないし複数の関数で変換し、それらを新たな変数として追加した「重回帰分析」を行い、元の変数の間の関係式に戻せば、必ず当てはまりが改善された近似式を得る事ができる。説明変数を増やせば、常に当てはまりが改善された式が得られる（最悪でも、追加した変数の係数を0 とすれば、当てはまりが悪化する事はあり得ない）ため。個別識別子の集合は「設計時に選べるデータ」であって、本来の意味で統計的データではなく、統計的データの処理の場合のような「モデルへの変数追加の妥当性」を考慮する必要はない。本実施形態では、単に式の当てはまりを改善できればよい。
線形の回帰分析と離散フーリエ変換を組み合わせて非線形回帰分析を行う。例えば、線形回帰分析で求めた一次近似式の誤差項に対して離散フーリエ変換を行って、誤差項を三角関数の和で近似する式を作り、元の一次近似式に加える。
なお、加法によるリダクションを利用する場合に集団識別子から個別識別子を検索する場合の手順は、最終的な対応が一般には１対１でない事以外は、個別識別子から管理対象の番号を検索する場合の手順と同様になる。なぜならば、一次近似式を使う場合、最終的に同じ個別識別子に対応する組み合わせで近似式の値が異なる場合は、単に一方の誤差が大きいと見なされる。また、離散フーリエ変換を使う場合では、近似式上でも異なる変数に対応して同じ値が現れてもよいため、特に問題はない。
図６０から図６５は、本実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートである。
図６０は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、回帰分析による管理対象番号と個別識別子の間の一次近似式作成処理の例である。
まず、管理対象番号の整列済リストが、作業領域Xに格納される（ステップＳ６００１）。
次に、個別識別子の整列済リストが、作業領域Yに格納される（ステップＳ６００２）。
次に、XとYに対して回帰分析が実行され、互いに他を入力とした一次式での近似式が算出される（ステップＳ６００３）。
さらに、回帰分析で求めた近似式の各入力に対する誤差リストが、各項で近似値から実際の値が引かれて算出される（ステップＳ６００４）。
そして、誤差リストの要素が整列され、元のリストの要素としての番号と対応付けた別のリスト、すなわち、誤差リストと管理対象番号の整列のリストとを対応付けた表が作成される（ステップＳ６００５）。
図６１は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、誤差が大きい箇所を除く事による一次近似式の精度向上の例である。
まず、一次近似式の誤差が規定値より大きい項の個別識別子が、リストから除かれる（ステップＳ６１０１）。
次に、管理対象番号に飛びがあってもよいか否かが判定される（ステップＳ６１０２）。
ステップＳ６１０２の判定がＹＥＳなら、そのまま処理が終了する。
ステップＳ６１０２の判定がＮＯなら、個別識別子を取り除いた箇所で番号を詰めて回帰分析が再実行される（ステップＳ６１０３）。その後、処理が終了する。
図６２は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、局所線形モデルによる近似式の精度向上の例である。
まず、誤差が規定値より大きい箇所が、誤差の大きさで整列した誤差項リストから選ばれる（ステップＳ６２０１）。
次に、誤差が規定値より大きい箇所の番号を境界として、データの集合が分割される（ステップＳ６２０２）。
そして、分割したデータの集合の各々に対し改めて回帰分析が実行されて、各集合ごとの一次近似式が求められる（ステップＳ６２０３）。
図６３は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、誤差の離散フーリエ変換による近似式の精度向上の例である。
まず、線形回帰分析で得た誤差項のリストに離散フーリエ変換が行われ、誤差項の近似式が作成される（ステップＳ６３０１）。
次に、元の一次近似式と誤差項の近似式が加えられて、非線形近似式が得られる（ステップＳ６３０２）。
図６４は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、重回帰分析による非線形近似式の作成処理（一般）の例である。
まず、管理対象番号の整列済リストが、作業領域Xに格納される（ステップＳ６４０１）。
次に、個別識別子の整列済リストが、作業領域Yに格納される（ステップＳ６４０２）。
次に、XおよびXを１つまたは複数の非線形関数で変換したリストからなる「リストのリスト」が、作業領域XXに格納される（ステップＳ６４０３）。
同様に、YおよびYを１つまたは複数の非線形関数で変換したリストからなる「リストのリスト」が、作業領域YYに格納される（ステップＳ６４０４）。
続いて、XとYYに対し重回帰分析が行われて、XのYYの各リストの値を格納する変数を入力とした近似式が求められる（ステップＳ６４０５）。
同様に、YとXXに対し重回帰分析が行われて、YのXXの各リストの値を格納する変数を入力とした近似式が求められる（ステップＳ６４０６）。
そして、重回帰分析で求められた近似式の各入力に対する誤差リストが、各項で近似値から実際の値の値が引かれて求められる（ステップＳ６４０７）。
最後に、誤差リストの要素が整列させられ、元のリストの要素としての番号と対応付けた別のリストが作成される（ステップＳ６４０８）。
図６５は、第１２の実施形態での個別識別子と管理対象番号の対応付けの高速化処理の例を示すフローチャートであり、回帰分析により作成した近似式f(x) をハッシュ関数とする検索処理の例である。
まず、個別識別子と管理対象番号の対応表が、作業領域Tに格納される（ステップＳ６５０１）。
次に、誤差リストによる探索範囲の下限が、作業領域ａに格納される（ステップＳ６５０２）。
次に、誤差リストによる探索範囲の上限が、作業領域ｂに格納される（ステップＳ６５０３）。
また、探索の対象となる識別子または番号が、作業領域ｘに格納される（ステップＳ６５０４）。
さらに、作業領域ａの値と作業領域ｂの値の平均値(a+b)/2に最も近い整数が、作業領域cに格納される（ステップＳ６５０５）。
その後、ステップＳ６５０６で作業領域iに初期値0（ゼロ）が格納された後、ステップＳ６５０８で+1ずつインクリメントされながら、ステップＳ６５０７でｘとf(c)の対がTに含まれると判断されるまで、下記の処理が繰り返し実行される。
すなわち、まず作業領域cの値が、作業領域ａの値と作業領域ｂの値の平均値(a+b)/2以下であるか否かが判定される（ステップＳ６５０９）。
そして、ステップＳ６５０９の判定がＮＯならばステップＳ６５１０で作業領域cの値にiが加算され、ステップＳ６５０９の判定がＹＥＳならばステップＳ６５１１で作業領域cの値からiが減算される。
以上の繰返し動作の結果、ｘとf(c)の対がTに含まれその結果ステップＳ６５０７の判定がＹＥＳになると検索処理が終了する。
以上説明した第１２の実施形態において、例えば、前述した｛1627以上2^16-1未満の素数｝の集合のように、上述の回帰分析による一次近似式の当てはまりが元々よい場合は、関数による変換は行わず、必要に応じて誤差の大きい方から素数を個別識別子の集合から除外する事で、一次近似式の当てはまりが比較的容易に改善される。
｛1627以上2^16-1未満の素数｝の集合の要素数は6000より多い上に、第６の実施形態により複数（a 個）の32 bits 領域を使う事で、対応できる管理対象の数は、１つの領域で対応できる数のa 乗に出来る。このため、仮に１つの領域内で使用する素数の数を数百程度に絞っても32bits 領域２つなら数万から数十万の管理対象に対応できる。このように第６の実施形態を前提にする場合、使用する素数に別の特徴を付けても、第２，第３の実施形態と比較して、「小さいか同等の大きさの領域で、より多くの管理対象に対応可能」という特徴は、容易に保つ事ができる。
さらに、大きさにより複数の範囲に分ける事によっても、一次近似式の当てはまりは確実に改善できる。
関数による変換は、一次近似式では当てはまりが悪い場合（番号と個別識別子の各々の集合の間の統計的な関係の非線形性が大きい場合）に、大きさで個別識別子の集合を分割する数を減らし、番号を求める際の条件判定処理のオーバヘッドを削減できる。
なお、本実施形態ではデータが整数なので、近似式が全ての入力データに対し「誤差が0.5より小さい」という条件を満たせば、近似式の整数部を取る事により「完全ハッシュ関数」を得ることができる。
「完全ハッシュ関数」にはならないとしても、探索範囲を「近似値周辺の固定幅」の範囲に限定する事ができる。すなわち、メモリ参照量を固定値の範囲内に収められる。
＜第１３の実施形態＞
次に、第１３の実施形態について説明する。
本実施形態は、第１１の実施形態と同様、第５または第６の実施形態における集団識別子（の成分）から個別識別子を求める計算の高速化に関する工夫を含む実施形態である。第１１の実施形態でも説明したように、「分解能が上限k で制限される場合」でかつ演算を乗法とする際の基本的アイデアは、「素因数分解の一意性」を利用して、乗法でのリダクションで計算された集団識別子から、個別識別子を取り出す事である。従って、「素因数分解」の所要時間がシステムの処理性能の高速化に際して重要な因子となる。
例えば、個別識別子の成分に、管理対象の番号を格納する多次元配列のインデックスを対応させる事により、第６の実施形態のように個別識別子が複数の成分を持つ場合を、成分が１つしかない第５の実施形態の場合と同様に取り扱う事ができる。以下では、特に断らない限り、成分数が１として説明する。
第１１の実施形態では、集団識別子から個別識別子を求める際、個別識別子の集合（ないし、その成分）の要素を順次選んで集団識別子（ないし、その成分）への除法を順次実行する事を前提として、その枠内での高速化手法を利用した。従って、特に個別識別子（の成分）が素数の場合は「因数になりうる素数で順次割る方法」（ brute force method ）が前提となる。
本実施形態では、例えば以下のようなbrute force method 以外の素因数分解アルゴリズムの一つまたは複数の組み合わせを使用する（組み合わせる際はbrute force method との組み合わせを含めてもよい）。これらのアルゴリズムに共通する特徴（すなわち、brute force method との相違点）は、「因数になりうる素数の集合」を入力として使用しない事である。
ρ method (「擬似乱数列」を使用する方法)
p-1 method (素数p に対し、p-1 が比較的小さい素因数を持つ場合に有効な方法)
p+1 method (素数p に対し、p+1 が比較的小さい素因数を持つ場合に有効な方法)
Fermat's method (素因数が元の数の平方根に近い場合に有効な方法)
連分数法(Continued Fraction Method)
複数多項式二次ふるい法（MPQS: Multiple Polynomial Quadratic Sieve Method）
楕円曲線法（ECM: Elliptic Curve Method）
これらのアルゴリズム自体は、例えば下記文献[7]に示されるように、「整数論」という数学の分野での命題、あるいは計算機科学での基本的なアルゴリズムとして、広く知られている。
[7] Donald E. Knuth,"The Art of Computer Programming, Volume 2"
ただし、「整数論」の問題としての「素因数分解」として、すなわち「素数か否か分かっているとは限らない任意の整数を入力として与えられた、素因数を少なくとも１つ求める操作」としては、あまり使われないアルゴリズムもある。それは、「特定少数の場合以外は遅い」、ないし「特定少数の場合以外、素因数を求められない」アルゴリズムは、「素因数分解の対象となる数が任意に選ばれる」という一般的な状況には適さないためである。
しかし、本実施形態においては、個別識別子（の成分）の集合を「使用するアルゴリズムで、高速に素因数が少なくとも１つ求められる」ように選んでおく事で目的が達せられるため、通常の整数論の問題としての素因数分解のアルゴリズムとしては一般性に乏しいとされる方法(p-1 method, p+1 method, Fermat's method など) も効果的に使用できる。例えば、Fermat's method は、素因数が元の数の平方根に近い場合に限り高速である事が知られているので、分解能k = 2 の場合に個別識別子（の成分）の大きさを可能な限り揃えておく事で有効に利用できる。
なお、brute force method 以外の素因数分解アルゴリズムでは、素因数を求めた後、管理対象の番号は別途取得される。
図６６は、brute force method 以外のアルゴリズムにより、所与の整数の素因数を少なくとも１つ求める処理の例を示すフローチャートである。
まず、作業領域Lに、空リストが格納される（ステップＳ６６０１）。
次に、作業領域Xに、集団識別子が格納される（ステップＳ６６０２）。
次に、作業領域pに、作業領域Xの値の素因数の１つが格納される（ステップＳ６６０３）。
そして、ステップＳ６６０４で作業領域iに初期値1が格納された後（ステップＳ６６０４）、ステップＳ６６０７で作業領域iの値が+1ずつインクリメントされながら、ステップＳ６６０６で作業領域pの値が作業領域Xの値を割りきらなくなったと判定されるまで、ステップＳ６６０５からステップＳ６６０７までの一連の処理が繰り返し実行される。
この繰返し処理において、まず、作業領域Xの値を作業領域pの値で除算した結果(X/p)が、新たに作業領域Xに格納される（ステップＳ６６０５）。
次に、作業領域pの値が作業領域Xの値を割りきったか否かが判定される（ステップＳ６６０６）。
ステップＳ６６０６の判定がＹＥＳならば、作業領域iの値が+1インクリメントされ、ステップＳ６６０５が再度実行される。
以上の繰返し処理の結果、ステップＳ６６０６の判定がＮＯになると、作業領域Lに、集団識別子の素因数と指数の対(p,i)が要素として追加される（ステップＳ６６０８）。
その後、作業領域Xの値が、乗法演算の単位元1に等しくなったか否かが判定される（ステップＳ６６０９）。
ステップＳ６６０９の判定がＮＯならば、ステップＳ６６０３の処理に戻り、作業領域Xの次の素因数の１つについて処理が繰り返される。
ステップＳ６６０９の判定がＹＥＳになると、図６６のフローチャートの処理が終了する。
以上のようにして、第１３の実施形態において、「因数になりうる素数の集合」を入力として使用しない素因数分解のアルゴリズムの利用により、個別識別子から集団識別子を求める際に、「因数になりうる数の表」を参照する方法に比べてメモリ参照量が削減できる。特に分解能k あるいは個別識別子の成分に使われる素数の一方ないし両方が大きいために「因数分解すべき集団識別子」が大きい場合に、高速化と処理負荷の軽減の両面で有効である。
＜第１４の実施形態＞
最後に、第１４の実施形態について説明する。
本実施形態は、第１１の実施形態および第１３の実施形態と同様に、第５または第６の実施形態における集団識別子から個別識別子を求める計算の高速化に関する工夫を含む実施形態である。
例えば、個別識別子の成分に、管理対象の番号を格納する多次元配列のインデックスを対応させる事により、第６の実施形態のように個別識別子が複数の成分を持つ場合を、成分が１つしかない第５の実施形態の場合と同様に取り扱う事ができる。以下では、特に断らない限り、成分数が１として説明する。
本実施形態は「量子コンピュータ（量子ビット(qubit) による計算を行う演算装置を備える計算機）」が受信側ノードであるシステム構成を前提とする。
第５、第６の実施形態での集団識別子（の成分）からの個別識別子（の成分）の特定を、ショアのアルゴリズム(Shor's algorithm) による素因数分解を利用して行うために、量子ビットを使用した計算を行う演算装置を使用する。下記の文献[8]には、「多項式時間で（＝従来の計算機では不可能な程度に高速な時間）」で素因数分解を量子計算機上で行う「ショアのアルゴリズム」が開示されている。
[8] Peter W. Shor,"Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer",SIAMJournal on Computing Volume 26 Issue 5, Oct. 1997, Pages 1484-1509
添付資料の "5 Prime factorization" を含むページ。
図６７は、第１３および第１４の実施形態の相違点の説明図である。第１３の実施形態は、通常のbitを操作する一般的なCPUとメモリとを備える通常の計算機を用いて、図６７（ａ）に示されるような、brute force method 以外の素因数分解アルゴリズムを実行する計算機が、図４の識別子集約機構４０１または識別子分析機構４０２を実現する。一方、第１４の実施形態は、通常のbitを操作する一般的なCPUとメモリに加えて、量子bit(Qubit)を操作する演算装置である量子計算機を搭載し、この量子計算機が、図４の識別子集約機構４０１または識別子分析機構４０２を実現する。
ここでの「量子計算機」は、独立した計算機であってもよいし、図６７（ｂ）に示されるように、「「ショアのアルゴリズム」による素因数分解を実行する機能しか持たない補助プロセッサ」としての演算装置であってもよい。
なお、「ショアのアルゴリズム」は、素因数分解の過程で「因数となりうる数」の表を引くわけではないので、求めた素因数から管理対象の番号を求める手順は別途実行される。
以上説明した第１４の実施形態により、量子コンピュータでショアのアルゴリズムをも散ることにより、「（素因数分解の対象となる数の大きさに対して）多項式時間」で素因数分解を行う事ができる。すなわち、素因数分解の処理時間が、一般に素因数分解の対象となる数の大きさを変数とする多項式で表せる程度の大きさに留まる。
既知の量子コンピュータを使用しない方法での素因数分解は、全て「準指数時間」かかる（入力データの大きさを引数とする指数関数と同じ程度の割合で計算時間が増加する）。
しかし、因数分解の対象となる数が知られている他の方法で現実的な処理時間で素因数分解できない大きさの場合でも、量子コンピュータでショアのアルゴリズムを使えば、現実的な処理時間で素因数分解を行う事が可能となる。
従って、本実施形態は「集団識別子から個別識別子を求める処理」が、「因数分解すべき集団識別子の成分」が他の実施形態で現実的な処理時間内には扱えないほど大きい場合」を現実的な処理時間内に扱える。すなわち、第５、第６の実施形態で扱える管理対象の数を桁違いに大きくできるほか、分解能k も大きくできる。例えば、大規模疎行列の分散並列計算への図４の識別子集約機構４０１と識別子分析機構４０２の適用では、状態監視への適用に比べて大きな分解能k が必要な場合が多いと考えられるため、本実施形態は特に有効である。
現在、素因数分解の実用的応用として、公開鍵暗号系での鍵交換において、大きな２つの素数の組p,q に対し、積pq を公開してもp,q は従来型のコンピュータでは容易に計算できないため「秘密鍵」と見なせる事が利用されている。この応用は、量子コンピュータでのショアのアルゴリズムを使う素因数分解が普及すれば価値を失う。一方、本実施形態では、量子コンピュータによる素因数分解の高速実行は、適用可能な範囲の拡大につながる。
＜その他の実施形態＞
前述したように、第１から第１４の各実施形態は、必ずしも相互に排他的ではなく、必要に応じて組み合わせることが可能である。
前述したように、図４の識別子集約機構４０１および識別子分析機構４０２は、図７、図２０、図２１、または図２２の情報集約システムを構成するノード７０１または７０２のCPU７０１−１または７０２−１のソフトウェア処理によって実現できる。この場合、図７の各ノード７０１または７０２あるい中継装置７０３に記録媒体読み取り装置を備えて、磁気ディスク、光ディスク、光磁気ディスク、及びＵＳＢメモリ等の記録媒体に含まれる制御プログラムを読み出させる。記録媒体読み取り装置により読み出された制御プログラムは、直接、あるいは中継装置７０３から通信線７０４を介して、所定のノード７０１または７０２のメモリ７０１−２または７０２−２に記録される。CPU７０１−１または７０２−１は、メモリ７０１−２または７０２−２に記録された制御プログラムを実行することで、第１〜第１４の実施形態に従った図４の識別子集約機構４０１および識別子分析機構４０２の機能を実現する。
以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
送信側ノードに設けられ、情報の通知元に固有の個別識別子と、前記情報の通知元からの前記個別識別子による通知を集約して集団識別子とを生成して送信する識別子集約機構と、
受信側ノードに設けられ、前記集団識別子を受信し前記個別識別子を復元する処理と、前記個別識別子から前記情報の通知元を特定する処理を実行する識別子分析機構と、
を備えることを特徴とする情報集約システム。
（付記２）
前記識別子集約機構は、前記送信側ノードが管理する前記情報の通知元にて前記情報を通知すべき条件が成立したときに前記通知元に固有の個別識別子を生成し、前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信し、生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信し、
前記識別子分析機構は、前記送信側ノードが送信した集団識別子を受信し、受信した前記集団識別子から前記集団識別子の生成因子である１つ以上の前記個別識別子を復元し、復元したそれぞれの前記個別識別子から前記通知元の通知を復元する、
ことを特徴とする付記１に記載の情報集約システム。
（付記３）
前記識別子集約機構は、前記送信側ノードが前記ネットワーク上の起点ノードである場合には、前記リダクション演算において前記集団識別子の代わりに第１の既定値を入力し、前記送信側ノードが管理する前記情報の通知元にて前記情報を通知すべき条件が成立していないときには、前記リダクション演算において前記個別識別子の代わりに第２の既定値を入力する、
ことを特徴とする付記２に記載の情報集約システム。
（付記４）
前記第１の既定値および前記第２の既定値は、前記リダクション演算における単位元である、
ことを特徴とする付記２または３に記載の情報集約システム。
（付記５）
前記識別子集約機構に、ネットワークまたは当該ネットワークに接続されたノードの通信装置上に具備されるノード間演算機構を用い、
前記集団識別子の送信と受信に対してバリア同期を実行する同期機構をさらに備える、
ことを特徴とする付記１ないし４のいずれかに記載の情報集約システム。
（付記６）
送信側で予めグループ内の管理対象に対して論理和を実行しておく、
ことを特徴とする付記１ないし５のいずれかに記載の情報集約システム。
（付記７）
前記送信側ノードに、複数の整数からなる順序付けられた組を対応させる、
ことを特徴とする付記１ないし６のいずれかに記載の情報集約システム。
（付記８）
前記識別子集約機構は、前記個別識別子の割当てに、代数的整数の素因数分解の一意性と乗法を利用する、
ことを特徴とする付記１ないし７のいずれかに記載の情報集約システム。
（付記９）
前記識別子集約機構は、前記個別識別子の割当てに、代数的整数の素因数分解の一意性と加法を利用する、
ことを特徴とする付記１ないし７のいずれかに記載の情報集約システム。
（付記１０）
前記識別子分析機構は、前記代数的整数の加算を用いて、受信した前記集団識別子から前記個別識別子を復元する、
ことを特徴とする付記９に記載の情報集約システム。
（付記１１）
識別子の集合を複数のグループに分ける、
ことを特徴とする付記１ないし１０のいずれかに記載の情報集約システム。
（付記１２）
回帰分析または離散フーリエ変換を利用して、前記識別子に関する検索処理での探索範囲を絞り込む、
ことを特徴とする付記１１に記載の情報集約システム。
（付記１３）
前記識別子分析機構は、因数になりうる素数の集合を入力として使用しない素因数分解アルゴリズムを用いて、前記集団識別子から前記個別識別子を復元する、
ことを特徴とする付記１ないし７に記載の情報集約システム。
（付記１４）
前記受信側ノードが量子コンピュータである、
ことを特徴とする付記１ないし７に記載の情報集約システム。
（付記１５）
ネットワークに接続され情報の通知を行う送信側ノードのコンピュータに、
前記送信側ノードが管理する前記情報の通知元にて前記情報を通知すべき条件が成立したときに前記通知元に固有の個別識別子を生成する処理と、
前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信する処理と、
生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信する処理と、
を実行させるためのプログラム。
（付記１６）
ネットワークに接続され情報の集約を行う受信側ノードのコンピュータに、
送信側ノードが送信した集団識別子を受信する処理と、
受信した前記集団識別子から前記集団識別子の生成因子である１つ以上の前記個別識別子を復元する処理と、
復元したそれぞれの前記個別識別子から前記通知元の通知を復元する処理と、
を実行させるためのプログラム。
（付記１７）
送信側ノードにて、情報の通知元に固有の個別識別子と、前記情報の通知元からの前記個別識別子による通知を集約して集団識別子とを生成して送信する識別子集約処理を実行し、
受信側ノードにて、前記集団識別子を受信し前記個別識別子を復元する処理と、前記個別識別子から前記情報の通知元を特定する処理を実行する識別子分析処理を実行する、
ことを特徴とする情報集約方法。
（付記１８）
前記識別子集約処理において、前記送信側ノードが管理する前記情報の通知元にて前記情報を通知すべき条件が成立したときに前記通知元に固有の個別識別子を生成し、前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信し、生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信し、
前記識別子分析処理において、前記送信側ノードが送信した集団識別子を受信し、受信した前記集団識別子から前記集団識別子の生成因子である１つ以上の前記個別識別子を復元し、復元したそれぞれの前記個別識別子から前記通知元の通知を復元する、
ことを特徴とする付記１７に記載の情報集約方法。
１０１ 管理対象
１０２、２０１ 送信側ノード
１０３、２０２ 受信側ノード
１０４ Gather
１０５ リダクション
２０３ NIC(Network Interface Controller)
２０４、７０１−１、７０２−１、１４０１ CPU(Central Processing Unit)
２０５ コンテクスト
２０６ 階層化された送信側ノード
４０１ 識別子集約機構
４０２ 識別子分析機構
４０３ 識別子のコード化体系
４０４ リダクション
７０１ 送信起点ノード
７０２ 受信・中継ノード
７０３ 中継装置
７０４ 通信線
７０１−２、７０２−２、１４０２ メモリ
７０１−３、７０２−３ NIC
１４０３ 入力装置
１４０４ 表示装置
１４０５ 外部記憶装置
１４０６ 記録媒体書き込み装置
１４０７ 通信インタフェース
１４０８ バス
１４０９ 記録媒体
２００１ 独立筐体型ノード間演算装置
２１０１ ノード内蔵型のノード間演算装置
２２０１ ノード間演算機能を持つネットワーク・インターフェース

Claims (14)

  1. ネットワーク上の送信側ノードに設けられる識別子集約機構であって、
    予め定められていた事象が、前記送信側ノードが管理する情報の通知元にて発生したときに、前記通知元に固有の個別識別子を生成し、
    前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信し、
    生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信し、
    前記送信側ノードが前記ネットワーク上の起点ノードである場合には、前記リダクション演算において前記集団識別子の代わりに第１の既定値を入力し、
    前記事象が前記通知元にて発生していないときには、前記リダクション演算において前記個別識別子の代わりに第２の既定値を入力する、
    該識別子集約機構と、
    前記ネットワーク上の受信側ノードに設けられる識別子分析機構であって、前記送信側ノードが送信した集団識別子を受信し、受信した前記集団識別子から前記集団識別子の生成因子である１つ以上の前記個別識別子を復元し、復元したそれぞれの前記個別識別子から前記通知元の通知を復元する該識別子分析機構と、
    を備えることを特徴とする情報集約システム。
  2. 前記第１の既定値および前記第２の既定値は、前記リダクション演算における単位元である、
    ことを特徴とする請求項１に記載の情報集約システム。
  3. 前記識別子集約機構に、ネットワークまたは当該ネットワークに接続されたノードの通信装置上に具備されるノード間演算機構を用い、
    前記集団識別子の送信と受信に対してバリア同期を実行する同期機構をさらに備える、
    ことを特徴とする請求項１または２に記載の情報集約システム。
  4. 送信側で予めグループ内の管理対象に対して論理和を実行しておく、
    ことを特徴とする請求項１ないし３のいずれかに記載の情報集約システム。
  5. 前記送信側ノードに、複数の整数からなる順序付けられた組を対応させる、
    ことを特徴とする請求項１ないし４のいずれかに記載の情報集約システム。
  6. 前記識別子集約機構は、前記個別識別子の割当てに、代数的整数の素因数分解の一意性と乗法を利用する、
    ことを特徴とする請求項１ないし５のいずれかに記載の情報集約システム。
  7. 前記識別子集約機構は、前記個別識別子の割当てに、代数的整数の素因数分解の一意性と加法を利用する、
    ことを特徴とする請求項１ないし５のいずれかに記載の情報集約システム。
  8. 前記識別子分析機構は、前記代数的整数の加算を用いて、受信した前記集団識別子から前記個別識別子を復元する、
    ことを特徴とする請求項７に記載の情報集約システム。
  9. 識別子の集合を複数のグループに分ける、
    ことを特徴とする請求項１ないし８のいずれかに記載の情報集約システム。
  10. 回帰分析または離散フーリエ変換を利用して、前記識別子に関する検索処理での探索範囲を絞り込む、
    ことを特徴とする請求項９に記載の情報集約システム。
  11. 前記識別子分析機構は、因数になりうる素数の集合を入力として使用しない素因数分解アルゴリズムを用いて、前記集団識別子から前記個別識別子を復元する、
    ことを特徴とする請求項１ないし５に記載の情報集約システム。
  12. 前記受信側ノードが量子コンピュータである、
    ことを特徴とする請求項１ないし５に記載の情報集約システム。
  13. ネットワーク上の送信側ノードとして用いられるコンピュータに、
    予め定められていた事象が、前記送信側ノードが管理する情報の通知元にて発生したときに、前記通知元に固有の個別識別子を生成する処理と、
    前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信する処理と、
    生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信する処理と、
    前記送信側ノードが前記ネットワーク上の起点ノードである場合に、前記リダクション演算において前記集団識別子の代わりに第１の既定値を入力する処理と、
    前記事象が前記通知元にて発生していないときに、前記リダクション演算において前記個別識別子の代わりに第２の既定値を入力する処理と、
    を実行させるためのプログラム。
  14. ネットワーク上の送信側ノードによって実行される識別子集約処理であって、
    予め定められていた事象が、前記送信側ノードが管理する情報の通知元にて発生したときに、情報の通知元に固有の個別識別子を生成する処理と、
    前記送信側ノードが前記ネットワーク上の起点ノードでない場合に他の前記送信側ノードが送信した集団識別子を受信する処理と、
    生成した前記個別識別子と受信した前記集団識別子とに対してリダクション演算を実行することにより前記個別識別子と前記集団識別子とが集約された新たな前記集団識別子を生成して前記ネットワーク上のノードに送信する処理と、
    前記送信側ノードが前記ネットワーク上の起点ノードである場合に、前記リダクション演算において前記集団識別子の代わりに第１の既定値を入力する処理と、
    前記事象が前記通知元にて発生していないときに、前記リダクション演算において前記個別識別子の代わりに第２の既定値を入力する処理と、
    を含む該識別子集約処理を前記送信側ノードが実行し、
    前記ネットワーク上の受信側ノードによって実行される識別子分析処理であって、前記送信側ノードが送信した集団識別子を受信し、受信した前記集団識別子から前記集団識別子の生成因子である１つ以上の前記個別識別子を復元し、復元したそれぞれの前記個別識別子から前記通知元の通知を復元する該識別子分析処理を前記受信側ノードが実行する、
    ことを特徴とする情報集約方法。
JP2014118467A 2014-06-09 2014-06-09 情報集約システム、プログラム、および方法 Active JP6417727B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014118467A JP6417727B2 (ja) 2014-06-09 2014-06-09 情報集約システム、プログラム、および方法
US14/719,360 US9847913B2 (en) 2014-06-09 2015-05-22 System and method for gathering information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014118467A JP6417727B2 (ja) 2014-06-09 2014-06-09 情報集約システム、プログラム、および方法

Publications (2)

Publication Number Publication Date
JP2015233178A JP2015233178A (ja) 2015-12-24
JP6417727B2 true JP6417727B2 (ja) 2018-11-07

Family

ID=54770457

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014118467A Active JP6417727B2 (ja) 2014-06-09 2014-06-09 情報集約システム、プログラム、および方法

Country Status (2)

Country Link
US (1) US9847913B2 (ja)
JP (1) JP6417727B2 (ja)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033801B2 (en) * 2015-02-12 2018-07-24 Mellanox Technologies, Ltd. Associative summing for high performance computing
WO2016161220A1 (en) * 2015-04-01 2016-10-06 Microsoft Technology Licensing, Llc Efficient topological compilation for metaplectic anyon model
JP6597231B2 (ja) * 2015-11-27 2019-10-30 富士通株式会社 演算装置、プログラム、情報処理方法
KR102520502B1 (ko) * 2016-08-02 2023-04-12 엑스-로고스, 엘엘씨 기하 대수학을 이용한 강화된 데이터-중심 암호화 시스템을 위한 방법 및 시스템
US11044181B1 (en) * 2016-08-02 2021-06-22 Initial State Technologies, Inc. Data aggregation, transformation and visualization of networked broadcast reports
JP2018160180A (ja) * 2017-03-23 2018-10-11 富士通株式会社 情報処理システム、情報処理装置および情報処理システムの制御方法
JP6870487B2 (ja) * 2017-06-13 2021-05-12 富士通株式会社 情報処理システム及び情報処理方法
JP6874564B2 (ja) * 2017-06-27 2021-05-19 富士通株式会社 情報処理システム、管理装置及びプログラム
US10313495B1 (en) * 2017-07-09 2019-06-04 Barefoot Networks, Inc. Compiler and hardware interactions to remove action dependencies in the data plane of a network forwarding element
US10721167B1 (en) 2017-10-09 2020-07-21 Barefoot Networks, Inc. Runtime sharing of unit memories between match tables in a network forwarding element
JP7077839B2 (ja) * 2018-07-18 2022-05-31 富士通株式会社 並列処理装置、リダクション演算システム及びリダクション演算方法
US10694217B2 (en) * 2018-09-21 2020-06-23 Intel Corporation Efficient length limiting of compression codes
US11122136B2 (en) 2018-10-22 2021-09-14 Red Hat, Inc. Quantum payload service for facilitating communications between a quantum computing system and classical computing systems
US11144334B2 (en) 2018-12-20 2021-10-12 Red Hat, Inc. Quantum computer task manager
JP7278084B2 (ja) * 2019-01-29 2023-05-19 キヤノン株式会社 情報処理装置および情報処理方法ならびにプログラム
CN111858017A (zh) * 2019-04-30 2020-10-30 伊姆西Ip控股有限责任公司 用于处理任务的方法、设备和计算机程序产品
US11309974B2 (en) 2019-05-09 2022-04-19 Red Hat, Inc. Quantum channel routing utilizing a quantum channel measurement service
US11005654B2 (en) * 2019-05-14 2021-05-11 Google Llc Outsourcing exponentiation in a private group
WO2020231590A1 (en) * 2019-05-14 2020-11-19 Blayne Lequeux Healthcare data cloud system, server and method
JP7277756B2 (ja) * 2019-08-02 2023-05-19 富士通株式会社 情報処理装置
US11886380B2 (en) 2020-04-27 2024-01-30 Red Hat, Inc. Quantum file management system
US11416221B2 (en) 2020-05-12 2022-08-16 Red Hat, Inc. Quantum entanglement protection
US11676059B2 (en) 2020-06-23 2023-06-13 Red Hat, Inc. Performing quantum file pattern searching
US11556833B2 (en) 2020-06-25 2023-01-17 Red Hat, Inc. Performing quantum file concatenation
US11580247B2 (en) 2020-06-25 2023-02-14 Red Hat, Inc. Systems and methods for quantum file permissions
US11562283B2 (en) 2020-06-25 2023-01-24 Red Hat, Inc. Performing quantum file copying
CN113238856B (zh) * 2021-03-09 2022-07-26 西安奥卡云数据科技有限公司 一种基于rdma的内存管理方法及装置

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09298543A (ja) 1996-05-02 1997-11-18 Sumitomo Electric Ind Ltd ネットワーク管理システムおよび中間管理装置
JP2004072271A (ja) * 2002-08-02 2004-03-04 Kyushu Ando Denki Kk 機器管理システム及び方法
US20050071457A1 (en) * 2003-08-27 2005-03-31 Siew-Hong Yang-Huffman System and method of network fault monitoring
JP2005204290A (ja) * 2003-12-18 2005-07-28 Omron Corp 通信機能付き情報機器への特定情報の登録方法と登録システム、登録装置と通信機能付き情報機器、ならびに特定情報管理方法とシステム
JP2007235243A (ja) * 2006-02-27 2007-09-13 Brother Ind Ltd 情報通信システム、情報収集方法、ノード装置、及びノード処理プログラム
US20080109569A1 (en) * 2006-11-08 2008-05-08 Sicortex, Inc Remote DMA systems and methods for supporting synchronization of distributed processes in a multi-processor system using collective operations
WO2008093690A1 (ja) * 2007-02-02 2008-08-07 Nec Corporation 分散情報生成装置、復元装置、復元結果検証装置、秘密情報分散システム、方法およびプログラム
US20110047272A1 (en) * 2007-03-09 2011-02-24 Anne-Marie Bosneag Dissemination of Network Management Tasks in a Distributed Communication Network
JP5331898B2 (ja) * 2009-11-12 2013-10-30 富士通株式会社 並列計算用の通信方法、情報処理装置およびプログラム
US8639802B2 (en) * 2010-04-30 2014-01-28 Brocade Communications Systems, Inc. Dynamic performance monitoring
US8634314B2 (en) * 2010-07-30 2014-01-21 Cisco Technology, Inc. Reporting statistics on the health of a sensor node in a sensor network
JP5737075B2 (ja) * 2011-08-29 2015-06-17 富士通株式会社 イベント収集方法及び情報処理装置
US9135208B1 (en) * 2012-04-13 2015-09-15 Olympus Corporation Method and system for group management
US9411633B2 (en) * 2012-07-27 2016-08-09 Futurewei Technologies, Inc. System and method for barrier command monitoring in computing systems
WO2014193950A1 (en) * 2013-05-28 2014-12-04 Convida Wireless, Llc Data aggregation

Also Published As

Publication number Publication date
JP2015233178A (ja) 2015-12-24
US20150358219A1 (en) 2015-12-10
US9847913B2 (en) 2017-12-19

Similar Documents

Publication Publication Date Title
JP6417727B2 (ja) 情報集約システム、プログラム、および方法
US8344916B2 (en) System and method for simplifying transmission in parallel computing system
US6115716A (en) Method for implementing an associative memory based on a digital trie structure
JPH06259223A (ja) 分散データ処理システム
Jiang et al. A novel quantum image compression method based on JPEG
US11424760B2 (en) System and method for data compaction and security with extended functionality
CN110059129A (zh) 数据存储方法、装置及电子设备
US11831343B2 (en) System and method for data compression with encryption
US20230283292A1 (en) System and method for data compaction and security with extended functionality
Ahmed et al. Hardware based string matching algorithms: A survey
US11995040B2 (en) Multi-node storage system and method data de-duplication method for the same
JP5852594B2 (ja) 多倍長整数演算装置、多倍長整数演算方法、プログラム
Zeng et al. Detecting affine equivalence of Boolean functions and circuit transformation
Yang et al. Private and secure coded computation in straggler-exploiting distributed matrix multiplication
Shen Optimal realization of any BPC permutation on k-extra-stage Omega networks
Pantaleoni A massively parallel algorithm for constructing the BWT of large string sets
Kang et al. Analyzing multi-trillion edge graphs on large gpu clusters: A case study with pagerank
Sugier Implementation efficiency of BLAKE2 cryptographic algorithm in contemporary popular-grade FPGA devices
US11967974B2 (en) System and method for data compression with protocol adaptation
McCoy et al. Singleton Sieving: Overcoming the Memory/Speed Trade-Off in Exascale κ-mer Analysis
US20240113728A1 (en) System and method for data compaction and security with extended functionality
CN117376403B (zh) 一种云端数据迁移方法及系统
US8321823B2 (en) System and method for designing architecture for specified permutation and datapath circuits for permutation
Kim et al. Dual pattern compression using data-preprocessing for large-scale gpu architectures
US20240056286A1 (en) Homomorphic encryption calculating accelerator and encryption system including the same

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170309

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180223

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180306

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180426

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180911

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180924

R150 Certificate of patent or registration of utility model

Ref document number: 6417727

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150