はじめてのにき

_ 経県値

なんか前やったんだかやってないんだかわからんけど、記録残ってなかったので

http://uub.jp/kkn/km.cgi?MAP=44340444443354404144034344543000444040043000000&NAM=%82%CD%82%DC%82%B6&CAT=%90%B6%8AU%8Co%8C%A7%92l

行ったことあっても記憶が無いとこはのぞいた

(18:16)

_ 読んだ本

• 論考: ウィトゲンシュタイン。だいたい読んだ。哲学をずいぶん狭い世界に勝手に限定して、「これで哲学完成！もう哲学者のやることは無いっ」てのはちょっとひどいんじゃないかとか思った。哲学屋の友人に聞いてみたところそういう面もあるかもね次のやつ読んだらということだった。でもこういうのも一冊読むのは結構だるいな。
• 心にナイフをしのばせて: 少年犯罪の被害者側の家族が悲惨な生活、加害者本人は弁護士になって順風満帆な人生、ていうやつ。少年法とか被害者加害者人権てやつは難しいなあと思う。基本的には加害者には死を！みたいなのには賛成できないけど、これ読むと被害者悲惨すぎやろ感強いので一定の保証があっていい気がする。気休めみたいなもんかもだけど
• 僕はやってない: 筋弛緩剤点滴事件の容疑者が冤罪と主張するというやつ。今は無期懲役確定で再審請求してる感じぽい。これ読むと、あっこの人本当に冤罪だなって思う
• 真実のカルテ: 筋弛緩剤点滴事件を警察に届けた病院の人たちの主張。これ読むと、あっあの人やっぱり犯人だったんだって思う。ありえそうな正解のパターンは 1. 実際殺してた 2. 冤罪でかつこの病院が医療事故をゴマかすための陰謀 3. 冤罪だが病院側は本当に殺人だと信じている、の3つか。3つ目がクズ人間がいないという意味では良いのだけど、筋弛緩剤無くなったのとかヘンすぎるので、1か2が現実的なんだろうな。真実のカルテの方、警察が逮捕した時点で「やはり事実であったか」と思った、とか書いてあるんだけど、これ人狼的には黒要素とか思いながら読んでた。僕はやってない側は黒要素無いかなと思うけど、すごい嘘つきてのはいるもんだから1もありえるとも
• 東大駒場寮物語: なんかうまいことまとめてるなと。身贔屓かもしれないけど。時代的には昔が半分、著者がいた時代が半分て感じでなんかちょうどいい。しかしものすごい量記録あったのによく読んだな

マンガは特に面白いこともなく

School rumble こんな終わり方してたんだ、と思った。あとは変ゼミが終わりました

(23:44)

_ ハーモニー

も読んだんだった。ついでに映画も。

映画のオチは「あーなるほどこういう意味だったんだ」と思ったけど、まあ普通に映画で勝手に解釈したぽい。映画の方がわかりやすくていいんじゃね、原作者墓下で文句言ってそうだけど。

内容はまあ、意外とストレートにわかりやすい、みんな良い人になりすぎた理想郷は人間くささが消えてつまらんよ系の。類似ストーリーとしては斑鳩を最初に思い出す。それはいいし、素直に先が気になったんだけど、なんか途中の展開が全体的にこうちょと違和感ある感もあった。もやっと

(01:38)

_ メガネ

右 S-8.00 左 S-7.50 C+0.50 S-7.00 C-0.50*

と書いてある。意味は調べてない

(23:29)

_ リセットボタン

http://mubou.seesaa.net/article/432460939.html

まあ UI が進化したのと起動が遅くなったのとで、ゲームの再起動はゲーム内でやるようになったというのがあり。

てか PS1 PS2 てハードウェアリセットボタンついてた？？とか思って、画像検索したらついてた。すごい押した記憶ない

PS1 の絵描けて言われればこういうの描く。で、これリセットボタン忘れてるんだけど、全く違和感無いしリセットボタン描いたら逆に違和感ある気がする。使わないものって記憶に残らないんだなあ

