ミシンって
何に使うか思い出せない。
一般家庭で刺繍とかそんなしょっちゅうやるか?
test
test
http://d.hatena.ne.jp/hatenadiary/20170605/1496643809
これ見てもうダイアリー側はレガシー対応になってしまってる気がして申し訳ない気がしているので移行したほうがいいかもしれない。
でもスタイルとか作り直す気力がない…
東京オリンピックの良かった探し
「ソフトウェア開発は属人性が高くエンジニアリングとして失敗云々」とか言われた時に、「お、東京オリンピックのスケジュールは順調ですかな?」とか煽れるようになったので良かった。
東西盲
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/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 させれば バックトレースも取れるので、アクセラレータに乗せるのに比べたら簡単だと思う。