はじめてのにき

_ HPCぽい話と並列性の分類と

https://tl.hateblo.jp/entry/2021/04/30/154411

HPC ぽい話も(にわかほど語りたがるというし)ちょっと書いてみたかったけど、発散しそうだったから、やめたのだった

HPC、とりあえず、スケールしない部分が足をひっぱらない程度にはバカパラに近くなってないと、なんともならないというのがあると思う。そこはなんか問題いじったりしてでもバカパラにするし、できないならスパコン使う必要とか無い、ということになるんだと思う

次は DRAM からの移動なりインターコネクトなりのバンド幅足りないとお話にならないので、計算戦略やデータの持ち方とかでなんとかして、そこまで行くとSIMD、パイプライン、スーパースカラ的なのをやっていく、みたいな印象を持っている。なんというか、クラウドとかのバカパラマルチスレッド的なのと、いわゆるアセンブリでチューニング的なやつの両方必要な感じだなあ、と

その二つに加えて、ヘテロなスレッドが協調動作してる系のやつ、くらいで雑に並列性ぽいものは分類できるのかな、と思った。つまり

• 1. マルチスレッドパイプライン並列
• 2. マルチスレッドバカパラ並列
• 3. SIMD/パイプライン/スーパースカラなどの計算ユニット内並列

くらいに分類できると考える

1 は DRAM や IO 待ちで律速しがちで、用途的にもレイテンシ重視が多め。 DRAM や IO 待つとこまでいければ良いので、 2,3 をやってもしょうがないみたいなケースも多いが 2 も併用したりもよくする。 1+2 がタスクキュー。「並列プログラミングは難しい」と言う時に思い浮かべるのは、僕はコレ

2 は message passing に主題として書いたやつ。高速化的には最も簡単でバグらなくて素晴らしい

3 は message passing 書いてる最中に書こうかなあ、と思ったけどやめたやつ。普通あまり並列プログラミングと言わない気もするんだけど、並列計算ではある。コアの性能をしぼり出すというソフトウェアの観点からも、電力や回路面積などのリソースをどこに割り当てるかというハードウェアからの観点からも、関連した話題ではあると思う。そのへんで言うと A14 のスーパースカラすごい広いのとかも、これバランス悪い気がするんだけどどうなんだろう……とか思うけどどうなんだろう: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2

スマホや chrome はおおむね 1 、 jpeg のデコードは 3 (2も使ったりする？)、 HPC は(たぶんおおむね) 2 と 3 、クラウドは 1 and/or 2 、 GEMM は 2 と 3 。ディープラーニングだと GEMM に加えてデータローダとかはちょっと 1 ぽさあるので、割と全部あるかもしれない。あと inter-op のモデルパラレルは 1 ぽさがある

あと、 1 と特に 2 はノードまたぐか否かとかで割と雰囲気が変わるとかあるかもしれない

(10:39)

_ DFT

密度汎関数理論て、「なんかそういう理論に基いて第一原理計算ができたらしい」くらいのなにかだったけど、かなりとんでもない発見なのかなこれ。多体問題を一体問題で書けると言っている……

(12:21)

_ DEFCON CTF Qual やった問題

exploit-for-dummies

最初になんかクイズが出てるらしい。チームの人が解いていた

本質は自由な trivia.debug ファイル読ませられる状況で、 gdb -c core trivia した後の x/s <user-input> ができるので、いい感じの <user-input> を与えろ、というやつ

とはいえ gdb の expression が ()[]{},; あたり禁止されていていかにも厳しく、 shellcoding という名前からして、たぶん DWARF でいい感じのを作れということだろう、と

チームの人がレジスタからフラグの位置を計算する式は考えていてくれたので、テキトーに DW_OP_xxx で書いた。それは一瞬で終わったのだけど、サイズ制限があるということで、めんどくさかった。というのは gcc でテキトーに作ったバイナリをいじって作っていたので、セグメントの位置を大きくずらすとかあまりやりたくなかったので……

これまたチームの人が短いバイナリを作るレシピを共有してくれてたのだけど、なんか手元ではリンカが違うのか、うまいこといかなかった。まああとちょっと削れば……という感じだったので、コンパイラオプションやリンカをあれこれ調節してなんかおさまった

gcc -gno-record-gcc-switches -Wl,--no-eh-frame-hdr -static -g -Wl,-T,minimal.lds

と

objcopy -I elf64-x86-64 -O elf64-x86-64 -j '.debug_info' -j '.debug_abbrev' -j '.debug_str'

https://gist.github.com/shinh/1a7c185ea0478f7b14f2ec905b59d1b1

back-to-qoo

オフィシャル解説が出てるぽい

https://github.com/o-o-overflow/dc2021q-back-to-qoo-public

なんか協力者が意思決定した後に qubit を回転させてるのに、これでいいのがよくわからん……

https://gist.github.com/shinh/242786e2f6a38f9f50803e64a1882715

(13:48)

_ GAN で暗号

https://arxiv.org/abs/1610.06918

CTF に出てて知った。発想は面白いと思った。原文と鍵を受けて、 alice が encode して bob が decode して、元のに帰ってれば OK 的にトレーニングするんだけど、これだと鍵使ってくれないので、鍵を受け取らない(代わりにちょっとレイヤ数とかトレーニングの頻度を上げてある) eve が bob と同じタスクをすることによって、 alice と bob は鍵をそれなりにいい感じに使ってくれる、というもの

明らかに通常の暗号と違って、暗号として機能するっていう理論的な保証がなくて、言えることは eve より強いってことだけ。実際レビューを見ると

https://openreview.net/forum?id=S1HEBe_Jl