(12:23)

_ 速度

https://twitter.com/kmizu/status/687232554001235969

ポジショントークです

色んな速度があるからなあという話。大雑把に言って

• 1. スループットが重要なもの
• 2. レイテンシが重要なもの
• 3. 書いてる時の速度が重要なもの(ちょっとした問題の修正も含む、いわゆるイテレーション速度)
• 4. 問題を解決する速度が重要なもの(運用してる間に起きた問題の修正、しょうもない typo とかは含まない…とする)

なんてのがあると思う。 3 と 4 は規模によって結構変わる数字。えんどうさんは Ruby は 3 (や 4)が重要な言語だという観点で、 1, 2 のためにそっちを犠牲にしないで欲しい、的なスタンスなんだと思う。僕も賛成する…が rails の人たちなんかは少し違うバランス感覚を持つだろう

1 が効いてくるなら C/C++ と JVM 以外に解が無いことが多いと思う。それとスクリプト言語で書いてもたいして楽にならないケースが多いように思う。というわけで、 1 は Ruby でやろうとしないのが懸命だと思うけど、まあ言語のベンチマークはおおむねこれを測ってるケースが多い…と思う。とはいえ実行頻度が少なければ、 C/C++ なら1時間ですむけど、 Ruby なら5時間…みたいなタスクでプロジェクトによって Ruby を採用するのもわからんでもない…が個人的には基本イヤだ。

2 はこう、 1 よりは制限が弱くて、 UX 的に問題になるまではどの言語でもいいところではある。 Python Ruby で書いてる大規模なフロントエンドなんて、まあいくらでもあるだろう…とは思う。がなあ、 1, 2 が気になりうるならそもそも Ruby 使うな感はある(このへんポジショントーク)。レイテンシは問題が起きるたびに修正しなきゃなんで、最初から速いので書いときゃ問題が起きる頻度が減るんで。

3 はおおむねスクリプト言語が速い…が今は知らんが昔の rakudo で見てる限り Perl6 の 3 は速くない。 4 は printf で解決するような問題だと 3 の速さが重要になるけど、ややこしいデバッグとかするなら JVM とかが良くなる…と思う。個人的な感覚では JVM は速度に関する問題が起きた時、 4 の解決は C/C++ がツールの充実と GC の不在により、最速になりうる…と思う(このへんもポジショントーク)。

4 はこう、割と 1,2 の速度と 3 の速度が混じる領分で、複雑になればなるほど 1,2 の速度が問題の解決にかかる速度に依存しがちで、簡単なものだと 3 の速度てかイテレーション速度に依存しがち…な気がする。ただそれ以上にツールの充実とかが重要になってきて、言語機能そのものとかより、エコシステムが影響してくる分野だと思う。

1 考える時は C/C++ で良くて、 2 は C/C++ かひょっとしたら JVM とか GC つきの言語もアリで、 3 はスクリプト言語、みたいな使いわけになってる気がする。 4 は色々あるけど、結局エコシステム的に、慣れたせいもあるけど、 C/C++ (+gdb +valgrind +etc.) が素晴らしいんだよな。

でー…僕は 1 と 4 最重視でサクッと書く時は 3 重視、みたいな感覚で、それでなんか C/C++ か Ruby (か会社で書く時はいやだなあと思いつつ Python) しか使わなくなってしまっている。のでえんどうさんの言う https://twitter.com/mametter/status/687227476548833280 は強く賛同するんだけど

2 ぽいことする時は隙があれば Go とか JVM 系言語使ってもいいと思うんだけど、最近そういうのやってないんだよな。あと Go はともかく JVM 系はイテレーション時間かかりがちだよな色々(古い記憶に基くポジション)

で Rails の人てのは 2 なんだろうな

なんていうかスクリプト言語の人とか最新言語好きな人は 3 によりすぎてると思うんだよな基本的に。まあイテレーション速度は重要ですがね。 C/C++ でもコンパイル結果わかるまでは 1 秒あれば普通のプロジェクトなら可能だしな(Chromiumは普通Androidは異常という世界観)。書く速度の方はなあ。1ヶ月くらい1万行越えるコードベースいじってると、アセンブリとかでなければ生産性たいして変わんなくなる気がしてるんだよな。脳の速度が律速する

