（様式 20）成果報告書

平成 26 年度 TSUBAME 産業利用トライアルユース 成果報告書

利用課題名 大容量の行動関連データを使った最適シミュレーション及び暗黙知の利用
英文：Tacit knowledge and use of optimal simulation using large amounts of data related behavior
佐々木 武
Takeshi Sasaki
所属
株式会社 電通国際情報サービス
Information Service International-Dentsu,Ltd.
URL http://www.isid.co.jp

我々の課題は、膨大なデータが日々蓄積される今日の消費者生活において、広告業務の媒体計画作成に携わる人向けの業務システムを提供しており、顧客が求める期日迄に媒体計画を策定する機能を実現することが困難なケースがあるということである。昨年度、シンプルな課題において高速化が図れたが、より複雑な条件における高速化を目指し、CPU レベルの並列化、GPU レベルの並列化をチューニング検証することが今回の目的である

Keywords:

Media-Mix Optimized Media Planning Unit- Vehicle

背景と目的
広告キャンペーンにおいて、様々な条件 例えば、「地概要
媒体計画立案のための条件を下記のようにした。

区」、「媒体種類」、「媒体予算」、「媒体出稿期間」、「最適化

広告ターゲット＝「４歳以上男性または女性」

指標」などがあり、その条件から媒体への接触ローデータを

広告出稿エリア＝「関東エリア」

元に、ビジネスロジックの実装をコンピュターリソースを用い

対象媒体 A 案＝「TV」、「ラジオ」て最適化された媒体計画を算出するアプリケーションを

対象媒体 B 案＝「TV」、「ラジオ」、「雑誌」、「新聞」、我々は提供している。昨今の広告媒体の状況は取り分け「屋外・交通」、「Internet」

Internet 媒体の種類の多さ、ビジネス・ルールの複雑さな

各媒体は スポット広告も番組に見立てて集計

どがめまぐるしい速さで変わっており、媒体組合せが膨大で

出稿予算 A 案＝「１億円」（各媒体 10%刻みで構成）あり、日々増大している。複数の媒体及びその個々メニュー



出稿予算 B 案＝「１億円」（各媒体 10%刻みで構成）のうち、目標に対し最適化された媒体計画を出力するため

最適化指標＝広告接触回数「３回」に掛ける時間が膨大になりつつある。集計時間を待つ非効

最適化目標＝最適化指標到達率「３５％」率性と機械損失を含めた



予算許容指数＝１．２（倍）これらの条件を元に、最適化された媒体計画を算出する。
本プロジェクトでは、昨年度の TSUBAME 上での実行時間「４時間５８分」に対し半分の時間「２時間３０分」を目標に、２倍の処理速度を得るために 既存のボトルネック部分CPU の並列化を行い、GPU 演算に回る部分も大きな分岐の単位で並列化をめざす。

（様式 20）成果報告書
結果および考察◆新たな処理概要は下記に処理概要フローを示す。

◆現行の処理概要は下記に処理概要フローを示す。

（A 案）

（A 案）

●CPU 並列処理導入●CPU 処理の中に GPU 処理への変更【広告ターゲット（標的）処理】

条件

サンプル
属性マスタ

【TV媒体処理】条件

標的：該当サンプル

番組候補

TV

番組ｘ個人
広告効果CPU並列処理C
P
U
1

統合処理

TV番組ｘ個人広告効果

GPU
1【ラジオ媒体処理】
番組候補条件

ラジオ番組ｘ個人広告効果

CP
U
２

統合処理

TV番組ｘ個人広告効果

GPU
２

共通の処理は、従来型の GPGPU の処理内容を踏襲。
GPGPU の（B 案）の場合（A 案）においては、「TV」「ラジオ」の組合せが２媒体で固定されていたので、最終的な GPGPU の処理は、１つの組合せブロックのまま処理するだけで済む。

