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 はどうなってんだろう・・・と調べるが、さっぱりわからん。相変わらずだなこいつらは・・・。
via Learning at work is work, and we must make space for it | Hacker News
HN のコメ欄は本文を読まずヘッドラインだけみて言いたいことだけいっているクソコメで盛り上がっているが、自分も興味のあるテーマだったので PDF を買って読んだ。
内容としては: "Boot Camp" みたいのでなにかを勉強したり教わったりしてスキルや知識を身につけるのは "Incremental Learning" であって、大きな飛躍はない。一方 "Playground" で実際になにかをやって、その体験を内省的に振り返り、新しい自分を発見する "Transformative Learning" には飛躍がある、そういうのをやろうな・・・みたいな話だった。Kate Matsudaira 的 BS 感・・・というと語弊があるが他人事感・・・を拭いきれないが、著者は HR 方面の人なのでそれも仕方なし。
たとえば delegate できないリーダーが例として登場する。そのひとたちは失敗できないがゆえに delegate できない、だから色々なことを試してちょっと失敗してもいい learning のための space をつくってやるのが組織に必要なことである。みたいな話をする。そして企業が transform するには、そういう space をシステマティックにつくる playground をトレーニングに組み込もうな、と結論づける。後半にいくほどどうでもいい。しかしこの記事は企業の digital transformation (ってなに?) を応援する issue の一部なので、書き手に文句をいう筋合いはない。釣られた HN が悪い。
自分はというと、出世パスに乗っていないおかげでまあまあ transformative learning をする機会を持てているなとは思う。一方、下っ端プログラマが生存するために必要なのは仕事を通じてものの見方を transform することではなく、機械学習とかクラウドとかがわかるようになることではないか、というと極端だけれども、知識やスキルというのは下っ端には必要なのだよ。リーダーシップの皆さんはそういうの足りてる前提で話してますけどね・・・。
というわけで「俺は仕事中もコソコソ勉強してるぜ」みたいな HN のコメが本文を読んでないゴミであるといいつつも、その sentiment には共感があるのだった。
ところでなにかと脊髄反射で悪口をいいがちな Kate Matsudaira, いま何してるのかなこのひと、と見てみたら・・・あまり人の悪口とかをいうのはよくないですね、という良い例でありました。はい。ごめんなさいね。
via Why Is the World So Loud? - The Atlantic
Arizona に住む男が近隣を覆いはじめた謎の騒音に苛立ち、正体を追いかけたらデータセンターだった、なんとかしたかったが行政とかは全然助けてくれなかった、という話。2つの点で興味深かった。
まずアメリカってなんだか妙に色々音がデカイなとは引っ越してきてからずっと思っており、その印象を裏付けてくれた面があること (aka. the confirmation bias.)
家の外は電車、車、芝刈り機に枯葉掃除機、謎の排熱施設など。屋内も掃除機、洗濯機、食洗機、冷蔵庫、空調までなにかと音がデカイ。まあアメリカは主語でかすぎで a suburban cheap apartment dweller perspective である点は disclaimer すべきだけれども、音でかいよね。なにかと。日本は無駄な音楽やアナウンスを流すスピーカーからの音害がしばしば非難されるが、それ以外は割と全て静かじゃん。スイスとかフランスとかそれすらなく完全に静かで素晴らしかったなそういえば・・・。
二点目として、データセンターと石油の比喩的な近接。巨大資本の富の源泉である点には以前から親しさを感じていたが、赤くて貧しい州の規制の弱さにつけこんで環境を犠牲に資源を吸い出している点にも類似性がある。データセンターは建物がでかく排熱がある点である程度は環境負荷があると誰もが感じているだろうけれど、個体差はあるとはいえまさか騒音が届くような近所に人が住んでいるとは思わなかった。
データセンターの騒音は、他の環境問題にくらべると技術的にはまだいくらでも改善の余地があるように思える。防音の施策は色々ありうるし、立地だって妥協できる。一方、問題の相対的な subtle さと巨大資本のアグレッシブさを照らし合わせると対策がなされる期待も薄い。記事も漂う悲しさ、無力感を伝えようとしている。資本と地域コミュニティの一方的な戦い。
こうしてみるとデータセンターの騒音ってすごいアメリカ的な現象だね。そしてふと思い出すに、大手町のデータセンターはすごく日本的というか東京的な存在だった。金融オフィス街のビルの一つがさりげなくデータセンターであるカオス感というか詰め込み感というか。クラウド以前の牧歌的な存在だったとも言えるが。シンガポールのデータセンター群はどういう立地なのだろう。
なおリンク先の記事は無駄に長い上にデータセンターの騒音問題自体はあまりちゃんと取材していないので、がんばって読む価値は薄め。
via Blow to 10,000-hour rule as study finds practice doesn't always make perfect | Science | The Guardian
モダン根性論ポップカルチャーのはしりのひとつ Outliers (5000 Amazon reviews!) が論拠としている 1993 年の研究を replicate しようとしたけどだめでした、という研究の話。ふーんとリンク先の論文も眺める: The role of deliberate practice in expert performance: revisiting Ericsson, Krampe & Tesch-Römer (1993) | Royal Society Open Science. 割と面白い。
- 元研究、およびこの研究は great, good, less good の violinist をあつめて比較している。これどうやってあつめるかというと: Great と good は一つのエリート音楽学校からサンプルする。具体的には学校の教師にノミネートしてもらう。Less good はエリートではない音楽学校から適当にサンプルする。
- モダン根性論用語になった "deliberate practice", 具体的には "teacher-designed practice" だった。対にあるのは self-guided practice らしい。Deliberate practice ってなんとなく自分で工夫して負荷を高めるもののように考えていたけれど逆だった・・・というか、もともとは Delibrate practice の定義は存在しなかった、あるいは主張に応じてコロコロ変わった、らしい (4.1)。この論文は元論文著者 Ericsson の雑さを強く批判している。
- 練習以外の activities についても時間の情報を集めている (table 3). たとえば "意識の高い会話 (professional conversation)" みたいのもはいってる。
この論文のキーとなる発見は
- Good および Great 勢は Less Good 勢より圧倒的に練習している。
- Great 勢と Good 勢は practice も teacher-designed practice も大差ない。（むしろ great 勢の方がちょっと少ない。)
この論文の趣旨はオリジナル論文の主張の replication なのでそのほかの点については細かく議論していないが、外野としてグラフを眺めるとなかなか趣深い。特に "3.5. Retrospective estimates of practice during development" のセクション、自己申告による練習時間の経年変化。
- Best 勢は人生序盤 (8 歳くらいまで) の teacher-designed practice の量が Good/Less Good よりだいぶ多い。しかし 12 歳あたりで Good が逆転する。つまり violin で Great になるには幼少期に教師に鍛えられるのが重要なのではないか。逆に一定程度年をとったあとにキャッチアップしようとしても難しいのかもね。この一定程度というのが 12 歳であるあたりに violin 業界の厳しさを感じるが。
- Good 勢の練習量は 15 歳あたりから Best よりもだいぶ多い。(二割くらい違う。) そして Good の練習量は 18 歳に向けてどんどん増えていくが、そこで頭打ちになり下がり始める。一方 Best 勢の練習量（Good 勢より少ない)は 18 歳を過ぎても下がらない。ボンクラ努力家が 18 で自分の限界に気付かされる様を見るようで気の毒。
音楽の世界は厳しいなあ・・・。
あと Best と Good が同じ学校の同級生で、Less Good は別の学校という事実にも趣があるね。Good/Great と Less Good の差はほとんど peer pressure で説明できそう。実力をつけたいなら厳しい環境に身を置くのが大事だね。
プログラマ、音楽家と比べるとほんとに平和なものでよかったな・・・と思う。
- Best でなくてもふつうに生活できる。
- 幼少期にプログラミングを教えてくれる teacher とかいない (少なくとも一般的でない). Teacher-designed practice もあんましない。
Best と Good を violinist を区別するものが (12 歳以降の) practice でないならなんなのか。幼少時の訓練なのか「才能」なのかそれとも他のなにかなのかはよくわからないが、音楽のように成熟した世界ですらこれなのだから、プログラマみたいに雑で新しい世界でそこそこの成果を出したいなら、いくらでもやりようはあるのだろうね。まあ AI 方面はアカデミアという超成熟した過当競争世界にも見えるけれど。
via ニューヨーク・タイムズは日本を「独裁政権」と呼んだのか、気炎を吐いても息さわやか - ネットロアをめぐる冒険
珍しく NYT が話題になってるので眺める。
- 朝日新聞、というか新聞全般はいつも元記事をリンクしないのがひどい。
- それはそれとして <Japan is a modern democracy where freedom of the press is enshrined in the Constitution, which American occupiers drafted after the war. It is not the kind of place where journalists are denounced as the “enemy of the people.” Still> ときて <the government sometimes behaves in ways more reminiscent of authoritarian regimes> と「現代民主主義」の対なうえに "regime" なんだからネガティブさを強調する語として「独裁政権」は別によくね？
- リンクされてる「権威主義体制」訳の文章はアカデミアの書いたテキストで、それとこのライトなポートレイト記事の訳を比べても仕方なくね？
- NYTimes がすごい無色透明な報道機関であるという前提がある気がするが左よりで opinionated なメディアだし、そうでなくてもアメリカのニュースは(リンク元の asahi.com の特集が示唆するように) Trump がらみで言論の自由にピリピリしてるんだから、歯に衣着せぬ感じな「それでも日本政府はときに独裁政権をほうふつとさせる振る舞いをしている」という訳は権威主義体制みたいなやんわりワードより雰囲気を伝えている。なにかニュートラルな話をしてるんじゃなくて直球でディスらてんのよ？そのニュアンスを伝えたかったんでしょ。
- まあ記事はディスりが本題ではなくこの記者の存在の興味深さなので、NYT が日本を独裁のようと批判したとする cherry picking がフェアかどうかはまた別。どちらかというと掴みためののレトリックじゃね。
- ちなみにコメント数を見ればわかるとおりアメリカ人には興味ない話題なのだった。東の方には独裁政権いっぱいあるからね。（自分も冒頭記事を読むまで Ms. Mochizuki 知らなかった。日本のニュースもうちょっと読んだほうがいいな・・・）
Fragment に書いていたら長くなったので別記事にしてみる、という実験。
一歩下がって考えるに、これは翻訳というものの限界な気がする。
自分の感覚だと「権威主義」という言葉はアメリカ人のいう "authoritarian" ほどネガティブな空気を纏っていない。それはたぶん歴史的に割と authoritarianism っぽい文化が通底しているからな気がする。ついでに「体制」という後も、戦後すぐならともかく 21 世紀には "regime" ほどネガティブなニュアンスがない。
なので "権威主義体制" は直訳としては正確だが "authoritarian regime" という語が孕む「うげーヤベーなあいつら」という雰囲気を伝えていない。でもこれって直接的な意味のマッピングと価値観や雰囲気のマッピングの間にある不一致がうんだ lost in translation だよね。
ついでにアメリカ人にしてみれば authoritarian も dictatorship も等しく悪なので、そこを繊細に使い分ける動機はない。NYT の寄稿者の中にはそういうのを気にする書き手もいるだろうけれど。リンク先の記事はもうちょっと雑。
朝日新聞の記事が雑さのギャップにつけこんで我田引水してるのは事実だと思うのでそこにケチをつけるのはいいと思うけど、ある語の訳を nitpick するのは生産的ではない気がする。
メタなマウントとして、リンク先の記事も朝日新聞も NYT を絶対視しすぎ。NYT -> asahi.com でもちこまれた歪曲は NYT 元記事の左傾や雑さによる歪みに対して significant なのか？NYT いいメディアだけど別に隈なくクオリティ高いわけじゃないよ？日本の話なんてとくに眉唾がちなんだから、ちゃんと読んでケチつけといたほうがよくね？
我ながらクソのような出羽守を書いてしまった・・・。しかしそうした衝動の掃き溜めとしてブログ書いてるからいいのです。
via Antitrust 3: Big Tech : Planet Money : NPR
Planet Money が三回シリーズで Antitrust を扱っていた。その中で紹介されていた論文 Yale Law Journal - Amazon’s Antitrust Paradox, NYTimes で紹介されたのをきっかけにブレイクしたという。自分も antitrust まわりに気をつけるようになったのはこの記事がきっかけだった。論文は 1/3 くらい読んで放置してあるが・・・（長いのだよ。）
別のきっかけは Exponent の Episode 153 — Black Holes. 上の論文は Amazon の分割を提案しているらしいけれど、このエピソードでは Facebook による競合の買収を問題視している。NPR のエピソードでも同じことを主張する人が登場した。
Tech 大企業はいっぱいあるので、一社が（たとえば倫理的な判断から）買収を遠慮したりすると、別の会社に攫われてしまう。競争がある故にいろいろえげつなくなりがちな面はある気がする、ので法が頑張るのはそんなに悪くなさそう。ちゃんと機能するのかは疑わしいが、やってみて機能したりしなかったりするなかゆらゆらと調整するのが民主主義、法治国家の歴史だとも思う。
そういう法律は大企業だけでなくスタートアップにも影響ありそうだよね。主要な exist path だった買収に暗雲が漂うわけだから。
いずれにせよ Antitrust はもうちょっと色々読むなりして心の準備をしたいかんじ。
via Block ads in apps on Android (including video ads) - unlike kinds
フーンどうやるのかな、とおもってコードを覗こうとしたが GPL3 だったので諦め。周辺情報を総合すると VPN として振る舞うらしい。
これを使えば /etc/hosts の代替品となるのではなかろうか。でも VPN ってことはアプリをぜんぶのパケットが通ってくのかな。それは雑に作ると性能でなそうだが・・・。
そしてなぜか app store でなく f-droid で配布してるけれど、Ad-blocker は Playstore の規約に触れるのかな。まあ触れてもおかしくないな。自分用なら adb install すればよさそうではある。
サンプルの ToyVPN を見ると・・・ IP packet がストリームとしてやってくるのか。厳しい。一方で VpnService.Builder をみると DNS を指定できる。
なんとなくインプロセスの DNS を実装してそいつが /etc/hosts 的に twitter.com などをブロックし、IP パケットは素通しする、というような実装ができると一番簡単に思えるがどうなのだろうな。素通しは必要なシステムコールを特定すればなんとかなるとして、インプロセスの DNS は手強い・・・。なお ToyVPN は linux の tunneling の仕組みに丸投げする実装になっている。
DNS はインプロセスじゃなくてどっかに自分で立てる、という方向性もありうるか。どのみちそこまでがんばって実装する気にはならないなあ・・・。
ここまで。Android の VPN の API を眺めることができたのでよしとする。
更にスレを読み進めると、Android P はユーザが DNS サーバを上書きできるのか。(Cloudflare の説明) これでやるのが一番簡単そうだなあ。しかし DNS サーバを運用するのみならず DNS-over-TLS をサポートしたやつを使うとか大変そうすぎる・・・。誰かそういうサーバ立ててくれないかなー・・・。
via You probably don't need a single-page app | Hacker News
自分も手元に SPA の悪口を書いた draft があるのだが、世間での hate が高まっているところに加えて言うこともないかなと思う。
なお自分は不満は開発者としてではなくユーザとしてのものである。すなわち世のウェブ製品や内製のツールが SPA になったとたん URL が壊れるなど激しくゴミ化する現象が観測され、気に入らないという話。出来の悪いコードというのはいつの世にもあるのだけれど、内製ツールという観点だとダメージの現れ方が厳しいと思う。
この話は長々書いても悪口にしかならないのでやめとこう。
それよりは、出来の悪い SPA はなぜ生まれるのかを考えて見る方がいい気がする。個人的には Web というプラットホームが十分な基盤を提供してないせいだと思う。JS フレームワークの未熟さみたいのはそのうち解決するだろうから。
SPA は、伝統的なウェブにあった URL 単位の "画面" という単位が希薄になりがちである。その昔, URL はユーザにとっては文脈を特定するコンパクトな表現であり、同時にウェブアプリにとっては serving というわかりやすい抽象化の単位であった。つまり URL のわかりやすさはユーザにとっても開発者にとってもある程度有り難みがあった。
ところが SPA になると開発者にとっての URL は単なる負担になる。画面という抽象化の単位に自動的に URL がつかなくなるから。なのでサボって腐ることが増える。ウェブやブラウザという patform は、ウェブプログラマに良い URL をデザインする incentive を用意しないといけない。そうしないとサボられてしまう。
素人の意見としては TurboLinks みたいのをもうちょっと洗練させて標準にすればよいのではないかと思う。つまり、JS のコードやある種のサイトグローバルなデータはインメモリに残しつつ、ページ単位のデータを新しい URL のもとに取得しなおす。ある意味では JS フレームワークの router みたいなもんだが、それを何らかの形でブラウザが提供し、それは JS だけだと実現できない何らかの有り難みがあるとよい。
完全に口から出まかせを続けると、そのためには API から serve される JSON が一級市民にならないといけない。もっというと "JSON のレンダリング" みたいな概念が一級市民として必要に思える。20 年くらい前は XSLT がそれだったわけで、XSLT は概ね失敗したのでたぶん普通にやると失敗するからもっとうまくやらねばならず、自明でないデザイン上の難さがある。Service Worker からもう三歩くらい進めばなんとかならない？だめ？
URL がぶっこわれていてリンクも scrape もできない dashboard や CRUD UI は心底うんざり。そういうのを作ったやつが悪いのは確かだが、ウェブがしゃきっとしないから治安が悪くなったのも事実だと思うのだよね。
Android だと Activity がプラットホーム提供の画面単位の抽象化単位として機能している。Activity をすっとばした SPA 的アプローチも一瞬流行りかけたが、今のところ主流にはなっていない。React Native にやられてしまうかもしれないけれど。
ウェブも Android も React にやられかけているというのは興味深い現象であることよ。
via google/mobly: E2E test framework for tests with complex environment requirements.
最近性能テストの自動化にこれを使っている。まあまあ良い。良さの一部は lab の実機で CI するインフラを誰かが用意してくれているから、というツール自体とは無関係なものだけれど、テストコードが host 側で動き、しかもそれが Python だというのも良い。
原則としてこうした E2E のテストは保守性の点で望ましくないことが多く最小限にすべきなのだが、性能のベンチマークばかりは実機でやりたいし、環境をいじる必要もあるのでホスト側の adb で色々やりたい。そして自分の関心は特定のコードの挙動でなくシステムとしての遅さなのだった。
Mobly をランダムな他人に進めるかというと・・・どうだろうね。ちょっと大げさすぎる気はする。しばらくは plain python でがんばってみて、辛くなったら調べてみるくらいでいいのではないかな。ホスト側でテストを動かすというコアのアイデアが重要だと思う。
それはさておき仕事で python を書くのは新しく学ぶことが多くて楽しい。文法とかは今更特に学ぶところはないが、社内インフラをはじめ色々なライブラリを使い、他人のコードレビューを通せる程度にはゴミでないコードを書くと、余暇プロジェクトや書き捨てのスクリプトとは違う仕事の手触りがある。
via Androidにおけるパフォーマンスチューニング実践 - Speaker Deck
世間の期待値的には性能の話がこれでいいのか・・・別にリンク先のひとを腐したいわけではなく、2019 年にこんな話なのか・・・と割と心の底からびっくりしてしまったのでひっそり記録したかったという話。なお別にこういう話をしているからその人たちのアプリが遅いといいたいわけではない。地味にコツコツやればそこそこ速くなるジャンルはたくさんあるから。それでいいならそれでよいのです。
つい Twitter に余計なことを書いてしまったが完全に言いがかりだったと反省。
講演きいてないのでわからないけれど、リンク先の資料に問題があるとすれば計測して、詳しく見て問題を特定して、それを速くする、というサイクルが感じられないところかな。高速化、そのサイクルが一番下にないとカーゴカルト黒魔術みたいのになりがち。
追記
スライドの人が dex.fm に出ていたことに気づいたので聴いてみた。ちゃんと仕事してる人だった。我ながら言いがかりよくないわ。
dex.fm — 064: Performance Tuning
こういう人の話を聴いてみると、自分のやってる仕事は単に職場のインフラを exploit しているだけだなあと思う。たとえばベンチマークの自動化にしても lab なり dashboarding なり scheduled execution なりの仕組みはもうあるので、それを寄せ集めれば良い。
というか自分はそれすらできず、半年くらい前にやってきた別の人が別の目的で寄せ集めた自分のチーム向けのセットアップに相乗りしている。一番大変な connecting pieces 作業はそのひとが済ませてくれたので、自分はその上でちょっとコードを書けば良い。
自分の作業はアプリ側からメトリクスを expose する側に寄っているのでちょっと守備範囲が違うとも言えるが、そのアプリ側の仕事にしても昔だれかがやったまま放置していたコードを整理復旧して使い物にしただけで、特にすごく何かをがんばったわけではない。まあこれは前のチームで割とがんばった部分なのでやればできるとは思うが・・・。
こうした仕事に価値がないとは思わない。実際自動化によってカバレッジがあがり、早い段階で性能バグを発見できるようになったわけだから。ただまあ、リンク先の人のような全方位的活躍とは程遠い。
他人の仕事を寄せ集めるだけで成果がでるのも、他人の仕事を寄せ集めるのが大変なのも、大企業であることよ。最近やってきたできるエンジニアは「俺はコードは書かない。他人のコードをコピペするだけだ」と冗談交じりに言っていて、そういう面なあるなと思う。コピペ元コードの出処が社内コードサーチか SO かの違いで世間のプログラマも割とそんなもんなのではという気もする。はさておき。
部品を寄せ集める大変さを考えると大企業で社内インフラに乗るのだろうがスタートアップでオープンソースに乗るのだろうが大差なくね、というのは常々感じているオープンソースもっと使わせろという不満につながるわけだが、自動化のインフラはコードだけでなくサービスの operation も必要な類なのでまあ仕方ないかなと思う。過剰な大変さはなんとかしてほしい気もする一方、サーバ側と比べた時の社内のモバイル回りの筋の悪さには諦めもある。
via [1.3] arter97 kernel for OnePlus 6 - Post #56
No, I'm actually not going to refine this as I'm quite certain this is due to the bulls**t OnePlus is doing with schedulers to boost certain whitelisted apps such as Snapchat.
Those crap OnePlus code, which is just hard to look at, may improve user experience, but I'm just refusing to put cancer in to my kernel. These are just bandaids on top of another multiple layers of bandaids that are prone to cause more problems down the road.
Oneplus はカーネルレベルで Snapchat を優遇しているのか・・・。自分もカーネルレベルで優遇してほしいもんだわ。無理だが。なんとかして一般的なフレームワークでこういうのできないのかなあ。
via Profilo · An Android performance library
コードを眺めているが・・・。すごいなこれ。
すごいところを列挙するのはあとでやるとして、Android の C++ レイヤの練度で見ると Facebook は自分の勤務先を含む多くの会社を圧倒している気がする。
たとえば Chrome なんかは単純に C++ のコードベースとして見れば割と比類ない練度だと思うけれども、基本的にはデスクトップアプリだから Android らしさというのはない。Facebook から出てくるライブラリの C++ は Android らしさを感じる。しかも Android が好きで良さを引き出そうというよりは、Android の弱点にくまなく付け込んで攻略するという方向性。これは自分の好みに近い。
自分の勤務先は根本的にはウェブの会社で、モバイル対応はなんとなく場当たり的に行われた。上の方は mobile first と旗を振ったけれど、なにをすべきなのかは誰もよくわかっていなかった。各チームがそれぞれ勝手に色々やっていたため、全社共通の基盤みたいのの整備が遅れた。さすがに今はちゃんとしてきたけれども、インフラから整然と作っていったサーバ側とはだいぶ趣が違う。そしてアプリインフラ的なレイヤを主導しているのが Java の人なせいか C++ レイヤは未だに荒野感がある。まあ Android の低レベルの仕事をしたいプログラマの多くはアプリじゃなくて OS やると思うんだよね。アプリとして C++ 書きたい人、そんなにいない気がする。
この話とはちょっと矛盾するけれども、初期にモバイル対応 (Android アプリ開発) を主導した現場の人の多くは Android OS 出身者で、自分のアプリのために Android のギリギリを攻めて行こうというよりは Android ecosystem の良き市民であろうという意識が強かった。だから platform の .so を dlopen() してシンボルをぶっこぬく、とか多分やらない。Java レイヤの hidden API を reflection でよぶくらいがせいぜい。自分たちのチームにしても、OS やデバイスがやるべきことは自分で妙なハックをしたりせず OS やデバイスの人に頼む。(自分はそれがあまり好きでないが、妥当だとは思っている。)
ふりかえって Facebook を見るに、彼らの mobile first はなにをすべきかはっきりしていた。Facebook アプリに全部の機能を詰め込んでちゃんと動くようにすればよい。そう決断したタイミングがすごく早かったとは思わないけれども、とにかくチームが、そしてコードベースが一つのアプリを中心に編成された。だからライブラリなどのインフラも大規模コードベースらしく整備されているし、よく書けてる。
しかも低レベルでいろいろやりたいプログラマに OS をやるという選択肢がない。彼らはそのかわりにアプリの中で色々無茶なハックをしてウサを晴らしたのだろう。OS のコードをコピーし、アプリ固有の事情にあわせツールチェインを魔改造し・・・といった具合に。
まあこれらは完全な想像だけれども、Profilo および依存先 C++ のコードには大量につっこまれたエンジニアリング資源の匂いがあるね。Android がアプリレイヤでどこまで無茶できるかを体験するには面白いところなのだろうな Facebook. まあコード読んで勉強させていただきますわ。
via I interviewed at six top companies in Silicon Valley in six days | Hacker News
また HN が大企業コーディングクイズ問題で荒れていた。自分の見解は前に書いたが、この話はコーディングクイズを肯定する前提で書いた。HN のトップコメントはしかしアンチコーディングクイズで、しかもなんとなくわかってないなあ・・・と感じてしまった。
なお以下の話は自分の意見であって別に勤務先などの見解を反映していない。
コーディングクイズがアルゴリズムを書かせがちなのは、別に CS の知識的なものを問いたいわけではなく、プログラミングの筋肉みたいなものを知りたいからだ。プログラミングには筋力/体力みたいなものが存在する。それは綺麗な抽象化を考える力とかアルゴリズムの知識とかではなく、目の前の積み上がったミクロな複雑さの山を押しのけてズカズカと前に進んで結果を出す速度みたいなもの。
アルゴリズム類のコーディングには抽象化でごまかせないむき出しの難しさがあるので、体力を試すのには割と向いてる。
体力が導く「成果」はかならずしも最終的な成果ではなく、試行錯誤のマイルストンに近い。目の前に自明でない問題がある。ここでいう問題は原因不明のバグかもしれないし、API デザインみたいなものかもしれない。そこでガガガっと色々試して解空間を探索して良い答えを出す力が筋力。知識があるほどよい初期解を選べる。体力があるほど広い空間を探索できる。
そういう筋力を使わずにできる仕事、良い初期解の近傍で乗り切れる仕事はたくさんある。そういう仕事の多くでは、規模から生まれる複雑さがプログラミングの主要な、しばしば唯一の、敵である。一方で世の中には筋力がないと解決できない仕事もある。そして実際に筋力がある人の働きを目にしないと、世の中にそういうものがあることには気づけない。
筋肉質な仕事ぶりを目にすると、ああアーキテクトとか別にどうでもいいな、という気持ちになる。規模に頼らなくても意味のある成果を出せることがわかるから。
体力だけあって抽象化とかの技能がないとそれはそれでやがて破綻する。けれどテック大企業、というと一般化しすぎだけれど自分の勤務先とかはそういう筋力で解く姿勢を重く見ている気がする。表立ってそれが語られることはなく、表面的には規模の複雑さを扱うほうが偉くなれることになっているが、空気を流れる ethos は筋肉を志向している、気がする。それを端的にあらわしているのがたとえば Jeff Dean Facts のような subculture である。
そういう価値観は必ずしもいいことばかりではなく、わかりやすい欠点としては manliness や heroium に傾倒しがちで teamwork や inclusiveness とは相性が悪いなど副作用もある。良くも悪くもそういうものというだけで。昨今の diversity awareness の高まりから生まれた古い subculuture に対するカウンターにはその綱引きを見ることができる（例 1, 2）。大企業はでかいだけあって価値観も一枚岩でない。ただ採用の仕組みとかは早い段階に固まってしまいがちで、結果として proto culture が染み出すのだろう。
そして自分は後ろめたさを感じつつこうした古い価値観を一定程度 preach しており、だから冒頭のようなコメントを読むとため息ついちゃうんだろうな。Manliness が大事って話じゃなくて、ばばばっとコード書きたいなということね。
筋力がないのに筋力がある人のように働こうとすると、初期解近傍で妥協するかわりに時間をかけて広い解空間を探そうとして仕事が遅い人になってしまうのだった。困る。しかしちょろい仕事をぱぱっとやるとかマジもう興味ない。価値観の呪い。
しかし冒頭のコメントの人は抽象化が大事とかいいつつコーディング練習するヒマがあったら乗っかるフレームワーク考えるのに時間使いたいわとか言っていて、現代における抽象化というものを考えてしまうよなあ。
via amakanサービス終了の経緯 | r7kamura on Patreon
シリーズ情報は誰かが提供してくれるものではないため、書籍の名前、カテゴリ（漫画、ライトノベル、雑誌など）や作者を amakan 側で解析し、良い感じに分類するということをやっていました。
前のチームにいたとき、漫画のタイトル（など）からシリーズを検出してまとめるコードの日本語対応をしてちょと頼まれ、適当に正規表現を書いた記憶がある。リンク先にも書いてある通り、書誌情報にはシリーズ番号が入っていることもあるが、入ってないこともあるのだった。
元のコードに正規表現やその他の細かいコードを足せば大体動いたが、それなりに奇妙なケースもあって (1上、1下... 3上、3下 みたいなのとか)、そういうのをちゃんと動くようにしたかは覚えていない。最後に計算量を変えるような微妙なコードを書いたがレビューされなかった、やんわりとした悲しみが残っている。
そのバッチは Cloud Dataflow の前身 FlumeJava で書かれており、自分が書いた唯一の production big data コードとなった。まあ正規表現なんだけど。
Flume みたいな並列のコードからガバっと叩いてバッチでデータ処理してもびくともしない Megastore だか Spanner だかはすごいな、という感想を持った。
via ngrok - secure introspectable tunnels to localhost
自分であげた GCE のインスタンスにある Jupyter をどこからでもさわりたい問題、ふと調べてみたら ngrok という port forwarding 業者を使えそうだとわかった。まあ今どき人々は Colab なのかもしんないけど、自分でインスタンスを持ちたいときには便利かもしんない。
個人事業主がやってるインディーっぽいサービス。しかし Webhook API を提供している業者のチュートリアルでは隈なく使われているという。インターネット、いいかげんでよいな。
via Android Rules - Bazel
慣れ以外で Bazel を使うそれなりにマシな理由としては native code が Android Studio 推奨の方法よりラクそう、というのがある。一方でその他のツーリングとかは標準 Android の方が良い気もするので、NDK まわりだけ Bazel を使えないかと考えてみる。
で android_library. 期待どおり AAR を出してくれる。つまり .so を含めることができる。Bazel で C++ と周辺の Java を書いて AAR にして、そっから先は好きにする、という方法はあるかもなあ。
そのうちためそう。
via C++ programming with Visual Studio Code
C++ mode の出来の良さに感銘を受けたのでちょっと真面目にショートカットなどを覚えてみる試み。さすがちゃんと定義されている。しかし Android Studio と混ざって若干つらい。べつにどちらがわるいせいでもないのだが。
定義にジャンプする機能で STL などシステムのヘッダまで潜っていけるのは素晴らしい。C++ に限れば全部のコードが読めるということで、これコードリーディングとかするとき素晴らしいのではなかろうか。
ただ C++ 環境の質の良さは若干とびぬけている気がする。Python とか Java とか Go とか Rust とか C++ じゃないけど大規模コードになりがちな子たちはどのくらいちゃんと動くのかなあ。
via Microsoft Edge: Making the web better through more open source collaboration - Windows Experience BlogWindows Experience Blog
Blink がフォークして、WebKit/Blink が the Web Renderer (というと Mozilla の人に怒られそうだが) でなくなってしまった失望はブラウザから足を洗うきっかけになったわけだけれども、その後エンドユーザ製品としての Chrome の嫌われぶりとは裏腹に Electron だの Brave だのなんだのの Chromium 派製品は割と幅を利かせ続け、ついに IE/Edge も(何らかの形で) Chromium ベースになる日が来た。
これは Chrome/Chromium がんばったという話ではもちろんあるわけだけれども、それ以上に Microsoft の Windows というか desktop のやる気のなさの表れとも言える。だから方針を巡って喧嘩になったりはしないだろうね。
最近 desktop(laptop) を新調した身としては複雑な気分。Apple の Mac のやる気の無さの結果 Macbook が全体的にぱっとしなくなってしまった一方、一時期の Macbook のがんばりでバーを引き上げられた Windows laptop 業界は (Windows を受け入れるなら) 割といい製品が増え、Apple ファンはしばしば悔しがっていた。そうした高評価 Windows laptop の仲間には Microsoft の Surface ファミリも含まれている。でも Windows 本体がやる気ないんじゃハードウェアがんばってもしゃあねえな、という話にならないのかね。Windows PC メーカーは後に引けないから頑張るしかないのかもしらんが。PC オワコン気味は仕方ないけど滅びたわでもないんだから各位もうちょっとがんばってくれないかなあ。
一方で、力が抜けて色々クロスプラットフォームフレンドリになった Windows は、自分のように歴史的経緯で Windows に拒否反応がでてしまう勢がもう PC でどうでもいいわ、力を抜いてと戻る先にもなりうる。5 年後, Windows 11 は Linux ベース、とかわけわかんないこといいだしても不思議ではないな。Windows 全然好きじゃないけど、すくなくともドライバを自分でビルドしなくてもきちんと動くからね。
インターネットをみてるとウェブ標準の行方を気にしている人が一定数いる。個人的にはウェブ標準にかぎらずこの手のコードを伴わない標準というものはオープンソースによってだいぶ役割が小さくなったと思っており、標準とか言ってないでコードの側で透明性を保つ方がいいんじゃないの、と思っている。たとえば新しいプログラミング言語で標準化がどうとか言ってるのほとんどないよね。昔は ANSI とか ISO とかで標準化していたのに。
まあ単一私企業が実質的な主導権を持ってるオープンソースプロジェクトに透明性を期待できないという主張はわかるので、去年書いたみたいに foundation にするのが良いと思っていたけれど、さすがに the ship has sailed でしょう。やるなら WebKit だったろうから。Turning points というのは事後的にしかわからないものだね。
via The Friendship That Made Google Huge | The New Yorker
Jeff / Sanjay が長いことペアプロをしていたというのは有名な話で、以前にもどこかで読んだことがある。自分が入社したころはまだやっていたらしいが、入社後初出張ツアーで冷やかしにいったときは不在だった。かわりに Gosling がいた。ははは。（遠くから見ただけだよ。）
AI 部門のトップになると聞いたとき、TensorFlow は Jeff Dean 最後の戦いなのだという自分の予感は深まった。コードを通じて会社を支えてきたけれど、何千人もいる部門のトップになってしまったらコードなんて書く暇ないじゃん。GFS / MapReduce / BigTable とちがって TensorFlow はオープンソースになり、専用のチップも作り、会社の総力をつっこんで開発を進めている（ように見える。）最後の戦いに相応しい舞台だとは思うけれども、勝手に悲壮感を感じてしまう。
会社のために AI 部門とインフラ部門へ袂を分けた二人が、けれど月曜は朝早くオフィスにきて、かつてのようにペアプログラミングをする。かつてにように二人で互いに LGTM し、かつてのようにコードをコミットしていく。
Jeff / Sanjay がコードを書いている限りこの会社もなんとかなる、とは別に思わない。どちらかというと、組織がどんどん大きくなり、自重で崩れかかっているこんなときでも、二人でコードを書く大切な営みを一週間のなかの少しだけは守り続けている。人として大切なことをすべて投げ捨ててはいない。そんな事実に安心する。会社はともかくあの人達は大丈夫と。億万長者相手に余計なお世話だが。
テクノロジー資本主義に荒波が打ち寄せるその朝、失望したユーザの罵声と政治家の叱責が空を埋め尽くし、デモ行進の果て暴徒と化したアクティビスト社員が放った炎に二階建ての旧本社ビルが燃え落ちるなか、オフィスの片隅で二人は、いつもようにコードを書いていた。ここが遅いな。どうしたら速くなるかね。まずはちょっとコードを整理しようか。人々が投げ棄てた暗いコードベースに、小さく静かな LGTM が灯る。
悲しい話だと思いませんか。
via MacBook Air - Apple
こういう Macbook が欲しかった！これだよこれ！というかんじですが・・・(高いのはさておき)。
しょうじき XPS13 2015 特に困ってない(Linux laptop の根本的なダメさを受け入れるなら)ので衝動買いを正当化はできないなあ。いまや家でぜんぜん PC さわってないし、3 年では償却できん。来年くらいかね。ていうか家計簿つけだすとこういうのを衝動買いできなくなるのであることよ。
しかし欲しいなー。今年でた様々なデバイスのなかでこれが一番ほしいな。なんでこんなにほしいのかと考えるに、XPS13 の前に使っていて水没のため亡くなってしまった前代の Air を気に入っていたからだろうな。Apple も most beloved mac と言ってるけれども、ほんとにそう。XPS13 は別に気に入ってはいないからねえ。自分が所有し使っている計算機が好きになれない現状は情報産業従事者としても物欲者としても若干悲しい。
どうも遅いっぽいなあ。じっさい CPU のクロックとか XPS 13 2015 と大差ない。重さも似たようなもんだし・・・。まあ XPS / Ubuntu の問題は CPU の性能ではなく細々としたできの悪さなので性能を比較しても仕方ないのだが、三年前のハードウェアを買い替えて性能に差がないというのはさすがに寂しいのではないか。
XPS13 に Windows 10 を入れれば一定程度 Linux のダメさが改善される見込みはあるが、一方でももう Windows とか使いたくないのだよ・・・適応しなおすガッツないでござるよ・・・。
Macbook Pro を買えという話なんだろうけれども、あんまし好きじゃないのだよなあ Pro. TouchBar とかここのそこからどうでもいいものに F keys を奪われてしまうのいやじゃよ。
我ながら無駄に picky で呆れる面はある。Evernote を受け入れ Macbook Pro を受け入れれば人生ラクになる(部分的に)のだろうけどなー。このガジェットについて考える時間の無駄さといったら。
via Profiling: Measurement and Analysis | Riot Games Engineering
Riot Games という会社は自分の C++ のゲームを trace する際に Chrome Tracing のフォーマットでダンプしているらしい。そうそう、こういうのいるよねーと思うのだった。
ただ続編の記事 Profiling: Real World Performance in League を読むとこの人はもっと色々使っており、たとえば GPU analyzer みたいのを使っている。そういえば Snapdragon Profiler もなんかこの手の機能があるようなないような感じだった。自分の今の仕事だと GPU がボトルネックになるのを見たことがないのであまり出番はなさそうだが、それはさておき tracing 以外のツールも色々使えるようになりたいもんだなあ。特にクライアントサイドだと画面の visual components と cost budget を対応づけるような何かは欲しい。Android にも overdraw とかあるにはある。ただもうちょっと自分のアプリに近いレイヤで工夫したいね。
あと PC games みたいのは画面もでかいしメモリもいっぱいある(開発機には)ので in-app で色々書けるけれども、スマホは画面が狭いので on device は限界があるよなあ。自分は debug 情報表示用 activity を入れとく派だけれども、その activity を表示すると本体の activity が stop してしまう欠点があり、これはアプリによっては嬉しくない。悩ましい。
$ adb shell monkey -p your.package.name -v 500
via UI/Application Exerciser Monkey | Android Developers
あなたのコード、特定の条件下 (デバイス、OS など）で起動するとすぐ落ちますよ、ということを伝えるためのコマンド。再現手順を簡潔に伝えられて良い。
そんなクラッシュコードがチェックインされるとかどうなの・・・と思うかもしれないけれど依存関係の奥の方で変更があったりするとそういうこともあるのだよ。翌朝来たら誰かががんばって bisect して直していた。おつかれさまでした・・・。
追記
とりあえず何十回か回す one-liner を書いて動かすとなかなか楽しい。まあ monkey test ってのはもともとそういうものなわけだが。monkey 実行前の条件づくりをもうちょっとがんば良いテストになりそうだな。というかテストの人たちはそうやってるのであろうな。