(22:13)

_ sevilwm に15年くらいあったバグ

gimp みたいな GUI アプリで、 window が消えて再び現われた時に、縁の四角しか出てこねえ、てことがあった。

Quartus でこれ不便なんで、うーんと眺めてみると、あっさりなおった。

Index: screen.c
===================================================================
--- screen.c    (revision 8338)
+++ screen.c    (working copy)
@@ -324,6 +324,7 @@

 void unhide(Client *c, int raise) {
     raise ? XMapRaised(dpy, c->parent) : XMapWindow(dpy, c->parent);
+    XMapWindow(dpy, c->window);
     set_wm_state(c, NormalState);
 }

要は window が消えて現れてるんじゃなくて、隠してまた出現させてるアプリで起きるてことで、出現させる時に縁だけじゃなくて中身も map しないといけないぽい

(00:09)

_ またたらいを回す

http://shinh.skr.jp/m/?date=20151221#p04 の続き

内蔵 RAM の読み書き、ムダに FF がはさまってる部分を撤去して速くなった。あとよく見ると RAM の入力自体に FF が挟まってやがるので、 RAM 用のクロックを本体より速くしてやったら、命令フェッチの次のサイクルで命令実行できるようになった。

ただ、本体が 50MHz RAM が 100MHz だと間に合ってないぽくて挙動がおかしい、し、 TimeQuest さんもダメぽて言ってる。そもそもクロック速度変えるんじゃなくて、クロックずらしてやるとかが良かったりするんだろうか。。

で、 tarai(12, 6, 0) が 25MHz で 27.87 秒。

(04:19)

_ いんたびゅー

面接じゃない方の。

https://codeiq.jp/magazine/2016/01/35490/

ありゃこれで終わっちゃったんだて感じ。なんだか別に面白くないなって。誰が悪いというわけではないんだけど。思うに素敵な聞き手がいると面白いんだろうな。たぶんこれは聞きてていうか参加してる人が全員強すぎる。

初期のるびまのインタビュー、すごく面白くて好きだったんだけど、あれはたぶん毎度聞き手として混じってた arton さんがすごかったんだろうな。話し手の昔話、しょうもない話をきちんと拾って広げてる感があった。こっちは単にそれぞれの話し手が自分の思う方向性の面白い話してる感じというか。

CodeIQ のこの聞き手がダメとかではなくて、喋ってる3人が偉すぎるから話題提供に徹しちゃってる感じなんだろうけど。

単に arton さんまた聞き手で参加して下さいってだけの話な気がする

(22:16)

_ たらい進捗

フェッチと実行を同時にやるようになって、 25MHz で 15.26秒。 50MHz 時代より速くなった。 50MHz か、パイプライン入れてもっと速く実行できるようにするか、あるいはスーパースカラとかできると良いんだろう

(22:27)

_ PPCの命令エンコーディング

たいていの命令は dest, src1, src2 と並んでるわけだけど、一部の命令、というか論理演算は src1, dest, src2 と並ぶ。これヘンだなむかつくなって思ってたんだけど、きっと設計時のスーパースカラから来てるんだな。

たぶん計算の命令と load or store or 論理演算が同時に実行できるようになってて、 load/store アドレスのレジスタて書き変わるかもしれないので(要は push/pop だ)、ぱっと見不自然に見えるけど、真ん中が dest になるんだなあ。

(21:47)

_ それはそれとしてたらい

50MHz で全命令動くぽい感じになったので 7.63秒。

パイプライン作らないとこれ以上は速くならないだろうから、作る

(21:49)

_ 京大のCPU演習

http://www.lab3.kuis.kyoto-u.ac.jp/~ktakagi/le3a/

を教えてもらった。これは FPGA がだいたい同じスペックなのと