（B 案）の場合においては、６媒体の並列処理を行う。
この場合、組合せが少ない媒体新聞などは、他媒体より先に終了するが、全媒体の組合せ最適を行うには全部が終了することが必要になる。そのため、管理機能を新たに構築して、「媒体組合せ」、「予算比の組合せ」、「GPU 集計の制御」、「共通部分の GPU 結果共有」、「GPU 結果の保存」の機能を管理機能側が制御し、GPU の演算分と切り分ける。（様式 20）成果報告書
Step5: 「従系」媒体および予算の組合わせを CPU の◆管理機構概要

管理機能が組合せを作成し、「GPU に処理依頼」を実行する。その際、「主系」の結果を共有し無駄な演算をせずに済むようにする。
Step6: 「従系」媒体の集計が終了した場合、結果を管理機構に戻す。
Step7: 管理機構は「従系」で「未集計」の組合せを、新たに GPU に割り当て集計処理を実施する
Step8： 全ての割り当ての集計が終了したら、集計結果をファイルに出力し終了する。
【各 GPU での処理】
GPGPU で処理する主要処理の概念図。

※ 複数媒体の媒体組合せは集計開始時に条件指定できる。
Step1: 全ての媒体において、単媒体の処理を集計する。
Step2: 単媒体処理が終わったもので、２媒体の組合せが可能なものを「主系」とし、アサイン可能な CPU に対して処理を指示する。
Step3： 「主系」の「予算比率」分の組合せ演算を「GPU」で集計する。
Step4: その結果を共通で利用するため一度 CPU 側のメモリに保存する

（様式 20）成果報告書
実測度の計測：の効率が落ちている。この部分は、複数媒体の組合せ集計

１） MPI による CPU 側処理の並列化の影響調査（同一条件での試行回数 5 回の平均値）

において「管理機能」が存在するオーバーヘッドが、若干発生している。

【A 案】２媒体
No. サーバ様式
1 NormalLinux（NonMPI）
2 DualCPU Linux（MPI)
3 DualCPU Linux（MPI)【Tuning】

経過時間
354 分 （5時間54分）
312 分 （5時間12分）
183 分 （3時間3分）

CPU 処理の高速化を図り、MPU 処理の昨年比約「1.70まとめ、今後の課題今期の目情である２媒体で「２時間 30 分」以内は、実現できた。課題については、（B 案）の場合において、６媒体の並列処理で、組合せが少ない媒体新聞などは、他媒体よ倍」の高速化を実現できた。従来型（一昨年前）の MPI 無し

りの場合と比較した場合には、「1.93 倍」の高速化が図れた。

先に終了するが、全媒体の組合せ最適を行うには全部が【B 案】６媒体終了することが必要になる。結果一部の GPU のリソースが「待ち」になっている。

これ以上の高速化を図る場合、一番長く処理時間が掛る媒体を更に並列処理をすることが必要である。今回の試みで媒体数を増やした【B 案】の場合においても、今回のはその部分まで踏むこむことが出来なかった。１媒体あたり

Tuning 版・MPU における高速処理の比率は【A 案】とほぼの処理を内部で細分化して、共通機構側に進捗情報を共同等であった。（Tuning 無し）MPI 比「1.71」倍。MPI 無し・有する仕組みが新たに必要でありこの部分の改善が今後比「1.93 倍」という数字であった。の高速化を図るチューニング・ポイントとなる。

６媒体の組合せにおいて、媒体の特性などがあり新聞や雑誌などは組合せが限定的にしか発生しないため、TV などに比べて合計処理時間が短いため、単純に媒体数の比（２：６）である「３倍」という時間にはなっていない。
（NormalLinux NonMPI で「１．９倍」）

２） GPU 並列化の影響調査（同一条件での試行回数 5 回の平均値）【A 案】２媒体

MPI+Tuning による高速化係数 ＝ 「2.17」倍

【B 案】６媒体

MPI+Tuning による高速化係数 ＝ 「2.1」倍

媒体数を増やした「B 案」においても、２媒体の「A 案」とほぼ同じで、MPI＋Tuning を行った方が約「2.1」倍高速化が実現できた。ただし、「B 案」の方が「0.07」倍ほど、高速化