自動並列化コンパイラをAndroidに適用してみた

7,298 views
7,035 views

Published on

1 Comment
23 Likes
Statistics
Notes
No Downloads
Views
Total views
7,298
On SlideShare
0
From Embeds
0
Number of Embeds
255
Actions
Shares
0
Downloads
49
Comments
1
Likes
23
Embeds 0
No embeds

No notes for slide

自動並列化コンパイラをAndroidに適用してみた

  1. 1. 自動並列化コンパイラをAndroidに適用 してみた @magoroku15 1 横浜PF部第33回勉強会 2013/10/14
  2. 2. SlideshareのAnalytics http://www.slideshare.net/magoroku15 2012年末から急落 2 横浜PF部第33回勉強会 2013/10/14
  3. 3. 最近…. 人に会うと言われます 最近何やってるんですか? 飽きた? カーネルの話の続きは何時やるの? つ部は参加しないの? ギークバーは行かないの? 家庭に問題でも(ねーよ) ●人でもできた?(いねーよ)        引きこもってました 3 横浜PF部第33回勉強会 2013/10/14
  4. 4. 引きこもってた理由 実は早稲田大学が開発した自動並列化コンパイラ(OSCAR) をAndroidで動かす研究をしてました     平日の夜と、週末の時間 Androidプラットフォームを並列化する試み 測定装置の設計、基板作成、自宅リフローもその一部 春までの成果は全部論文になったので、今日はその紹介 研究グループを代表してお話します コミュニティのみなさんの情報がとても役に立ちました 自動並列化コンパイラの詳細は       4 http://www.kasahara.elec.waseda.ac.jp/ または 検索: [早稲田 笠原研究室] 横浜PF部第33回勉強会 2013/10/14
  5. 5. 今日のお話し スマートディバスの高性能化   高クロック化とマルチコア化 準備体操   電力の基礎、Linuxの電力管理、OSCARコンパイラ、メモリ性 能、他 Androidのマルチコア利用率を調べてみた    通常の利用範囲ではマルチコアの利用率は低い マルチコアによる高性能化が実利用では機能していない Androidを対象に自動並列化をやってみた     5 並列化プログラムの動作阻害要因と改善 フレームワーク層の並列化→高速化 リアルタイム処理の並列化→低消費電力化 横浜PF部第33回勉強会 2013/10/14
  6. 6. スマートディバスの高性能化 それは正しい競争なのかなぁ? 6 横浜PF部第33回勉強会 2013/10/14
  7. 7. SoCの開発競争 マルチコア化 High performance device A15 A15 A15 A15 A7 A7 A7 A7 Linux – 8 core HMP A9 A7 A9 A9 A9 Linux - 5 core 4+1 vSMP A9 A9 A9 A7 A7 A15 A9 A7 A15 A15 A15 Linux - 8 core big.LITTLE A9 Linux - 4 core SMP A9 A9 Linux -2 core SMP 累積出荷台数 iOS 700,000,000 Android 1000,000,000 ARM11/ A8 Linux 2007 7 2011 ・・・・・・・ 2013 横浜PF部第33回勉強会 2014 2013/10/14
  8. 8. SoCベンダ 各社の方針 -個人の感想です- Qualcomm    独自路線 4コアでも使いきれないので8コアは無駄だ、RFで勝負だ NVIDIA    独自路線 4+1 vSMPで十分だ、Big LITTLEは4+1の劣化版だ Samsung     ARM追従路線 ARMの新アーキを一番最初に出荷するのだ Octaが同時に動かなくても商品名はOctaだ Apple      8 よくわかりません ふふん、他コア化してもスマートデバイスじゃ使わないよ 64bit x 2コアが最高(正しい気がする) 自分で作るのは面倒なので、Samsung・TSMCに委託するもん 横浜PF部第33回勉強会 2013/10/14
  9. 9. 準備体操 オームの法則覚えてますか? 9 横浜PF部第33回勉強会 2013/10/14
  10. 10. 電力って何   V:電圧、I:電流、R:抵抗 V=IR     W=V^2/R    電圧が一定の時、抵抗大なら電流小 抵抗が一定の時、電圧大なら電流大 電力はW=VI なので、I=V/RでIを置き換えて Rが一定の時、電圧を2倍で電力は4倍 Rが一定の時、電圧を1/2倍で電力は1/4倍 ACで考えると    10 C キャパシタンス、F 周波数が登場 電圧が一定の時 C*Fが大なら電流大 W=V^2*C*F 横浜PF部第33回勉強会 2013/10/14
  11. 11. マルチコアと電力消費 1Coreの場合 P = f*c*v^2  マルチコアの場合 P = n*f*c*v^2  ・・・・・ Eq.1 ・・・・・ Eq.2 • 4コア並列動作の場合、周波数‘f’を ¼ にしても性能は同じ • この時の電圧‘v’ が0.6vに下げられる とすると、電力は0.36倍(1/3に削減) ACのみ、DCは無視 11 横浜PF部第33回勉強会 2013/10/14
  12. 12. OSCAR コンパイラ 一般的なC, FORTRANコンパイラのフロントエンドとして 動作  逐次プログラムを自動並列化 A) 多様な並列性の抽出   再内ループ以外にの繰り返しはタスク並列 データ配置の最適化 B)  キャッシュに乗せる 周波数/電圧の制御APIを埋め込み C)  12 DVFS, Clock Gating, Power Gating 横浜PF部第33回勉強会 2013/10/14
  13. 13. 多様な並列性の抽出    タスクレベルの並列化 ループレベルの並列化 ステートメントレベルの並列化 13 横浜PF部第33回勉強会 2013/10/14
  14. 14. データ配置の最適化  L1 L2 外部メモリを考慮してデータの配置を管理 速い・少ない L1 L1 L1 L1 L1 L2 L2 外部メモリ 14 遅い・多い 横浜PF部第33回勉強会 外部メモリ 2013/10/14
  15. 15. データ配置の最適化  L1 L2 外部メモリのレイテンシ ARM Connect Community Technical Symposium 2009 System Level Benchmarking Analysisof the Cortex™-A9 MPCore™ http://www.ruhr-uni-bochum.de/integriertesysteme/emuco/files/System_Level_Benchmarking_Analysis_of_the_Cortex_A9_MPCore.pdf 15 横浜PF部第33回勉強会 2013/10/14
  16. 16. 周波数/電圧の制御APIの埋め込み  並列化かしたtaskの隙間に電力制御APIを埋め込む    Dynamic Voltage and Frequency Scaling (DVFS)で部分的に ゆっくり・消費電力を落として動作 Power gating: Power を落とす Clock gating: Clockを止める Core0 Core1 Core2 Core0 MT1 MT2 time MT5 MT3 MT4 MT6 MT8 MT7 MT9 Power gating Power gating MT2 MT1 Core1 MT3 MT4 (Low freq.) time Core2 MT5 (Low freq.) MT6 MT7 Power gating MT8 MT9 Clock Time management Margin gating Given Dead Line 16 横浜PF部第33回勉強会 2013/10/14
  17. 17. OSCAR がAPI電力管理APIを挿入 OSCAR Compiler •Multigrain Sequential Programs C/Fortran Parallelization •Memory Optimization •Data Transfer Optimization •DVFS, Clock gating Backend Compiler Proc0 Scheduled Tasks T1 off Proc1 Scheduled Tasks T2 T4 API Decoder #pragma oscar fvcontrol(pe, (id, state)) #pragma oscar get_fvstatus(pe, id, state) #pragma oscar get_current_time(current, timer_no) Translate OSCAR API into Library call Proc2 Scheduled Tasks T3 T6(slow) Low-power parallel C/Fortran Programs including OSCAR API 17 Native Compiler 横浜PF部第33回勉強会 Exec. Object 2013/10/14
  18. 18. 並列化プログラムの動作阻害要因と改善 18 横浜PF部第33回勉強会 2013/10/14
  19. 19. 評価環境  ハードウェア  Google Nexus-7  NVIDIA 社Tegra-3     ARM Cortex-A9 Quad-core + LP core vSMP: Variable SMP Clock 最大1.3GHz ソフトウェア  Android 4.1.2  JCROM 19 Japanese Custom ROM 横浜PF部第33回勉強会 2013/10/14
  20. 20. Android/Linuxのパワーコントロール    CPUFreq  負荷に応じてClockとVoltageを変更  DVFSの実装 CPUIdle  実行可能なプロセスが存在しない場合の休眠レベルを決める  深く寝ると、電力削減効果は大きいが、起きるのが遅い HotPlug     20 CPUFreq、CPUIdleの拡張 コアを高負荷時に増やす、低負荷時に減らす OSが負荷をサンプリングして自動的に 上手くいかない→後で詳しく 横浜PF部第33回勉強会 2013/10/14
  21. 21. SMPVariable SMP Variable SMP Variable SMP (4 -PLUS PLUS -1™)より 21 横浜PF部第33回勉強会 2013/10/14
  22. 22. Battery Save Coreとは何か   CPU0の定電圧動作時にCPU0に成り代わって透過的に 動作するCPU(LP0) LP0動作 LCD offで遷移   policy_min_freq:51,000 policy_max_freq:700,000 実測では 340,000~640,000の範囲で指定可能 通常動作    22 LCD onで遷移 policy_min_freq:51,000 policy_max_freq:1,300,000 実測では340,000~1,300,000の範囲で指定可能 横浜PF部第33回勉強会 2013/10/14
  23. 23. マルチコアの利用状況  TwitterクライアントとChrome動作時のsystrace  4コア動いてるように見えるが…… 拡大してみると  スカスカ  23 マルチコアの利用効率は低い 横浜PF部第33回勉強会 2013/10/14
  24. 24. 並列化プログラムの動作  並列化ベンチマークの結果  実行時間にばらつき サンプル 実行時間(秒)  1 2 3 4 5 6 7 8 9 10 最速 平均 最遅 5.12 5.08 3.65 5.05 2.78 2.73 5.06 2.74 5.05 2.74 2.73 4.00 5.12 Systraceによる解析結果   Thread生成からCPUのbindまでに遅延 (Start-Migrated 440.6ms) CPUの自動ON/OFF line(Auto Hotplug)が影響 440.6ms 24 横浜PF部第33回勉強会 2013/10/14
  25. 25. おまわりさんこいつです up down idle disable hotplug 動作周波数が上限値に達しているのでコアを追加 動作周波数が下限値に達しているのでコアを削除 動作周波数が上限値よりも低く、下減値よりも高いのでコア個数の変更なし Auto hotplug 機能を停止する Idle Idle Idle up 2 2 2 2 2 2 up Down Idle 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 up Down Down 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 L L L L up2g0_delay 25 L L up2gn_delay up2gn_delay down_delay 横浜PF部第33回勉強会 down_delay down_delay 2013/10/14
  26. 26. Tegra-3のhotplug governor Edp_Thermal Suspend tegra_auto_hotplug_governor Auto Hot plug CpuFreq parameters LP-mode GP-MODE up_delay up2dn_delay down_delay down_deley down_delay top_freq idle_top_freq idle_bottom_freq botttom_freq tegra_cpu_set_speed_cap up2g0_delay 0 idle_bottom_freq Throttle_table Update form user 26 New State Delay to effecte IDLE > top_freq UP Up_delay IDLE <=bottom_freq DOWN Down_delay DOWN >top_freq UP Up_delay DOWN >bottom_freq IDLE NA <bottom_freq DOWN Down_delay UP throttle_index Compare with requested freq UP 578 int tegra_cpu_set_speed_cap(unsigned int *speed_cap) 579 { 581 unsigned int new_speed = tegra_cpu_highest_speed(); 586 new_speed = tegra_throttle_governor_speed(new_speed); 587 new_speed = edp_governor_speed(new_speed); 588 new_speed = user_cap_speed(new_speed); 592 ret = tegra_update_cpu_speed(new_speed); 594 tegra_auto_hotplug_governor(new_speed, false); 596 } Current State <=top_freq IDLE ND thermal_cooling_device 横浜PF部第33回勉強会 2013/10/14
  27. 27. Auto_hotplugの無効化  auto hotplug のstate # echo 0 >/sys/module/cpu_tegra3/parameters/auto_hotplug # echo 1 >/sys/module/cpu_tegra3/parameters/auto_hotplug # cat /sys/module/cpu_tegra3/parameters/auto_hotplug  0: disabled  1: idle  2: down  3: up  0を書き込むと無効可できる 27 横浜PF部第33回勉強会 2013/10/14
  28. 28. CPU ON/OFF   以下の操作で可能 Online   echo 1 > /sys/devices/system/cpu/cpuX/online Offline  28 echo 0 > /sys/devices/system/cpu/cpuX/online 横浜PF部第33回勉強会 2013/10/14
  29. 29. on/off lineのカーネルログ <4>[138006.624075] CPU1: Booted secondary processor <6>[138006.634275] Switched to NOHz mode on CPU #1 B <4>[138006.636903] CPU2: Booted secondary processor <6>[138006.646632] Switched to NOHz mode on CPU #2 B <4>[138006.650118] CPU3: Booted secondary processor <6>[138006.657736] Switched to NOHz mode on CPU #3 B <4>[138020.741637] stop_machine_cpu_stop smp=1 <4>[138020.741649] stop_machine_cpu_stop smp=3 <4>[138020.741659] stop_machine_cpu_stop smp=0 <4>[138020.741670] stop_machine_cpu_stop smp=2 <5>[138020.743037] CPU1: shutdown <4>[138020.746183] stop_machine_cpu_stop smp=0 <4>[138020.746195] stop_machine_cpu_stop smp=2 <4>[138020.746206] stop_machine_cpu_stop smp=3 <5>[138020.747326] CPU2: shutdown <4>[138021.227998] stop_machine_cpu_stop smp=0 <4>[138021.228010] stop_machine_cpu_stop smp=3 <5>[138021.228841] CPU3: shutdown 29 横浜PF部第33回勉強会 ONline 12ms 11ms OFFline 1.4ms 1.1ms 0.8ms 2013/10/14
  30. 30. クロック制御  CPUFreqがインタフェースを提供    実体はクロックと電圧のテーブルを操作 /sys/devices/system/cpu/cpuX/cpufreq がI/F scaling_available_frequencies   scaling_max_freq   最大動作クロック scaling_min_freq  30 51000 102000 204000 340000 475000 640000 760000 860000 1000000 1100000 1200000 1300000 最低動作クロック 横浜PF部第33回勉強会 2013/10/14
  31. 31. クロック制御の制約     特定のCPUにクロックを設定すると他のCPUのクロックも 同じ値に変化? PLL,VCCが共通か? CPU個別のクロック制御はできない ON/OFFで制御するか? 31 横浜PF部第33回勉強会 2013/10/14
  32. 32. Clock up transit <7>[ 942.369161] notification 0 of frequency transition to 1200000 kHz <7>[ 942.369500] notification 0 of frequency transition to 1200000 kHz <7>[ 942.369685] notification 0 of frequency transition to 1200000 kHz <7>[ 942.370010] notification 0 of frequency transition to 1200000 kHz <7>[ 942.370193] cpufreq-tegra: transition: 340000 --> 1200000 <7>[ 942.370555] regulator regulator.2: set_voltage: name=max77663_sd1, min_uV=1100000, max_uV=1350000 <7>[ 942.371086] regulator regulator.1: set_voltage: name=max77663_sd0, min_uV=900000, max_uV=1250000 <7>[ 942.371467] regulator regulator.2: set_voltage: name=max77663_sd1, min_uV=1200000, max_uV=1350000 <7>[ 942.371985] regulator regulator.1: set_voltage: name=max77663_sd0, min_uV=1000000, max_uV=1250000 <7>[ 942.372505] regulator regulator.1: set_voltage: name=max77663_sd0, min_uV=1025000, max_uV=1250000 5ms <7>[ 942.373135] notification 1 of frequency transition to 1200000 kHz <7>[ 942.373209] FREQ: 1200000 - CPU: 0 <7>[ 942.373345] notification 1 of frequency transition to 1200000 kHz <7>[ 942.373483] FREQ: 1200000 - CPU: 1 <7>[ 942.373561] notification 1 of frequency transition to 1200000 kHz <7>[ 942.373756] FREQ: 1200000 - CPU: 2 <7>[ 942.373832] notification 1 of frequency transition to 1200000 kHz <7>[ 942.374027] FREQ: 1200000 - CPU: 3 32 横浜PF部第33回勉強会 2013/10/14
  33. 33. Clock down transit <7>[ 1035.045405] notification 0 of frequency transition to 1000000 kHz <7>[ 1035.045529] notification 0 of frequency transition to 1000000 kHz <7>[ 1035.045591] notification 0 of frequency transition to 1000000 kHz <7>[ 1035.045702] notification 0 of frequency transition to 1000000 kHz <7>[ 1035.045763] cpufreq-tegra: transition: 1200000 --> 1000000 <7>[ 1035.046042] regulator regulator.1: set_voltage: name=max77663_sd0, min_uV=975000, max_uV=1250000 <7>[ 1035.046315] notification 1 of frequency transition to 1000000 kHz 2ms <7>[ 1035.046387] FREQ: 1000000 - CPU: 0 <7>[ 1035.046462] notification 1 of frequency transition to 1000000 kHz <7>[ 1035.046593] FREQ: 1000000 - CPU: 1 <7>[ 1035.046669] notification 1 of frequency transition to 1000000 kHz <7>[ 1035.046857] FREQ: 1000000 - CPU: 2 <7>[ 1035.046929] notification 1 of frequency transition to 1000000 kHz <7>[ 1035.047116] FREQ: 1000000 - CPU: 3 <7>[ 1035.047352] regulator regulator.2: set_voltage: name=max77663_sd1, min_uV=1100000, max_uV=1350000 33 横浜PF部第33回勉強会 2013/10/14
  34. 34. おまけ Systelcall cost  getpid(2) 1M times    One CPU, ON & Off line 1K times   # time ./scalltest p M 0m0.19s real 0m0.02s user 0m0.18s system 190000000ns / 1000000 = 190ns Clock 1.2GHz # time ./scalltest 0 h K 0m23.43s real 0m0.00s user 23430 ms / 1000 = 23 ms 0m1.49s system Three CPU, ON & Off line 1K times  34 #time ./scalltest 0 H K 0m31.01s real 0m0.00s user 30s / 1000 = 30ms 0m4.77s system 横浜PF部第33回勉強会 2013/10/14
  35. 35. 遷移評価  CPUのON/OFF line    1CPU 3CPU 23ms 30ms Clock    まとめ UP Down 5ms 2ms 測定環境    35 Affinity init + factory kernel Autohotplug off via sysfs 1.2 GHz 横浜PF部第33回勉強会 2013/10/14
  36. 36. 並列化プログラムの実行環境  CPU Hot Plug  Auto Hot Plugの課題    対処     周波数制御でも負荷が改善できない場合にCPUを追加 サンプリングによる遅延 Auto Hot Plugの無効化 アプリケーションからの要求によるHot Plug 並列化プログラムから必要コア数を要求・割り当て CPUバインディング  非並列プログラムとシステムプロセスをCPU0に割り付け   並列化プログラムをCPU1~3に割り付け  36 Initを修正して、非並列プログラムをCPU0に 並列化プログラムからthreadをCPUに割り付け 横浜PF部第33回勉強会 2013/10/14
  37. 37. 並列化ランタイム    CPU HotplugとCPUバインディングを制御 sysfsインタフェースを利用 主な仕様      37 アプリケーションがCPU Auto Hot Plug 機能を無効化できる 事 アプリケーションがCPU のオンライン・オフラインの変更を行 える事 複数の並列化アプリケーションの要求を管理できる事 アプリケーションが異常終了した場合に獲得した資源を解放 できる事 評価対象以外のプログラムはコア#0 で動作する事. 横浜PF部第33回勉強会 2013/10/14
  38. 38. 並列化ランタイムの効果 - 過渡特性  Start-Migratedの時間は7.2ms   並列化ランタイムを用いない場合は440.6ms 以下を改善    38 7.2ms Auto hotplug によるコアの追加に伴う遅延時間 一旦, 任意のコアで実行を開始した後に, 指定されたコアに スレッドが移行する遅延時間 コア追加時に一旦クロックを低下させる処理 横浜PF部第33回勉強会 2013/10/14
  39. 39. 並列化ランタイムの効果 – 実行速度  適用前 サンプル 実行時間(秒)  2 3 4 5 6 7 8 9 10 最速 平均 最遅 5.12 5.08 3.65 5.05 2.78 2.73 5.06 2.74 5.05 2.74 2.73 4.00 5.12 適用後 サンプル 実行時間(秒)  1 1 2 3 4 5 6 7 8 9 10 最速 平均 最遅 2.70 2.71 2.72 2.72 2.73 2.73 2.76 2.72 2.72 2.73 2.70 2.72 2.76 以下の改善により、高速化・安定化   39 過渡特性の改善により、急峻な並列性負荷変動に対応 必要なコア・クロックを明示的に指定 横浜PF部第33回勉強会 2013/10/14
  40. 40. フレームワーク層の並列化 - 高速化 Skiaを並列化 40 横浜PF部第33回勉強会 2013/10/14
  41. 41. システムレベルの並列化  並列化ランタイムライブラリ   ネイティブバイナリを高速化できた Android上で利用する場合NDKを利用 1. 2.  NDKの問題    C又はC++でネイティブライブラリを作成 JavaからJNI経由で呼び出し Java とC++の2 種類のフレームワークの習熟が必要 Java で開発をしてきたデベロッパの負担大 Android のシステム側での並列化    41 既存のAPIを変更せず、その処理を並列化 デベロッパの負担無し 既存のプログラムも高速化が可能 横浜PF部第33回勉強会 2013/10/14
  42. 42. Androidの構造1 アプリケーションの空間構成 User 記述部分 Java Java クラスライブラリ Dalvik (VM) JNI skia Native 42 libc その他 描画 バッファ 横浜PF部第33回勉強会 2013/10/14
  43. 43. Skia  2D描画ライブラリ    2005年にGoogleが買収したSkia社のライブラリ オープンソースとして公開 Androidでは2Dレンダリングエンジンとして利用    例 Java: canvas→Skia: SkCanvas Google Chrome等でも採用 Skiaの構成    43 インタフェース層 APIを提供 演算層 API層の指示でラスタの演算を処理 BitBLT層 演算層の指示で描画バッファを操作 横浜PF部第33回勉強会 2013/10/14
  44. 44. Androidの構造2 Surfaceflinger アプリケーション アプリケーション アプリケーション Skia Skia Skia アプリケーション用 描画バッファ SurfaceFlinger Frame Buffer 44 横浜PF部第33回勉強会 2013/10/14
  45. 45. Android描画機能の並列化    アプリケーションから多用される2D描画処理 Skia HTMLのレンダリングでも利用 Java APIとして提供    C++で記述されたSkiaライブラリをJavaからJNIで呼び出す 描画以外にも画像展開、bitmap操作など Skiaの最適化  HWアクセラレーションは進んでいない   ストリーミング演算ではない BitBLT層はループ展開とSIMDで最適化 Skia並列化による改善を検討 45 横浜PF部第33回勉強会 2013/10/14
  46. 46. BitBLT Y X fx count 0 dx 32bit/pixel dst 回転 count 16bit/pixel イメージ (例:アイコン) Y アプリケーション用 描画バッファ 46 横浜PF部第33回勉強会 X 2013/10/14
  47. 47. BitBLT 従来の最適化  BitBLTはAndroidの改版の都度改善されてきた    C言語→ASM→SIMD GPUでは効果が出ない(実は最近………) SIMD命令による最適化  SIMDを用いたストライド転送を8画素単位にcount個繰り返す dx fx ストライド転送 dst 47 count 横浜PF部第33回勉強会 2013/10/14
  48. 48. BitBLTの並列化  初回の呼び出し時にスレッドを生成  システムコールsched setaffinity でコアに割り付け  演算の開始、完了の待ち合わせはスレッド間で共有するvolatile 変数の参照・更新で行う  待ち合わせはSpin lock 方式で行う 待ち合わせ処理はSkia のインターフェース層で行う  ① ③ ② パラメタの設定 ④ ④ fx+count//2 fx dst コア#0 48 count/2 ⑤ コア#1 横浜PF部第33回勉強会 dst+count/2 count/2 ⑤ コア#2 2013/10/14
  49. 49. Skia並列化による描画性能の向上  変更前 逐次処理の描画フレームレート(FPS) サンプル 2 3 4 5 Round 1 44.56 44.88 43.95 44.56 44.82 Round 2 44.91 44.67 45.18 44.91 44.42 Average  1 44.74 44.77 44.56 44.74 44.62 変更後 並列処理の描画フレームレート(FPS) サンプル 2 3 4 5 Round 1 44.89 45.84 45.89 45.87 45.80 Round 2 45.82 45.90 46.16 46.08 45.86 Average  1 45.85 45.87 46.02 45.97 45.83 3%の向上 OSCARによる自動並列化で フレームレートを2倍に向上 49 横浜PF部第33回勉強会 2013/10/14
  50. 50. Skia自動並列化のまとめ  4コア商用スーマートディバイスの課題     一定時間の負荷が継続した場合にのみコアを追加 短時間の並列性負荷ではマルチコアは動作しない 急峻な並列性負荷に対応可能なランタイム環境を整備 描画APIの1処理を例題としてAndroid内部で並列化  標準の描画APIの性能をフレームレートで3%向上  OSCARコンパイラで性能を2倍に 50 横浜PF部第33回勉強会 2013/10/14
  51. 51. Skia高速化 0xbenchでの評価 動画は近日中にyoutubeにupload予定 51 横浜PF部第33回勉強会 2013/10/14
  52. 52. Draw Image 52 27.2FPS → 52.9FPS 横浜PF部第33回勉強会 2013/10/14
  53. 53. Draw Rect 53 20.9FPS → 42.1FPS 横浜PF部第33回勉強会 2013/10/14
  54. 54. Draw Circle2 54 33.9FPS→ 50.8FPS 横浜PF部第33回勉強会 2013/10/14
  55. 55. 電力評価環境 55 横浜PF部第33回勉強会 2013/10/14
  56. 56. Nexus 7でやってみた    回路図なし PMIC、SoCの仕様は非公開 バッテリ側のPMICを加工して、電流測定 56 横浜PF部第33回勉強会 2013/10/14
  57. 57. Power Rail and Measurement point for Nexus 7 USB 5V A Battery I2 C slave B Bat-mgr C DC-DC PMIC PS63020 MAX77612 Unregulated VBAT (typ. 3.7v) 3.0v I2C slave SOC 0.8v3.3v I2C master Valuable A) B) C) 57 VBAT の出力 DC-DCの出力 PMICの出力 横浜PF部第33回勉強会 2013/10/14
  58. 58. 作ってみた 58 横浜PF部第33回勉強会 2013/10/14
  59. 59. 測ってみた#1 Vsync    1ms 73mv 平らなところはidle 1ms 間隔で割り込み 16ms 間隔でVSYNC 59 横浜PF部第33回勉強会 2013/10/14
  60. 60. 測ってみた#2   0xbenchのDraw rectで測ってみた VSYNC の間隔で負荷が上昇 60 横浜PF部第33回勉強会 2013/10/14
  61. 61. 電力測定はおもしろい SDを動作させた時の大電力  割り込みで間欠的に上昇する負荷  画面更新の少ない場合の負荷  画面更新の多い場合の負荷 突然Nexus7がお亡くなりに………  http://lbdaberi.blogspot.jp/2012/12/nexus-7.html 61 横浜PF部第33回勉強会 2013/10/14
  62. 62. 新しい評価環境 ODROID-X2  Samsung Exynos4412 Prime       ARM Cortex-A9 Quad core 最大 1.7GHz Samsung Galaxy S3で使ってます DVFS は4コア共通 Hardkernel 社からAndroid/linuxがソース提供 回路図も公開  62 シリアル番号をメールで送ると回路図が送られてくる 横浜PF部第33回勉強会 2013/10/14
  63. 63. Exynos4412のPower Rail  PMICはExynos4412 に4種類の電源を供給      VDD_ARM VDD_INT VDD_G3D VDD_MIF CORE Interrupt controller and L2 GPU DDR Memory VDD_ARM (CORE) を測定対象にした SoC Exynos4412 VDD_ARM PMIC Cortex-A9 32KB I/D NEON Cortex-A9 32KB I/D NEON Cortex-A9 32KB I/D NEON Interrupt controller + L2 VDD_G3D GPU VDD_MIF 63 VDD_INT Cortex-A9 32KB I/D NEON DDR 横浜PF部第33回勉強会 2013/10/14
  64. 64. ODROIDオリジナル 回路図 レイアウト VDD_ARM GND GND C27 C32 C C L L PMIC 64 横浜PF部第33回勉強会 2013/10/14
  65. 65. ODROID-X2の改造 Current Voltage Voltage (V) x Current (A) 65 横浜PF部第33回勉強会 = Power (W) 2013/10/14
  66. 66. やってみた VDD_ARM Single 5 Pin GND GND GND C C R R L Voltage L Drop Voltage PMIC 66 横浜PF部第33回勉強会 2013/10/14
  67. 67. こんな感じ ODROID-X2 オシロ・ADCなど SoC Instrumentation amp PMIC Shunt Shunt電圧 67 横浜PF部第33回勉強会 2013/10/14
  68. 68. リアルタイムアプリケーションの並列化 - 低消費電力化 - 68 横浜PF部第33回勉強会 2013/10/14
  69. 69. ベンチマーク MPEG2 decode  60FPS(16.6ms)毎に1フレームを処理 a)1フレーム分のdecode処理 b)時間を待ち合わせ(loop) 1ms程度で正確にsleep/wakeupできればb)の電力を下げられる 69 横浜PF部第33回勉強会 2013/10/14
  70. 70. clock gating  ARM のWFI 命令   WFI 命令はイベント(割り込み)が発生するまでClockを止めて 電力を低減できる 通常はカーネルのidle処理で利用   動作可能なプロセスが存在しない場合に呼び出し休眠、タイマ割り 込で復帰 Clock gating ドライバを作ってみる   70 WFI は特権命令 APIから呼び出し可能なLinux driverを作ってみたら? 横浜PF部第33回勉強会 2013/10/14
  71. 71. 作ってみた WFI driver while(1) { gpio_value(1); call_wfi_api(1); gpio_value(0); } while(1) { gpio_value(1); call_wfi_api(4); gpio_value(0); } 0us < T < 500us 1500us < T < 2000us GPIO GPIO Wake up 500mA 250mA 500mA 250mA Clock gating 15000us (3 slot) Time Slot is 500 us 2000us (4 slot) 71 (N -1) x 500us < T < N x 500us 横浜PF部第33回勉強会 2013/10/14
  72. 72. 電流 - 4コア Clock gating無し Busy wait in ordinary execute 2000mA 1500mA 1000mA 500mA 1core 72 2cores 横浜PF部第33回勉強会 3cores 4cores 2013/10/14
  73. 73. 電流 - 4コア Clock gating有り 電流は一定 Busy wait with clock gating 割り込み処理 2000mA 1500mA 1000mA 500mA 1core 73 2cores 横浜PF部第33回勉強会 3cores Clock gating 中 4cores 2013/10/14
  74. 74. 電流 Clock Gating ありなしの比較 Busy wait in ordinary execute 2000mA 1500mA 1000mA 500mA 1core 2cores 3cores 4cores 3cores 4cores Busy wait with clock gating 2000mA 1500mA 1000mA 500mA 1core 74 2cores 横浜PF部第33回勉強会 2013/10/14
  75. 75. 並列化+DVCF+ClockGateingでの MPEG2 Decoder 消費電力 Without Power Reduction Control With Power Reduction Control 1/7(13.3%) 1/3(38.1%) NUMBER OF CORES 75 横浜PF部第33回勉強会 2013/10/14
  76. 76. 電力測定 MPEG2 Decoder 1コア MPEG2 Decode execution In high clock and voltage 1.7GHz, 1.4V Clock gating by WFI Busy Wait execution 1.7GHz, 1.4V (a) Without Power Reduction Control (b) With Power Reduction Control Reduced by WFI 76 横浜PF部第33回勉強会 Reduced 2013/10/14 Consumed
  77. 77. 電力測定 MPEG2 Decoder 3コア Busy Wait execution MPEG2 Decode execution In low clock and voltage MPEG2 Decode execution In high clock and voltage 1.7GHz, 1.4V 400MHz, 1.05V Clock gating by WFI 200MHz, 0.92V (a) Without Power Reduction Control (b) With Power Reduction Control DVFS P = n*f*c*V^2 77 横浜PF部第33回勉強会 Reduced by WFI Reduced 2013/10/14 Consumed
  78. 78. MPEG2 Decoder の消費電力2は3並列で1/3に DVFS WFI 2.79 WFI 0.97 0.63 0.37 1/3(38.1%) NUMBER OF CORES 78 横浜PF部第33回勉強会 Reduced Consumed 2013/10/14
  79. 79. まとめ    Androidのマルチコアは殆ど動いていない Javaアプリを並列化するのは難しく、効果が少ない OSでの自動制御には無理がある   頻出するJava APIのNative側(Skia)を自動並列化してみた    2Dレンダリング性能が2倍に向上 実はHTML5でも効果あるんです リアルタイムアプリ(MPEG2 decode)を自動並列化してみた   アプリから制御する(OS屋をとしては敗北!) 消費電力は1/3に削減 次のネタは仕込み中w 79 横浜PF部第33回勉強会 2013/10/14
  80. 80. 利用したツールなど  性能評価      Syatrace Oprofile Perf Gwave システムレベルのプロファイル 関数レベルのプロファイル、CallGrapf 命令レベルのプロファイル 波形表示 プラットフォーム   80 Nexus7 2012 ODROID-X2 横浜PF部第33回勉強会 2013/10/14
  81. 81. 最後に  ET2013 産学共同パビリオンに出展します  2013.11.20(水)-22(金) 早稲田大学 理工学術院 笠原・木村研究室 ブース番号 UI-02  ETフェスタは11.21(木) 17:00-18:00    81 差し入れ歓迎 横浜PF部第33回勉強会 2013/10/14

×