it is strictly worse than any provable cryptography system.

と言われてる。

CTF で出たのは、このスキームで暗号化された平文の大部分と、暗号文が与えられるので、平文の残りの部分を解読せよ、という問題。トレーニングされたモデルと鍵は一切与えられない

この条件で解けるってことはガバガバってことだと思うんだけど……僕は解けなかった。 linear regression 一発で解けるって discord で言ってた人がいたんだけど、それはやってみたけど解けなかったんだよなあ。というか鍵ないんだし線型回帰だけじゃ厳しくない？という感想しかないんだよな

あー書いてて気付いたけど、同じブロックに対して鍵使い回して次の鍵をエンコードしてるから、そこ一つならいけるとかいう話かな。やってみよう

(17:01)

_ icebp

x86 の隠し命令

http://www.rcollins.org/secrets/opcodes/ICEBP.html

http://www.os2museum.com/wp/icebp-finally-documented/

ほえーこんなのあるんだなあ

(13:27)

_ Ubuntu 20.04

そういえばアップデートしたけど、何も悪いことが起きてない

GDM の設定が変わって sevilwm の起動のしかたなんか変えるくらいはいつもあるんだけど、それすらなかった

あーなんか skk が動かなかったけどそれは ddskk 入れればなおった

(21:43)

_ バラモン左翼

https://courrier.jp/news/archives/243521/

https://shuchi.php.co.jp/voice/detail/6826

なるほどなあ、と。日本にはあまり当てはまらなさそうな感じではある。

(15:25)

_ うぶんつ

そういえば 20.04 にしてなかった。してもいい気がするけど、問題あるとするとなんだっけな……

• python3.5 が欲しい
• cuda 大丈夫？

くらいかなあ。

(18:32)

_ matlab で木

https://blogs.mathworks.com/pick/2014/12/12/obfuscated-matlab-code/

ビジュアライズする系だとこういうのできるの楽しいな

(14:26)

_ 進撃の巨人

いやすごい面白かった。流行りものかつ長いもの、斜に構えてしまうものがあるのだけど、とても良かった。最初の10巻くらいはちょっと疲れる感じだったけど

流行り&長いで言うと、鬼滅はまあいいかという感じだったけど、呪術もなかなか良いなあという感じ

(20:07)

_ じゃりんこゲリオン

https://twitter.com/chiku012/status/1379029832613289986

おもしろすぎた

(10:28)

_ 面接

は割と好きな雑談トピックの一つなんだよなぁ。グーグルとかでも、大雑把なとこでは合意がある程度あるけど、細かく聞くと微妙に違ったり、なるほどその視点は良いな、みたいなのも多いし

https://twitter.com/shinh/status/1378585722404229122

の続きなんだけど、解けた解けないを重視しすぎたせいで明らかに不適切な評価をつけてしまったと感じて反省しているケースが一つある。直感ではこの人は強い、と思っていたし、興味深い視点を次々と出していたのだけど、なんかしら僕が想定している模範解答には直接辿りつきはしなかった。今思い出せば絶対に良い評価をつけてるのだけど、なんか当時は「ウーンやっぱこれ解けてないし、前の解けたけど微妙ぽい感じの人が落ちたことを考えると……？」と思って、悪い評価をつけてしまった。当時、 accept/reject をハッキリ書きなさい、と教育されていたことも、悪い方に働いたと思う。幸い、たぶん僕が calibrate されてない面接官で信用されていなかったこともあるのか、他の人が良い評価をしてくれたおかげで、その人は accept となったし、実際入ってからも活躍しているという認識。でもアレは本当に良くなかったなあ、と思っていて、面接になるべくなら関わりたくないと思い続けている。人の人生を左右するのはこわい

これ以外のケースではうまく面接できてるかというと、別にそんなことはなくて、ほぼ全ての面接の後で、「あの時これを聞いておけば、この人のいいところをもっと引き出せたかもなあ」などと思わないことはほぼ無いような気がする。あとどうしても労働の質にムラがある人間なせいで、面接の質にもムラがあって、調子悪い時に当たった人は申し訳ないなあ……というのもよく思う

「いいところを引き出せた」と書いて思い出したのだけど、アラ探しをするよりは、いいところをたくさん探して、その量が合格量に達したか、で判断するのが良いと思っている。人間の長所というのは本当に色々あって、同じ問題を出しても、分析力が良い、逆質問の仕方が良い、単にコード書くのが速い、コーナーケースの作りかたが良い、色んなパターンのグッドシグナルがある。アラ探しをしていると、どれか一つだけの尺度だけの判断になりがちで、その典型的な例が僕のやらかした「正解してないから不合格」だった、と思っている

「自分が答えを知っている必要もない」とツイッターに書いて、実際面接のちょっと前に自分が「ウーンどうしようかな？」と考えてたようなことを聞いてみたりとかもする。これはちょっと注意が必要で、「相手が自分より大幅に賢い場合に相手に教えてもらうことになるので、その相手の説明を自分が理解できるくらいの考察は自分に必要」というのがある。このへんに open-ended な質問の面白さがある気がするけど、僕はこわいので、自分が平均的な人よりかなり詳しい程度自信があることについてだけ、この手の問題を出すようにしている気がする

なんか色んなこと考えたり書いたりしたけど、元の nuc さんの「お茶をする」「よい面接は漫才のように進む」あたりの表現は本当に簡潔かつ適切な表現で、面接とか問題を出している、というよりは、未来の同僚との雑談、みたいな意識があるよねえ、と。ただ「お茶をする」の方はあの文章の他の部分と同様、賢い人サロン的な気持ち悪さも感じてしまうけど

(20:06)