トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|

ToDo:


2018-11-03

_ binary hacks によせて

https://twitter.com/okapies/status/1058272355984728064

当時、「こういう基礎的な話は息が長いですよ」的なことを出版社の方と、あとたぶん主著の人とかあたりが言ってた気がする。当時は「そんなもんかね、まあ僕が書いたようなことはマジで一発ネタみたいな話ばかりだし、というか金に困ってるでいうと今だし、どうでもいいか、いや長期に渡って印税が来るならそれは嬉しい」と思っていた気がする。今でも参照されうる本ということらしくて、当時の出版社の人達の分析は正しかったみたいで、すごいなあ、と思うのと、そんな中長持ちしない一発ネタばっか書いてすいませんでした、という気持ちになる

しかしまあ、普通に考えて、僕以外の人が書いた binary hacks の部分も、だんだんと古くなっていったりもするわけで。いや僕もバイナリぽいやつだと定番の linkers & loaders 読んでフムフムだったクチで、あれのせいで OMF とか未だになんとなく覚えてる感じで。まあなんだろ、「歴史から学びました。 CGI というのはこういう仕組みで動いてたらしいですが、今は…」的な話なんだよな。いやこの喩えも通じないのだろうが……

まあ僕が言いたいこととしては、んな古いものを見てる暇があればこれを読めということで

https://tanakamura.github.io/pllp/docs/

個人的にはこの調子で今ヘッダだけあるような章が全て書かれるのであれば、これは数十年オーダーで生きうるすごい物を書いておられるなあと思っている。いやまあ、長年のなかむらさんの文体ファンとしてはこの文体の文章見られるだけで、あとはどうでもいいレベルなんだけど。例えば、リンカについての文章でこれほど安心感があったことはあまり無いんだよなあ

https://tanakamura.github.io/pllp/docs/linker.html

それはそれとして、ファンといえば、 binary hacks に戻って、正直本自体の内容は今となってはどうでも良いのだけど、 shiro さんが書いて下さった、「本書に寄せて」だけは何度読んでも名文で。

http://0xcc.net/binhacks/sample.pdf

この「表向きの話」の後の文章、これがもう何度読んでも感動的で、今でも自分の行動指針になってるレベルのなんかな気がする。実際実現できてるかはあやしいが。。

(03:42)

_ この前書き

もう本当に好きすぎて何度も読んだのだけど、

本書はその絶好のガイドブックになるだろう

だけは、宣伝していただいてありがたいところなのだろうけど、なんかいらない文章だなと感じるのだった

たぶん shiro さんが最近生まれて幼少期にこの本を見たとして、ガイドブックとか別にこの人いらいないでしょ、という感覚かな

(04:01)

_ あと

ニューラルハックスみたいなのは普通に欲しいな

(04:03)


2018-11-06

_ resnet50 10 msec

https://dawn.cs.stanford.edu/benchmark/

たぶん、それほどでもない記録な気がするけど

(23:00)

_ きょうの kati

https://github.com/google/kati/pull/159

なんかヘンなパッチ来てるな、 cisco て書いてあるけど…と思ってたら本当に cisco だったらしい

ヘンというのは、ありていに言ってこれたぶんできがあまり良くない

(23:13)


2018-11-10

_ nvidia, f*** you

自業自得感しかないが、 cuda 10 入れようとして、ハマった

まず、 Ubuntu 向けのパッケージは、うまく入らない

次に、 Debian 公式のパッケージは、欲しいものではない

よって、 .run ファイルを拾ってきてインストールするのが良さそう

アンインストールは

sudo /usr/local/cuda-9.0/bin/uninstall_cuda_9.0.pl

とかするのが良さそう

うっかり debian の何かを入れてしまった場合、何を消せば良いのかわからなくなる。どうも /usr/lib/nvidia/alternate-install-present というファイルがあると、 .run ファイルが動きたがらないので、これを消す必要があって、

apt-get remove nvidia-installer-cleanup

で消しされる。

sudo service lightdm stop

で X を止めた状態で作業すると良い模様

(01:00)


2018-11-11

_ Death of Optimizing Compiler

https://tabesugi.net/memo/2017/8.html

を見て、これ2017年8月の段階かあ、この段階でもまだ、たぶんその通りだなあと思っていた。本当に性能を気にする「ホットスポット」は、 nvidia や intel が、手動や、半手動というか専用ツールみたいなのでカリカリにチューンしてくれて、それで良い気がしていたと思う

今はこう、その「ホットスポット」というのがどんどん広がっていて、 Conv+Relu 速くしたカーネルです!とか LSTM 速くしたカーネルです!ての出してもらっても、 activation 変えたいよう、とか、 attention 入れたい、あるいは変えたいよう、とか言って、ホットスポットは少数の人におまかせー、というわけにもいかんのとちゃうか、という雰囲気になってる気がする

