東西盲

http://d.hatena.ne.jp/w_o/20101206#1291566328

昔も似たようなの書いたが、こういう「どっちがどっちか一生覚えられない」リスト作ってみるべきだな。

https://twitter.com/tanakmura/status/592628867447132160

あと東と西がわからん。(左右はわかるので左右盲ではない。南北はわかる)

こういうの、ちゃんと手書きで100回書き取りみたいなことをして本当に克服できないか一回試してみたほうがいいな。

やっぱ困るのは東西かな…東西100回書き取り大会しなきゃ…



あとあんま話は関係ないし、さらに完全にうろ覚えなんだけど、大分昔にwebで見た文章に「フレミングの左手の法則は結局右か左か間違えて覚えたら意味ないので、あんまりいい覚え方ではない」みたいなのがあって、確かにそのとおりだな、と思った記憶がある。

ミラーレス一眼と一眼レフ

いまだにどっちがどっちか5秒くらい考えないと思い出せないが…

"レフ" と "レス" が似てるし、その二文字だと特に反対の意味は無いのに、実質意味が反対になってるのがややこしいんだよな。

というか、"レフ"か"ミラー"かで統一しろよと思うよな。あと"一眼"っていう文字を置く場所を統一しろよ。

  • レフレス一眼 vs レフ一眼
  • ミラーレス一眼 vs ミラーあり一眼
  • 一眼ミラーレス vs 一眼ミラー

とかそういう…

あと液晶で見るよりファインダーで見たほうが云々だから一眼レフのほうがいい理論は完全に意味不明だよな。液晶と実際の写真は同じ経路、同じCCD通してるんだから、一眼レフのファインダーより、ミラーレス一眼の液晶のほうが実際の写真に残る映像に近いでしょ。

まあ液晶表示するための画像処理が遅延出ないからファインダーのほうがいいという説明はそのとおりだと思う。

Skylake-X

これみっつともAVX512x2なんか?

Xeon は ark.inte.com にAVX512 の数書いてあるんだけど、Core X のほうは書いてないんだよな。

http://ark.intel.com/products/123613/Intel-Core-i9-7900X-X-series-Processor-13_75M-Cache-up-to-4_30-GHz

http://ark.intel.com/products/120498/Intel-Xeon-Platinum-8180M-Processor-38_5M-Cache-2_50-GHz

http://ark.intel.com/products/123551/Intel-Xeon-Silver-4112-Processor-8_25M-Cache-2_60-GHz


http://www.4gamer.net/games/382/G038222/20170711043/screenshot.html?num=007

というか18core、AVX512 x 2で、DDR4 4ch とかだときつくないか?

2GHz としたら、

2 x 18 x 8 x 2 x 2 = 1152Gflops , DDR4 2666 x4ch = 85.312 GB/s とかでしょ。B/f 比が 0.1 切ってるが。

MPIが簡単

printf できるし、メモリ保護付いてる環境下で動いてるし、core dump させれば バックトレースも取れるし。


「MPIが簡単」とか言ってしまったので、その真意についてちゃんと書いておこうと思う。


(http://d.hatena.ne.jp/w_o/20151206#1449329985 で書いた内容といくらか通じる部分がある)


まず、多くの人に同意してもらえると思うのは、「MPIには複雑な機能は無い」という点だろう。(openibのコードとか見たらクソ複雑なんだけど)


基本的には、send, recv, barrier, bcast, gather, scatter というプリミティブな処理しかない。(集合通信は処理方法に選択肢あるしプリミティブではない気もするけど…まあ…これも忘れて…)


まあ、性能まで考えれば難しい面があるのは否定しないけど、こんな単純な機能しか無いインターフェースをもって「難しい」と、言っていいのかは疑問である。インターフェースとしては、jqueryのほうがよっぽど何やってるかわからないし難しいんじゃない?


「MPIが難しい」と、言った場合、本質的には、「複雑な処理を単純な機能しかないMPIにマッピングする作業」の難しさが露出していると思う。

GPGPUとかも一緒。GPGPUが難しいか?と、聞かれたら、僕は「難しくない」と答えると思う。GPGPUで書けるプログラムの複雑さなんて、OSとライブラリが複雑に絡みあったプログラムの複雑さに比べると、ずっと少ない。

僕は、GPGPUでできることの少なさをもって、「GPGPUは簡単だ」と、言うと思う。

しかし、それは、「複雑なプログラムを単純な機能しか無いGPGPUマッピングする難しさ」を否定するものではなくて、アルゴリズムによっては、そういう作業が難しく、また場合によってはそもそも不可能な場合もあるだろう。(例えば、圧縮処理を並列化するみたいな)


同じように、アセンブリC言語どっちが難しいか、と言われたら、C言語のほうが「難しい」と俺の中では定義されている。

  • add eax, 1
  • a++;

どっちが難しいか?

アセンブリのほうは、前後の行に関係なく、「raxレジスタの値を一増やした値に32bitのマスクをかけてraxに格納」と、言える。

それに対して、a++ のほうは、「前後の行を見ないとわからん」としか言えない。


これは、ちゃんと区別しておくべきだと思う。


ちゃんと区別しないで、「MPIわからん、難しい、もっと書きやすいものをくれ」とか、言ってしまうから、なんかよくわからないMPIをラップしただけの、「使いやすい並列フレームワーク」みたいなのが無数に登場してしまう。


ちゃんと、「XXXのアルゴリズムは、プリミティブな機能しかないMPIにマップして動かして性能が出すのが大変」と、そういうふうに主張すべきだ。


あと、MPIは、printf できるし、メモリ保護付いてる環境下で動いてるし、core dump させれば バックトレースも取れるので、アクセラレータに乗せるのに比べたら簡単だと思う。

Ryzen SEGV

せっかく手元にあるし試してみた。手元だと出ない。

  • Ryzen 7 1700X
  • Arch
  • Linux 4.10 ぐらいだった、VMなしnative
  • gcc 7.1.1
  • メモリ : BLS8G4D240FSA x4 で32GB
  • マザボ : ASUS PRIME B350-PLUS
  • GPU : Radeon R7 360, ドライバはカーネルに付いてるやつ(fglrx ではない)
  • make defconfig; make clean ; make -j32 を 10回

あとその上にLXC入れてその上のubuntuでも出てない

  • xenial 16.04
  • gcc 5.4.0
  • make defconfig; make clean ; make -j32 を 10回

真面目にやるなら、問題出てる人とHDD交換、メモリ交換、マザボ交換、CPU交換とかして試すとかやってみるべきだと思う。(俺はやらないが)


一回だけWindows でOS死んだことがある。まあでもブルースクリーンの文字列見てた感じ、GPUドライバの問題みたいな感じだった気がする。問題がメモリ破壊とかキャッシュ破壊とかだったらなんとも言えないけど。

怒りのレジ袋

俺ももう色々燃え尽きたので、ものごとに怒ったりするパワーが無いのだが、もう10年ぐらい継続して抱え続けてる怒りとして、レジの袋問題があって、

http://d.hatena.ne.jp/w_o/20100912#1284295374

でも書いてるが、「当店では地球環境に配慮しています。レジ袋の不要な方はお伝え下さい。ご協力ありがとうございます」と書いてあるレジ袋を見るたびに、環境への配慮とは何か?「レジ袋が不要な場合は断わる」というアクションの中に、店舗側の地球環境へのアクションが一体何mg含まれているのか?完全に店側の努力はcompletely 0ではないか?とか考えてしまう。

完全に怒りパワーの無駄遣いだ。