ふと思い立って ftrace 周辺のドキュメントを軽く冷やかしてみる。数年前から Sphinx ベースになったらしい・・・。
自分の五年前の理解は、間違ってはいないがだいぶ雑だった。
FTrace はもともとはカーネルのコードで GCC のプロファイラオプションというか gprof を使えるようにするというもので、ただカーネル空間にはプロファイラのランタイムがないのでカーネルが自前のランタイムを提供していた、らしい。そのランタイムのインフラに他のトレース機構、たとえば tracepoint が乗っかってきた。ここでいうランタイムは、具体的には CPU スレッド単位のリングバッファ。Android の ATrace もこのバッファに便乗している。
コンパイラが関数単位で instrument するタイプのプロファイラは全然スケールしないので、ある規模以上のコードベースではふつう sampling-based profiler を使う。Linux も perf とかはサンプリングベースだったはず。
ただしそれとは別に、FTrace は "dynamic ftrace" という仕組みを追加した。カーネルのコードをプロファイラ有りでビルドしつつ、ランタイム関数の呼び出しは起動時に全部 nop で塗りつぶす。この塗りつぶしができるよう、呼び出し箇所の一覧を事前に作っておく。そして API で関数を指示すると nop の所にランタイムへの呼び出しを書き戻す。デバッガがやるようなことをカーネルの機能として提供している。たぶん今はこっちの方が主流っぽい。手元の Ubuntu ではふつうに有効になっている。Android はセキュリティのためカーネルを read only にしている都合で無効らしい。でも性能改善のドキュメントで紹介するくらいなら userdebug では有効にしておいてくれや・・・カーネルのリビルドとかやりかたわかんないよ・・・。
そんなかんじで Android からはカーネルの中に明示的にうめこまれた tracepoint たちとユーザ空間から書き込まれたデータしかトレースできない。まあいいんだけど。
Tracepoint のようにプログラマが手で足すにしろ Ftrace のようにコンパイラの助けを借りるにしろ、トレースの記録通知と通知を受けて何をするかは分離されており、イベントハンドラみたいのを（カーネル空間で）登録できる。リングバッファに書き込む、という部分はそのイベントハンドラの責務となっている様子。なかなか正しいデザインと言える。Brendan Greg の BPF 本では BPF をカーネルのイベントハンドラと表現していた。実際トレーシングのインフラがイベントハンドラを提供しているんだね。
Perfetto も自分でトレースフックのカーネルモジュールを書けば効率的にデータを読み出せそうなものだが、そんなカーネル依存のことはしてないだろうなあ。
リングバッファに話をもどすと、バッファには trace_pipe を読むとでてくるテキストが直接書き込まれているわけではなく、何らかのバイナリ列を書き込む。そして trace_pipe を解釈するタイミングでそのバイナリをテキストに整形する。なお ATrace はユーザ空間から任意のテキストを書き込める trace_marker という API を使っているので、じっさいバッファにテキストを書き込む。整形の仕組みをユーザ空間からもアクセスされてくれればよかったのに・・・。なお trace_marker_raw というバイナリ列を直に書き込む API もあることはある。
トレーシングというものの実装としてはだいぶがんばっている例の一つだと思うので、参考のためにもうちょっとコードを読んでみたいもんです。そのうち。
久しぶりにログを SQL で調べものをする仕事。二日くらいで終了。
昔にくらべ SQL は相変わらず下手くそだが Pandas/Matplotlib スキルが上がっており、それなりのチャートを Pandas だけで出せるようになってきた。結果として、二年前の "SQL 書くなら Altair 必須" という気分は消え去り、気がつくとぜんぶ Pandas で済ませている。たぶん当時は Pandas と Matplotlib を混ぜて使えなかった。今は Pandas の plot() が matplotlib の薄いラッパであるという事実を活用し、subplot したり axes 重ね書きしたりできるようになった。
とはいえもうちょっとモダンでシュッとしたライブラリを使えた方がいいんじゃね・・・という反省もあり、今回描いたチャートを一通り Altair に移植してみた。が ...mixed feeling. コードはすごいコンパクトかつ宣言的になるし、描かれるチャートもいいかんじ。でも自分の生産性がどれだけあがるかは微妙。
生産性を妨げる要素は、大きく分けて二つある。
ひとつ目は、自分のデータ力の低さ。Altair は入力の DataFrame が tidy data 的に正規化されていることを期待している。Altair が ggplot の追っかけである事実を考えると当たり前の帰結なんだけど、自分の手元のデータは必ずしも tidy でないので reshape しないといけない。でもデータの reshape とか素人には認知的負荷が高いのだよね。Pandas の API もわかんないし。今回のデータでいうと、ひとつ目のチャートは pandas.concat で複数の DataFrame を連結する必要があり、ふたつ目のチャートでは DataFrame.melt というので unpivot した。データの最終型がわかっていればこうした API を探す心の余裕もあるけど、実際の問題の中でごちゃごちゃやってる時には新しい API をみつける気力が無い気がする。同様に SQL も一段階がんばって書かないといけない。最終的に tidy な DataFrame をつくるための小細工とかを SQL に入れる必要があるので。でも SQL とかわかんないのだよ・・・。
一方で Pandas を生で使っていると適当に for 文を回しながらゴミのようなデータから手続き的に欲しい絵が出せるので、問題を考える mental bandwidth を浪費しない。たとえば一つの tidy DataFrame を使うかわりに、二つの単純な SQL のクエリから持ってきた二つの DataFrame を順番に使う、みたいなことができる。ただしコードはゴミ。
Hadley Wickham の Tidyverse がスパルタなデータサイエンティスト養成ギプスとして機能しているように Altair を tidy data 養成ギプスとして受け入れるのがあるべき姿なんだろうけど、自分なんて通りすがりで四半期に一回くらい SQL 書くだけなので、正直そこまでがんばりたくない。弱音吐いちゃう。
ふたつ目は Altair の API ergonomics。
Matlab あたりから延々と鍛え抜かれ磨かれた Pandas/Matplotlib の API は色々ダサいが、一方で使用頻度の高い機能がトップレベルの雑なキーワード引数でズバっと実現できるハフマン符号化的強さがある。しかももれなく SO の回答がある。たとえば outlier を適当に無視しつつレイテンシのグラフを書きたい時、Pandas なら df.plot(...., y='latency', ylim=(0, 10000)...) とかやればいいところで Altair は ....encode(..., y=alt.Y('latency', scale=alt.Scale(domain=(0, 10000), clamp=True)), ...) とか書かないといけない。気持ちはわかるがもうちょっとなんとかなんないんですかね・・・。Altair も所々にショートカットを揃えようという意思は感じるが、ベースの API がやや大げさな上にプロジェクトの若さゆえユーザビリティの苦情による API の圧縮が進んでおらず、上のようなかったるさにしばしば遭遇する。SO も頼りにならない。
Ergonomics 上の問題その二は、ベースにある Vega というオブジェクトモデルが言語非依存なせいで発生する冗長さ。Altair は自分自身がデータを dice and slice する仕組みを色々もっている。まあデータのブレイクダウンが必要なのである程度は仕方ないと思うんだけど、Pandas でやらせてくんないかなあ。一連の Data Transformation の仕組みなんて vega expression というナゾのミニ言語を使わされて、しらねーよという気分。ただし、いまドキュメントをみたら「できるなら Pandas 側でやりましょう。そのほうが便利です」と書いてあるのにきづいた。なんなの・・・。
Altair にせよ Vega にせよ ggplot と戦う気なだけあって色々よく考えられ、その結果としてよく練られた抽象がある。ドキュメントも割とよく書けてる。ただ裏を返すと大袈裟で、学習勾配がきつい。通りすがりのモバイルプログラマにはやや荷が重い。
がしかし！データワナビーとして我々は！背伸びをしてでもモダンなフリをキメるべきではないか！問題解決原理主義者に負けるな！
コードは短くなるしチャートはシュっとしているし DataFrame は Tidy になるし、良いことは良いんだよねー。まあ締め切りの厳しさと相談しつつぼちぼち使っていきたい所存。SQL 仕事だけじゃなく普段のベンチマークの結果整形とかにも使って体を慣らしていくのが良いかもしれない。
追記
Colab の local runtime ではちゃんと動かないことが判明しがっかり・・・。
前回かいた Systrace (というか Ftrace) データのパース、やろうとおもいつつ procrastinate していた理由の一つは、それより Perfetto の trace processor を使う方が良いのではと思っていたからだった。が、まあ気のせいだったね。
Trace processor は Perfetto のダンプに sqlite でアクセスできる機能があり、これは魅力的である。ただ現実には自分は特別 SQL が流暢ではないので Python で regexp して Pandas で加工した方が速いし、できることも多い。例えばこのあいだアロケーションのレイテンシとサイズの相関を求めたが、その解釈にはネストした trace section を紐付ける必要がある。これは for 文で書けば自明だが SQL だとどうしていいかわからん。しかもその trace processor には Pandas インテグレーションとかがないので可視化もできない。使えねー。
より深刻な問題は Perfetto が lossy である点。Perfetto はオンデバイスのコマンドで、自分でバッファを持っている。ということは ATrace の API も Perfetto に直接フィードするのかな・・・と思いきやそんなことはなく、引き続きカーネルの trace_marker に書き込んでいる。言われてみれば atrace/systrace の動作を壊すわけにはいかないので当たり前だが、つまり Perfetto は ftrace のバッファをパースして Perfetto の protobuf に詰め替えているということである。しかもオンデバイスで！まじか。そんなことで余計な CPU サイクル使わないでくれよ・・・しかもオンデバイスなんてロジックにバグあったら直せないじゃん・・・デバイスの外でやれよ・・・。
オンデバイスでやりたいのはオンメモリのバッファでけでなくファイルに書き出す長時間トレースをサポートしないなどの事情と関係あるのは理解している。しかしトレードオフには納得できない。実際、Q のオンデバイストレース (perfetto フォーマット) を Systrace のデータに変換しようとすると失敗したり、エラーにはならないが表示が壊れることがしょっちゅうある。一方で Perfetto ネイティブなビューアは機能がたらない。だめじゃん。Perfetto Native UI は wasm とかをつかっているあたり、いかにも実用的なものをつくる気のなさを感じる。というとディスりすぎかもしれないが。
自分が Perfetto への乗り換えを考えていたのは Q から on-device tracing のフォーマットが Perfetto に変更されたからだが、こうした不利益をわざわざ受け入れる必要はないと考えを改めた。特に ATrace が引き続き ftrace に依存している事実を考えると ftrace のバッファが the source of the truth なわけで、間に lossy な Perfetto を挟むのはリスク。やめやめ。引き続き Systrace で生きていきますわ。
Perfetto は Chrome と Android 共通のインフラにすると主張している。そんなら Chrome で枯らした後で Android に持ってきてほしかった。勤務先には "a shiny but work in progress way と a functional but deprecated way がある" という格言がある。Perfetto はその一例になっている感。そういう場合は常に the deprecated way を進めというのが先人の知恵で、自分はそれを体現してしまったのだった。Sigh.
追記
Perfetto の UI がバージョンアップし、以前は表示されなかったメトリクスが見えるようになった。そして後ろの席の同僚は文句をいいつつがんばって perfetto コマンドを使っていた。そうですね我々会社員には使ってバグを踏んで報告して直させる、という暗黙の責務もあるんですよね・・・。職業倫理の差を感じる。はーつかうか・・・しかし Colab から読めねーんだよなー・・・ヒマなら業務外で Perfetto に首を突っ込みたい所だがちょっとなー・・・。
前回のつづき。
機能 F が招くコマ落ちの原因探求、最初の被疑者たる CPU 負荷は無罪の見通しとなったため、他の指標をさがす。
コマ落ちの直接の原因である HAL API A のレイテンシは機能 F の有無でどのくらい違うんだろうか。Systrace の HTML を肉眼で眺めていてもいまいち決定的な違いが見えない。重い腰を挙げて Colab を開き、適当に正規表現を書いて Systrace 内のデータに含まれる該当 API のトレースを読んでレイテンシを抜き出す。そして時系列にプロットしてみる。
と、やはり F 有効時はちょっと悪い気がする。しかしなぜかがわからない・・・。
さて、件の API は何かと言うと、共有メモリ (gralloc) のアロケーションである。そして件の API 内部のトレースには要求されたメモリのサイズが書いてある。このサイズを見ると、誰が要求したメモリなのかがひと目でわかる。そしてサイズがでかいほどレイテンシは大きくなりがち。
ふと思い立ってパーサのロジックを書き足し、プロット (scatterplot) にサイズを反映してみる。X 軸を時系列、Y をレイテンシ。サイズを色に割り振ると・・・やはりサイズがでかいアロケーションは遅い。そして F 有効時はそもそも「サイズのでかいアロケーション」の数が多い！沢山の細かいアロケーションに隠れていて気づかなかったが、こりゃ遅くなるわ！アプリのログや同僚へのインタビューでこの事実を確認する。振り返るとアルゴリズムの性質から自然な帰結である。OMG.
この初歩的な問題に何週間も気づいてなかったのは shame. 肉眼さん・・・。
API リクエストの頻度自体は他の機能によるリクエストが支配的で、総数は機能 F の有無で大きな差はない。しかし他の機能がリクエストするアロケーションはぜんぶサイズが小さい。F によるアロケーションはでかい。しかも F のスレッドが直接リクエストを発行するのではなく、F がメモリを長時間保有するせいで普段はプロセス内で資源が再利用され省略されるアロケーションが発生してしまうという間接的な症状なのでグチャっとしたトレースを睨むだけでは気付けなかった。
というわけで可視化重要。あとゴチャっとしたデータをパースして構造化するのも重要。トレースをパースするコード片を書き溜めないとな。
可視化素人としては subplot の利用と scatterplot の color axis を使えるようになったのが最近のブレークスルーであった。
とある機能 F を有効にするととある操作 T のあとでコマ落ちするという、ユーザ（上司）の手元では再現するが手元での再現率がいまいちなバグを直そうと苦戦しつつはや数週間。
ハイレベルには、F を有効にした状態で操作 T をトリガーすると瞬間的に CPU の負荷が跳ね上がり、画像パイプラインのクリティカルパスにある HAL API である A のレイテンシがフレームレートを超えてしまい、コマ落ちに至る。
A のレイテンシは普段は余裕で予算に収まるのだが、他のタスクが増えると CPU のサイクルを奪われて遅くなる。症状から A の重要性は明らかなので A が動くスレッドを SCHED_FIFO にしましょうと主張してパッチを書いたが、OS のひとにインパクトでかすぎるのでダメと押し返されうーむとなる。
なお HAL の一部では SCHED_FIFO はぼちぼち使われている...まあ「ぼちぼち」は overstatement かもしれないですね。はい。従ってこの問題は priority inheritance で解決されるのが筋だが、俺のせいじゃねー的 API のせいでその仕組みは使えないのだった。
それはさておき操作 T 発動時の CPU 負荷は機能 F の有無に関わらずどのみち高く、全てのコアが振り切る。機能 F のアルゴリズムが高価なのは事実だろうが、ほんとにコマ落ちの有無を決めるような規模のインパクトがあるのだろうか。こういう雑な仮説を盲目的に信じては痛い目に逢い続けて数年、いちおう検証しておこうと思い立つ。
タスクが多すぎてタイムスライスがもらえないとか、ロードアベレージみたいなのをみればいいんだっけ？と検索すると Brendan Gregg のブログがヒット。要約すると Linux の load average の数字は微妙なので他の指標を使っときなよとのこと。他の指標としては BPF が使えるよ、とかいうが Android でそれは大変。別の候補として紹介されている /proc/schedstat ファイルを polling してみることにする。
ドキュメントおよびインターネットによると同ファイル内で "sum of all time spent waiting to run by tasks on this processor (in jiffies)" という数字を監視すればよいようだが、Jiffies ってなんやねん。その manpage およびインターネットによるとスケジューラのクロック、たとえば 100Hz だったら 10ms とからしい。なるほど・・・と値を眺めるが、全然合ってない。桁がいくつもちがう。最初は自分の雑なコードが計算ミスをしてるのかと思ったがそんなこともなさそうな雰囲気。はーなんだこりゃ・・・と落胆して帰宅。
翌日気を取り直してカーネルのコードを睨むと、数字の出どころは sched_clock() という関数らしい。実装が複数あるのでよくわからないが、ドキュメントは単位をナノ秒と主張している。 10ms と 1ns じゃだいぶ違うわけだわ・・・。ナノ秒として計算してみるとそれっぽい数字になる。やれやれ。カーネルのドキュメントも案外信用できない。
さてこうして計算したオレオレロードアベレージを定期的に ATrace_setCounter() しつつアプリをつついてトレースを眺めたところ・・・機能 F が有効だろうが無効だろうがロードに全然違いがない。
冷静になってトレースを見直すと機能 F はスレッドが一つ増えはするものの大した並列度はなく、そのスレッドも GPU に計算を投げたり他のスレッドの計算結果を待ったりで必ずしも全力では回っていない。仮説敗れる。はー・・・。
ではなぜ機能 F はコマ落ちを招くのだろうか。ユーザ（上司）の思い込み？でも自分の手元で問題がおきるときも機能 F の有無は影響ある気がするのだよなあ。
そして書いていて気づいたがトレースには sched の tracepoint が含まれているのだからカーネルが集めた stats を使うより自分で事後的に計算した方が色々わかることが多いきがする。たとえばカーネルの stats ではレイテンシの分布はわからない。ただその計算をするにはもうちょっとカーネル詳しくならんとムリだな。はー・・・。
年末にハカソンがあったので、自分は機能を削るとどれだけ起動が速くなるか実際にコードを消して調べることにした。一つ一つモードを消し、UI を外し・・・と一週間コードを消し続けた。しかし一ミリも速くならなかった。がっかり。
理由を考える。
まず前向きな理由がありうる: 余計なコードはクリティカルパスから取り除かれている。自分は余計なものをクリティカルパスからどかす作業を延々とやってきたわけだから、これはまあまあ的をいている。一方で、どうにも信じがたい。
最初の論点と少し関係がある仮説：起動などを遅くしているのは、モードや UI といった user facing feature のコードではなくフラグの定義やモニタリングのようなインフラっぽいコードである。そういうコードはどのみち消せないことがわかっているのでがんばって消すことをしなかったが、実際はまあまあクリティカルパスにあるのでほんとは消してみるべきだったのかもしれない。ただあちこちに断片的に埋め込まれてるので消すのが難しいのだよね。
このハカソンの少し前にフラグ取得の IPC がフラグの数だけ呼ばれまくっていたのを助っ人高速化隊のエースが発見し、それをバッチ化したら起動がぐっと速くなる出来事があった。これはインフラ税の存在を裏付けている。
自分が消していない部分に遅さがあるという意味だと、画像処理や C++ の中にある余計なコードがクリティカルパスにある可能性もある。画像処理パイプラインの「機能」は、わかる人には消せるのかもしれないが自分にはむずかしい。そしてこれらの「機能」は年々複雑化が進み、遅くなっている。
もうちょっと red herring な説: 一旦コードに持ち込まれた複雑さは、単純にコードを消すだけではキャンセルすることができない。たとえば新しい機能のためにリファクタリングして間接化や抽象化を足したとする。コードを消すと抽象化の裏にある実装は消えるが、抽象や間接化そのものが消えるわけではない。コードを消したら、そのあとよくコードを読み直して余計な抽象化を見つけ出し、それをベタなコードになおしてはじめてオーバーヘッドを取り除くことができる。かもしれない。自分は心の奥底でこの説を信じている一方、検証するのは難しいいイチャモンという面もあるのであまり強く主張する気にもなれない。
いずれにせよ「コードがでかくなると遅くなる」というのは必ずしも絶対的な真実ではないし、逆が真とも限らない。たとえばデスクトップ環境に巨大なアプリをインストールしたところで（そのアプリを起動しなければ）対して遅くはならない。一方でサーバに daemon の類をインストールすれば少しは遅くなるだろう。Android のアプリはその間くらい。単一プログラム内の余計なコードがデスクトップアプリのインストールとサーバの daemon のどちらに近いかは、ケースバイケース。というわけで「コードがでかい = 遅い」は経験則のひとつに留め、鵜呑みするのはやめましょう、という話。
そしてコードを消す話をするといつもこれを思い出してしまう人生の呪い。
Women's Work: A Reckoning with Work and Home
The Decade of the Parenting Manual - NYT Parenting で紹介されていたので読んでみた。ここにある本は半分くらい読んでおり我ながらサヨリべすぎて苦笑。そしてマニュアルではなく読み物ばかりだな、このリスト。
この "Women's Work" も例にもれず子育てガイドではなく読み物だった。著者自身の Memoir. もともと新聞記者の海外特派員だった著者が中国(北京)で妊娠し（配偶者もジャーナリストとして一緒に中国にいた）、新聞社の仕事をやめて子育てしながら本を書いてライターとしてのキャリアを続けようとする。しかし非協力的な夫を通じてジェンダー格差の現実に面し仕事が進まず、仕方なく nanny を雇ってみたら今度は中国の貧困やジェンダー格差に加担している自分に気づき思い悩む、という話。途中で第二子が生まれ、そのタイミングで夫の仕事の都合にあわせインド(New Delhi)に引っ越す。そこでまた nanny を雇い、同じ悩みを繰り返す。
ここで終わると傲慢なアメリカ人のうざい独り言なのだが、後半ではジャーナリストとして過去に自分が雇った（そのうち一人はクビにした）nanny に会いに行ってインタビューをする。そこは面白い。自分が employee として見ていた nanny たちのおかれた現実をジャーナリストとして revisit する著者の倫理的葛藤みたいのがよく書けている。
あと「うざい独り言」はやや言い過ぎで、自分も外国で子を育てている手前、そこにはある種の共感があった（インドに住むアメリカ人と比べるとカネの力で殴る経済力はないが）。そして自分はジェンダー格差の受益者なので、著者が夫にブチ切れるところでは胃が痛んだ。この手の本にでてくる夫は割とみんなひどい気がするのだが、自分がそうでないとなぜ言えよう・・・。
Amazon のレビューを見ると "White Privilege Horror Show" という批判がある。でも著者はそれに自覚的で、けれどその傲慢さを隠さない正直さみたいなのが面白いと思う。自分も読んでいる途中で著者のアメリカ人っぷりに笑ってしまう箇所がいくつもあった。書き手としての「声」がある点で「正しさ」に塗り固められた Lean In より個人的には好ましい。声といえば audiobook の narration はその鼻持ちなら無さを完璧にとらえており、最近きいた audiobook の中では最高峰の出来。
子供ができたら親である自分のキャリアは終わる。それは仕方ない。理由はどうであれ、多くの母親が仕事を辞め専業母親化する事実がそれを伝えている。そうしたコストの fair share を引き取ろうとしたら、定時強制の化石技能な万年末端になるくらいは妥当。理屈ではそうわかっていても、日々の impluse がしらずしらずのうちに privilege を claim してしまう。たまにこういう本を読み calibrate していきたい。
割と良かった。スタートアップは陰謀論でカルトなんだよ！と衒いもなく言い切る政治的正しく無さといい、なにかと引用される文献が渋いところといい、ファンもアンチも多いのがよくわかる。過剰なかっこよさ。あと薄いのも良いね。個人的には、世界の秘密を暴けるような仕事がよいという下りがよかった。
リーンスタートアップどういう話か忘れてたのでいい復習になった。ちゃんと innovation accounting してる企業がどれだけあるのか見当もつかないし大企業にそれを売り込める気もまったくしないが、シリコンバレーの会社というのはこういうのを読んだり本物のスタートアップで体感したりした下々が草の根的に存在するので、上の方が雑でも少しはスタートアップ・ウェイがまじりこむのだろうなと思った。
Amazon のレビューを読むと「風呂敷広げすぎ」「よくある企業改革論」みたいな批判が目につく。まあそうなのだろうね。アイデアは Lean Startup から変わってない気がするので。
こういうビジネス書を読んではなくそほじりながらフンフンとかいってるあたり我ながらおっさんだなー。ちなみに actionable な要素は特になし。
via Graphics and Gaming Development | The Bifrost Shader Core – Arm Developer
ARM の割と新しめな GPU (Bifrost) の資料を眺める。
ARM の GPU には複数の "Shader Core" がある。最大で 32 個くらい。NVIDIA の GPU でいう SM に相当する、とおもわれる。
個々の Shader Core には複数の "Execution Engine" が入っている。上の資料で参照されている G71 というやつ（最新ではない）だと 3 つの EE が入っているらしい。EE は NVIDIA の GPU でいうところの "CUDA Core" みたいなものだと思われる。
適当な NVIDIA の GPU (ここでは Turing) の資料とくらべてみる。
Turing の SM の数は、構成によって 28-72 個である。一方で SM あたりの CUDA Core の数は 64-128 である。この比率は ARM GPU とだいぶ違う。SM/Share Core の数はせいぜい数倍程度しか違わない一方、それらあたりの EE / CUDA Core の数は 10-20 倍違う。ARM も EE の SIMD 並列化を "Warp" と呼んでいるが、NVIDIA の Warp と比べると断然狭い、グラフィクスの頂点一個を並列処理するくらいがせいぜいに見える。
これは自分の直感の逆だった。ARM の GPU は、SIMD つきのシンプルなマルチコア CPU といった風情。しかもコア数が CPU より多い。GPU はおもったよりたくさんの異種タスクを詰め込めるように見える（他にボトルネックがなければ）。一方で NVIDIA の GPU が想定されているようなでかいベクトルをバンと並列に計算する能力を個々の Shader Core は持っていない。
これは・・・どうなの？少なくとも OpenGL を使っている限り単一プロセスがこのマルチコアの性能を完全に引き出すことはできないよね。なぜなら OpenGL はマルチスレッドのタスクを投げられない・・・というと語弊があるが投げにくいから。もちろんでかい頂点列をマルチコア向けに分割して処理するくらいは GPU なりドライバなりがやってると思うけれども, NVIDIA が暗に築いてきたメンタルモデルを逆手に取る利点はなんかあるのだろうか・・・。不思議。まあ色々なプロセスやスレッドから同時に叩かれるのを助ける面はあるかもしれない。
ARM GPU の理解を深めても自分の役には立たない。Qualcomm の GPU はどうなってんだろう・・・と調べるが、さっぱりわからん。相変わらずだなこいつらは・・・。
Picture Taking Practice をはじめて現在 36 日分経過。
- 完全に毎日はできないが、まあいいです。人間風邪引いたり調子わるかったりするので。精神衛生を損なうと写真を撮らなくなりがちで、ある意味バロメータになっている。
- 一日に一回 curate する頻度は割とちょうどいい感じがする。寝る前に 10 分くらいなので負担がない。
- 家族日記として機能している。自分の個人的な記録はないが、どこいったみたいな家族としての記録が残るのはよい。
- どうせとるならフルフレームが欲しいなーと思う一方、でかいのはムリだなという気分も深まる。でかいカメラを抱えて隣の公園で散歩するのもやはり silly に感じてしまうので。APS-C くらいでいいのかもなあ・・・というか 4/3 でいいのか・・・など無駄な物欲的悩み。
- アプリ的な話
- 奥様にも写真を追加してもらうようにした。Photos はこれができるのが便利。
- Timelapse がすばらしい。日常の banality も圧縮によって消える。
- Portrait も、被写体を強調する目的でだいぶよい。ボケはひきつづきだいぶ雑だが、Pixel 4 は激しい壊れ方をすることは減った(人間相手なら）。スマホで眺める分には許容範囲かなと思う。
- Night mode は子供を録るには不向き。水族館でも普通の Photo mode の方が良い。
- 週末、プレイデート友達家族と外出した先で子らが遊ぶ様子を両親 x2 の四名がスマホで写真をとる瞬間にはその sillyness に躊躇がある。
- カメラアプリのバグに遭遇しがち。ぐぐぐ・・・。
I'm resuming my snippets from today. I have little-to-no time for intellectual activity these days. so I'm posting my physical activity (running) and the body weight.
- Running 3/5
- Body weight: (Goal: 65kg)
自己デバッグはとくになし。
休暇中に精神衛生の劣化が限度を超えてしまい、ふと思い出して朝にジムで走ってみると・・・世界が！明るくなったぞ！（比喩的に！）そういえば走った日ってこういうかんじだったわ。すっかり忘れていた。トラブル気味だった大腸も元気になった。
スクーター通勤に切り替えて以来運動ができていなかったが、それでも通勤という軽運動はしていた。しかし休暇に入りそれすら途絶えていた。もっというと、通勤ランは色々気が散りがちでジムで走るほどの効能はない。ジムで走るみたいな純粋な心拍数向上活動は子が生まれて以来三年ぶりくらいな気がする。
睡眠に続き、目をそらしていた健康上の懸念を突きつけられた気分。じっさい休暇中は色々とストレスがたまりがちで、夫婦間の空気を険悪にしないようかなりの努力を要した（つまり、たぶんちょっと険悪になってたね。）色々理由を考えていたが、単に運動不足だったとは。脳内麻薬欠乏やばい。
やはり運動は必要に思える。薬物の質という点でジムなり公園で走るのが望ましい。そして薬効を最大限活かすには朝がよい。休暇前は朝おきて会社のメールを読んでいたが、これは諦めてジムに行くべし。
とはいえジムでの運動は着替えやシャワーを含む E2E で一時間。きびしい。5:00 に起きて、5:30-6:30 運動、そのあと家事。朝のメールが消える結果、8 時間労働を達成できない問題は振り出しに戻ってしまう。このトレードオフは字面からはあまり自明でないが、脳内麻薬の欠乏（に無自覚であること）は無視しがたい恐怖を感じるのではやり運動は取り戻したい。
一方、これを時間割とすると家でラップトップを触る時間はほぼ消えてなくなる。いまは就寝前にちょこっとさわったりしているが、大して生産的でない割に睡眠を削ってしまい望ましくない。
年末からは fast を兼ねて会社では昼飯を食べず、かつちょっと時間をちょろまかして昼食前後一時間半くらいを課外活動に当てている。これが自分の課外活動の全てとなる。八時間労働できないのに時間ちょろまかすのどうなの、という話はあるけれど、ただ子の着替えやトイレを待つのに使う時間と課外活動に使う時間ではトレードオフの妥当性が違うのだよ。
家でパソコンとかさわらないプログラマってこういうかんじか・・・ほんとに・・・？しかしここで躊躇して運動しないと鬱病になってしまうのでとりあえず運動はします。はい。今日もスタバまで走ってきたよ。