これについて、「djbも読み違えるるもんなんだなー」という印象で思ってたけど、今見ると domain specific tools みたいなのに言及していて、これがどういうものを想定していたかによっては、逆にちゃんと見通していたということかもしれない。というかむしろ現在の状況を語っていたという話な気もする

ところで関係ないけど、なんというか、逆にホットスポットで過剰に速くなってるせいで、研究者の思考が狭まってる気もするんだよな。 GEMM が速すぎて GEMM 使わないという選択肢が無いとか。

(14:00)

_ テュポーン

火力が足りないから確率2回発動に頼らざるを得なくて、2回発動のせいで序盤ダメージ当てすぎで安定しない。第一フェーズはとにかくダメージを入れてはならないので、チェーン待って撃つとかは逆効果、星6も使ってはならない

ややマシな手順

  • ウララ: マンダ→ファブラヒール、あとはマンダとアレグロと絶を適当に。2手目のファブラヒールは、第二フェーズへの以降タイミングが不定すぎて回復入れられる保証が無いので、ここで入れとくといいぽい
  • セラ: チェーン、あとはブリザガとチェーンもう一回、それだけ
  • たまねぎ: 絶、ブリザガ*3、たくす、あと撃てればブリザガ(撃てない)
  • トットとビビ: 星5*4、絶、星6

(14:07)


2018-11-13

_ 引数多すぎコンテスト

cudnnStatus_t cudnnRNNBackwardDataEx(
    cudnnHandle_t                     handle,
    const cudnnRNNDescriptor_t        rnnDesc,
    const cudnnRNNDataDescriptor_t    yDesc,
    const void                        *y,
    const cudnnRNNDataDescriptor_t    dyDesc,
    const void                        *dy,
    const cudnnRNNDataDescriptor_t    dcDesc,
    const void                        *dcAttn,
    const cudnnTensorDescriptor_t     dhyDesc,
    const void                        *dhy,
    const cudnnTensorDescriptor_t     dcyDesc,
    const void                        *dcy,
    const cudnnFilterDescriptor_t     wDesc,
    const void                        *w,
    const cudnnTensorDescriptor_t     hxDesc,
    const void                        *hx,
    const cudnnTensorDescriptor_t     cxDesc,
    const void                        *cx,
    const cudnnRNNDataDescriptor_t    dxDesc,
    void                              *dx,
    const cudnnTensorDescriptor_t     dhxDesc,
    void                              *dhx,
    const cudnnTensorDescriptor_t     dcxDesc,
    void                              *dcx,
    const cudnnRNNDataDescriptor_t    dkDesc,
    void                              *dkeys,
    void                              *workSpace,
    size_t                            workSpaceSizeInBytes,
    void                              *reserveSpace,
    size_t                            reserveSpaceSizeInBytes)

30引数あると今日学んだ。自動生成とかでない、まっとうな用途のある関数で、一番多いのはなんだろう

(23:01)


2018-11-19


2018-11-29

_ 近況

  • たのしい
  • 無限にやることがある
  • 不安になる

の3点かなと思う

月曜は ONNX workshop @北京 というのに行って、自分のやってるプロジェクトを紹介したりとかした。 ONNX の本筋からずれたことを、圧倒的英語力(の低さ)で説明してたので、とてもスンマセンという気持ちだったけど、結構反応してくれて良かった。 Intel とかの人と話をするってのは、前職なかなかなかった

なんだかやることは無限にあって、無限から何ひいても無限だし、頑張ってもしょうがないのだけど、まあまあ頑張っている。がまあ限界があるので、社内で人を募集してみると、興味持ってくれる人も多いのだけど、それぞれみな自分のメインの仕事を楽しんでいるようだ

人が欲しいなら社外で拾ってこい、という教えがあると知り、なるほど、と、ツイッタで勝手人募集をしてみる。これまたこう転職してなければ無かったような会話が色々できて楽しい。色々説明したり、教えてもらったり、意外な共通の知人を発見したり、いろいろと

そんなことをして、いろいろ反応してもらったりしていると、なんだかかえって忙しくなったりする。がまあ、もともとおおむね一人なので、進捗が滞っても誰をブロックするということもない

基本知ったかぶりで生きているので、頻繁に不安になる。曖昧な理解で喋ってると真逆のことを言ってしまったりとか。が、まあ基本ポジティブシンキングなのと責任感が無いのとで、なんとでもなる

よくミスをするなあとか思う。技術的負債みたいなやつは定期的になんかしたほうがいいな

(00:12)


2018年
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h