なんか休みとれたので大阪へ向かう。 _
_ 周回遅れすぎるCrusoe大研究
手元に持ち運びできるマシンがCrusoeのマシンしかないのでそれを使う。 _
CMSの謎については前から気になってたのでこの機会に少し調べて書いた。 _
もうちょっと頑張って基本ブロック越えたときとか、プロファイルフィードバックどのくらいしてるのかとか見ればよいかもしれんがベンチマーク方法思い付かないので略。 _
エイリアス検出の仕組みは面白いな。普通のマシンにもあれば…と思ったけど、普通のマシンは例外のトラップでOSが絡んできて遅過ぎるので使いものにならないか。 _
ぱっと見た感じ、同クロックのPentium3に近いくらいの性能は出そうなんだけど、世間の評価としては、同クロックのP6,K7と比べると性能半分くらいなんだよな。 _
何が悪かったのか。キャッシュ?ベンチマークでは無い実際のコードでは駄目なのか？FPU,DIV,MULとかがヤバかったのか？まあ、もう滅びたプロセッサなのであまり真面目に調べてもしかたないのだけど。 _
大阪暑い。たまたま今が暑いだけらしいが。 _
なんか電車止まった。 _
私鉄とか経費削減で人員が少なすぎて、電車が止まった時の対応がすごい。駅で説明とか無いし。東京のJRは恵まれてるなぁ…と、思う。 _
まあ、東京のJRとかしょっちゅう電車止まって対応が慣れてるとかだと思うので、どうかと思うが。 _
_ ハチサン世代として一言言っておくか
ハチロク世代に関して言うと、けまらしい以外の感情を持ったことが無いので、ハチロク世代が叩かれているのを見ると、なんとも言えない清々しい気分になるので、人としてどうかと思う。 _
まあ、見ず知らずの人に偉そうに物を教えるのは、色々と日本人として難しいものがあるよな。と、思う。そうでない人も多いだろうけど。 _
ここで、ハチサン世代がいかにセカイ系かをもとにした話を書こうとしたけど、記憶違いだった(エヴァはリアル中二のころではなかった) _
ブギーポップとかリアル中二なんだがなー _
_ うちで飼ってたカブトムシが死んだ
と言っても、すでにおとといこっちに来た時点でほとんど動いてなかったけど。生きてるカブトムシがひっくり返ってるのを見たこと無いのに、なんで死んでるカブトムシはひっくり返ってるのか謎だったのだけど、死にかけてるカブトムシは自分の力で起きあがれないから、一回ひっくり返ったら終わりなんだなーとか、そういう感じで、夏休みは命の大切さを学ぶのだった。 _
_ 最適化されて読めないコードと読めるコードはどっちが価値が上かな…
きれいなコードを改変して読めないようにしたものを人に受け入れてもらうにはどうすればいいか… _
_ Crusoe
よく考えたら関数のインライン展開しないのはかなり不味いな。Efficeonで変わった大きい点は基本ブロック越えてスケジュールする点かな？でも、関数呼び出しや、virtual method呼び出しをスケジュールするとは思えないんだよなぁ。 _
というか、関数呼び出しで繋がってる基本ブロックをぶつ切りにするのは罪が思いな。 _
で、この問題の根が深い点は、x86だとあまり問題が無いという点にあって… _
x86は今生き残ってるプロセッサの中では静的命令スケジュールの点で特殊すぎる。けど、世の中の殆どがARMとx86で、これらはセグメント(て何？)が違うのである分野は殆どx86だけ。特殊なものが特殊で無いという間違った世の中になり、インライン展開はcall命令を減らすもの、ループ展開は分岐命令を減らすものになってしまった！ _
否否否！レジスタが多いマシンでは。インライン展開、ループ展開は、主にスケジュールの可能性を上げるために必要なのだ。 _
CrusoeのSoftware Optimization Guideにはループの中には最低でも10命令は並べろ、と書いてある。さて、あなたが最近書いたコードの中にある基本ブロック、つまり、call or jmp 命令以外の命令が連続してる数はいくつ？10個以上の命令が入ってる基本ブロックの割合は？基本的には、全ての基本ブロックは、10個以上の命令を持っておくべき。しかし！x86は、基本ブロックがそれより短い場合でも動いてしまう！何故か？x86はそのArchitectureの定義に「アウトオブオーダーであること」と書いてあるからだ。嘘です。x86の世界ではインオーダーマシンは思い思いと言われ、「こんなの省電力の世界でしか使えないよ」と言われてしまう！なんてこった！違う。プロセッサが悪いんじゃない！プログラマが糞なのだ！ _
virtual method呼び出しの、インライン展開しない関数の、エイリアスを考えてないload,storeの、短かいループのコストを、本当のコストを考えなおすべき！べき、羃、^^^∧∧ヘヘ！ _
なんか全然関係無い話を書いてた。みんなx86-64にして、Atomにして、それなりのコードを書くようにすればx86の静的スケジューリングの特殊性も減ると思うのだけど。 _
あとやっぱimulのレイテンシ13はでかすぎだろ。ARMとかでも3,4ぐらいみたいだし。 _
帰りの新幹線。充電してくるの忘れたな。今京都駅で、残り11910mWh。これ東京まで保つかな？ _
近くのスーパー行ったら魚屋のところで魚泳いでて、それ見ながら、 _
「あー、そういえば小さいころはこうやって泳いでる魚見てボーっとしてたなー。あれは小さい子だからできたことで、今みたいにオッサンになった自分がこれボーっと見てたらもはや不審者だよなー」 _
とかボーっと考えながら魚見てたので、もはや不審者だった。 _
_ テレビと世代交代
久し振りにテレビ見る。最近テレビ見て思うのは、バラエティ番組の世代交代って歪んでるよなーっていう。 _
普通、世代交代というと、FIFOなんだけど、バラエティ番組の世代って、一番上の世代が固定してて入れかわらず、新人が入ってきて新人が中堅になる前にフェードアウトしてるよなーって感じがする。 _
司会者達は僕がテレビ見てた頃(5年くらい前)から変わってないんだよなー。 _
あと20年もすればあの人達も年齢的に限界がくるのだろうから、さすがにフェードアウトすると思うけど、その頃まで今のテレビが残ってるだろうか？ _
カラーテレビを飾った人達は、カラーテレビの終焉とともにフェードアウトしていくのだろうなーとか。だからどうって話でも無いが。 _
_ Crusoe
つってもこれから公開なのでこれでやっとバージョン1だが。 _
あと調べるべき点は、 _
もうやる気ないのでやらないけど。 _
Efficeonとか手元に無いしな。あとCrusoeはそれなりに資料あるけどEfficeon資料無さすぎ。 _
今から書く _
生きてるよ。 _
http://www.asakura.co.jp/books/isbn/978-4-254-12173-5/ _
COINSの本とかあんのか。 _
http://www.a-qual.com/cosy/index.html _
あと商用のそれ系のってあるんだな。 _
_ x86むずい
http://alohakun.blog7.fc2.com/blog-entry-952.html _
これ読んで、「そんなに難しくねーし。基本抑えれば簡単だし」みたいな文書を書いてたのだけど、やっぱりむずかしかった。 _
addl %eax, %edx
addl %ebx, %ebx
addl %eax, %edx
leal (%ebx,%ebx), %ebx
これ、Core2だと、下のほうが速いのだけど、理由が謎すぎる。 _
下が1[cycle]で妥当。上が1.33[cycle]で少し遅い。lealのほうがうーおぷすたくさんになって遅いとかならまだ理解できるが… _
ちなみに _
addl %eax, %edx
leal 2(%ebx,%ebx), %ebx
これも1[cycle] _
久しぶりにまともな文が書いてある小説読んだ。 _
あれだなー。最近まともなテキスト読むのを敬遠してたのは、この読んだあとの何とも言えない感じを体験したくなかったからなんだな。 _
読後感と言うやつだろうか。残念ながら人と感情を共有できないので、「爽やかな読後感」というやつがどんなものかわからないが、僕としてはあまり爽やかな気分にはならないので、どっちかというと鬱屈とした読後感というか。 _
_ データ並列の技術って枯れてるってほんまか
「枯れてる」の定義がむずかしい。 _
_ 除算と条件分岐とロード
Core2のSSE2の倍精度除算ってレイテンシ10ちょいぐらいなのか。頭おかしいんじゃないか。 _
もう除算は遅いなんていうのは都市伝説になっていくのだろうか。いや、でも、パイプライン化されてないし、一回しか実行できないから、簡単な命令と比べたら数十倍ぐらい遅いのか。そう考えれば納得いかないでもない。 _
さて、プログラマにとって、「除算がおっそい」というのは、比較的浸透している考えかたであろうと思う。 _
では、「分岐がおっそい」、「ロードがおっっそい」というのは、どのくらい浸透しているのだろうか。 _
分岐はそれなりに浸透してる気がする。 _
ロードはどうだろうか？ _
除算や分岐の最適化は局所的な変更で対応できるけど、ロードの最適化はそれなりに大きな視点で変更しないといけないから、あとまわしにされるケースが多いか。 _
_ 公式が出してるGPUの資料で詳細スペックて
http://intellinuxgraphics.org/documentation.html _
Intelのやつぐらいか。 _
Intelのオープンソースへのとりくみってどういうポリシーでやってんだろうな。IBMとかはLinux滅んだらなんらかの影響があるって感じがするが、Intelは？ _
こんなのもあるなhttp://www.x.org/docs/AMD/ _
あとで読む系(読まないという意味) _
_ CTM とか CAL とか
今日までGPUプログラミングっていうと、高レベルAPIがどーんとあるイメージだったのだけど、AMDのはそうでもないな。 _
僕は割り込み、ISA、DMA転送が丸見えのほうが好みなのでやるならこれかな。やらないが。 _
_ プログラミングとか苦手な人にプログラミングを教えるのが可能だと思っている人は、自分が苦手なものにぶち当たって挫折したことないのだろうか
どんなジャンルでも、苦手な人の言葉として「何がわからないのかわからない」と、いうのがあると思う。 _
僕は過去に何度か、そういうのにぶち当たってきたことがある。野球、バスケ、音楽。 _
そういうのがあるので「何がわからないのかわからない」状態というのはまあ理解できる。 _
「何がわからないのかわからない」というのは、本当に何もわからない状態で、まあ、何もわからないのである。 _
と、いうような体験があるので、「何がわからないのかわからない」っていう人がいても、穏かな気分で受け入れることができる。良いか悪いかは知らない。 _
_ 適性が無い人には何を教えても無駄とか考えてる教育者って何なの？
分からない人に教えても無駄とか考えてる人は滅ぶべき。 _
_ あれ？
書かなさすぎ。僕がいかに毎日を無駄に過ごしているかがよくわかるな。書くことと言ったら虫が発生した系の話しかない。 _
行きます。 _
最近アクペクト指向的なものが欲しくなってる気がするな。 _
でもアスペクト指向では足りないんだよなー。 _
具体的には、変換したあとのコードが再編集可能になっていてほしい。 _
で、そういう自動変換したあとのコードが可読である、というのが最近の流行なわけなんだけど、そういうのをやりたいとなると、複雑な構文を持つ言語や、ひとつの処理に対して、複数の表現を持つ言語というのが、問題になってくる。 _
最近C++でなくてCを書きたくなるのは僕のそのへんの心境の変化から来てるのかもしれんというか、僕の超個人的な心境の変化をここに書いたところで誰かのメリットになるのか謎。 _
自動変換をかけやすい言語というのは、超抽象的なプログラミングという点でも、C言語を超える最適化するプログラミングという点でも有用である、という気がするのでプログラミング言語はそっちの方向に進化してほしい、と思っており、ある変な方向へ極端に尖って進化してしまったLLはさっさと滅んでほしい _
_ LLふーちゃん
というわけでLLなんたらは「LLは滅ぶべき」とかの話があれば行きたいと思うのだが。遠い将来には滅ぶべきという意見は多数の人に受け入れられると思うので、未来をテーマにするならあってもおかしくないと思うが。 _