http://www.lab3.kuis.kyoto-u.ac.jp/~ktakagi/le3a/contest/index.html

このコンテストが東大と違って浮動小数の実装がいらないので、目標としてはとても良い気がした。

とりあえず実機で測ってみると、 9.98ms ということで 28 倍遅い。シミュレータによるとサイクル数はだいたい 300k で 6ms ほどで終わって欲しいところなんだけど、たぶん RS232C で測定終了マーカ送ってる部分で遅れが出てるか。

それ以外にもいろいろ違いがあって、まず記録の数字はサイクル数少なすぎる。僕が libc の qsort 使ってるせいでムダなオーバヘッドあるのかなーと思うので、とりあえずそれは直そう。

あと京大のやつは 16bit より広いバス使っちゃダメ、て言ってるのに僕のは使ってる。まあこれは C 言語側で 32bit int 使って計算するようにしてるから、基本的には僕に不利に働くか同条件と言えるんじゃないかな…

(22:19)

_ nop がバグっておった

nop で R0 が書き変わっててわらた

(22:44)

_ CPU TODO

• ベンチマーク用のプログラム、テスト用と本番用両方作るようにする
• mftb と mftbu を実装して使う
• sdc を勉強する

このへんちゃんとやってからパイプラインに進んだ方がよさげ。

(22:56)

_ mftb と mftbu

実装した。で測ってみると 140816 サイクルで、 50MHz なのでたぶん 2.81632ms 。シリアルのオーバヘッド 5,6ms くらいだと思ってたけどそれよりデカいななんか。。まあ命令数はコンテストサイトと比較すると妥当な感じなので、まあそんなもんな気がする。

2サイクルかかる命令があるので、GDBのシミュレータだと 121322 サイクルで、 2.426ms の計算。

そういえば授業でやってる人達に比べてずるい点として、コンパイラ自分で作ってなくて clang が最適化してるので、サイクル数少なめってのがある。ソートも glibc のやつ使ってるだけだし。

(01:42)

_ sdc

sdc を用意したことにより、自動で行なわれていたらしいクロック検知が行なわれなくなり、正しく動作しなくなった

(12:16)

_ ラクに速くしたい

アンドロ、完全にビルドするもの無い時に make て叩くとむっちゃ速い時で 6 秒くらいかかる。普通は 8 秒とかそのくらい。 kati 以前は 2 分だったので、まあいいちゃいいんだけど、やっぱり 8 秒はちょっとイラっとくる…気がする。

2分から10秒にするならすごく頑張る価値があるけど、 8 秒のものを速くするならちょっとした努力ですむと嬉しい。

むっちゃ速い時の 6 秒、内訳を見ると大雑把に言って、 4.5 秒が ninja で 1.5 秒が kati の責任。

ということでとりあえず ninja でしょ、ということで書いた ninja のパース結果をバイナリとして保存するパッチ。入ってくれると 3.5 秒かかっているパース部分 1 秒になるので、合計で 4.5 秒だったのが 2 秒くらいになる。もうちょっと速くすることもできる(が相対的な嬉しさはたいして無い)。

https://github.com/shinh/ninja/commit/1ac857f8ca7ce5dcc8999b9b6d270bbae6074af4

これを入れてもらえると ninja 2秒 kati 1.5 秒となって、 kati 側の方が気になる。こっちは thread で並列で処理すると速くなるに決まってる処理なので、やってみたら 0.4 秒ほどになった。

https://github.com/google/kati/commit/6bbf9e29fcb069871a9153e845242ed6fe0e1b94

2つひっくるめると 6 秒が 2.5 秒ほど、まあそりゃ、もちょっと速い方がいいけど、費用対効果としてはこんなもんかなって感じ。

C++11 の lambda+thread で thread pool 書いてみたりした。書きやすい感ある…がまあ pthread は基本的な API はだいたい使い方覚えてるので、ぶっちゃけこっち書く方が時間かかるというのはある

https://github.com/google/kati/blob/6bbf9e29fcb069871a9153e845242ed6fe0e1b94/thread.cc

thread_local キーワードて Mac だとサポートされてないのかー、と今気付いた。修正しないとか。まあだいぶ前に書いたこれ使えばすぐできるだろ

https://chromium.googlesource.com/arc/arc/+/master/src/common/thread_local.h

さて

Makefile が書き変わったりして kati がこれは処理しなおさなあかんなーと気付いた場合、 Makefile をパースして評価しなおすんだけど、こっちはもっと時間がかかる。大雑把に言って

• パースと評価: 23 秒
• 依存グラフを作る: 8 秒
• ninja を出力する: 13 秒

てとこ。最初の部分、これは一番気合が入ってる場所なので、まあそれなりに速いと思う。 GNU make が2分かけてる部分だし。

残りは割と適当なんだよな。こっちはまあ、 23 秒の部分は速くするの難しいと思ってて、残りの 21 秒頑張ってもたいした効果ではないので、ラクに速くできる部分があればやる…くらいかなと思う。

まあ普通に考えてスレッドで散らせ、ってことになると思う…がまあ、これはめんどくさい部分も多い。コードが汚なすぎるんだよな。あと順番が重要な処理もある。

グラフ構造みたいなのをトラバースするのを並列にやる必要がある。一つ一つのノードを処理するのはすごく速いけどノード数が多いので、新しいノードを見つけるたびにタスクキューに入れる、みたいなことすると待ち合わせの時間ばかりかかることになると思う。

たぶん分岐があったら、一定の確率で分岐先をタスクとして実行させる、とかでいいんだと思う。って parallel GC てそんな感じなんだっけ?

(20:28)

_ code of conduct

なんじゃこれ

https://bugs.ruby-lang.org/issues/12004

全体的に良い自転車小屋だなーと思いながら流し読みしてたら、極右によるなりすましまで現われてすごい

(06:42)

_ 陰謀論

で、その極右は実は当初のやつを採用させたい派による、なりすましのなりすましであり、ほら code of conduct committee 必要でしょー、と実演してるという陰謀論

(06:46)

_ 今年度

この冬今まで暖房使ってなかったことに気付いた。あったかい冬だなあと思ってたがまあもう限界だ

(07:02)

_ SIGABRT - bt - No stack.

今日もらったバグレポをエアデバッグしてて、あーこういうことだなってアタリがついた事例

(gdb) p main
$1 = {int ()} 0x400596 <main>

つまりシンボルのある綺麗なバイナリです

(gdb) r
Starting program: /ssd/test/a.out

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) bt
No stack.

abort してるのに "The program no longer exists." ヘンすぎるやろ。というわけで以下のコードがこういう挙動を起こすことに気付いた。なるほどねー

$ cat vfork_fail.c
#include <stdlib.h>
#include <unistd.h>
int main() {
  if (vfork())
    sleep(1);
  else
    abort();
}

(20:33)

_ CoC

あっ終わってしまいそうだ。なんかあのスレ流し見するのが日課になってた。

こいうのでいうと、在特会 vs しばき隊とかも似た構図かなあと思っていて、被害を被るのは、「うーん、どっちも、えー…」と思ってる人達ってのが。そいう人ってどっちかよりの意見を持ってたりもすることもあるのに、先鋭化した人達は俺より敵側にいるやつは全部敵、てなっちゃうんだよなあ

ちょっとずれて、なんとなく手塚治虫のマンガとかに出てきた、百姓が「おさむらいさんがいつも戦争してるけど損するのは百姓ばっかだべ……」とかぼやいてるシーンを思い出すのだけど、大きな違いは百姓がバカじゃないってことがあると思う。がまあ見るからに matz 以上に喋った人は被害は被ってるんだよなー

(22:42)

_ GoF

http://qiita.com/irxground/items/d1f9cc447bafa8db2388

おおこれすばらしいな

(23:18)

_ FFRK

新システムのスフィアてやつ、何がどのくらい必要なのかよくわからんので適当にスクリプト書いてみた。

http://shinh.skr.jp/ffrk/dive.html

(02:07)