grafi.jp

新しい AMD の GPU で色がおかしくなる問題

2021-03-08T15:10:00Z

Radeon RX 6800 で Linux 動かして画面がちょっと変なのをしばらく放置してたんだけど、改めて調べてみると YCbCr でディスプレイに送ってたせいでレンジがおかしくなってたぽい、あと変換時に誤差も出てたかも。

https://gitlab.freedesktop.org/drm/amd/-/issues/476

ドライバに雑なパッチ当てれば直るのは直った。

Threes

2021-03-01T03:37:47Z

Threes というパズルゲームがある。 2048 という模倣のほうが有名になってしまったゲームである。ピースを合わせて大きな 3 × 2 ^ n を作ることが目標。6144 はかなりの高スコアで、12288 を作ると “beat Threes” とされる。

引っ越し前後の家具の配置といった作業が一段落したのを機に、断続的にやっていたこのゲームを再開した。引きこもって過ごす今年の正月休みににやることとして、6144 を作れるまでがんばろうと決めた。

この記事は敗北の表明である。すなわち、わたしは 6144 を作ることができなかった。

発達・愛着

わたしはパズルゲームなどにのめり込みやすい性質をしている。自閉症スペクトラム障害の傾向を持つ人は多かれ少なかれ同じ性質を持つと思われる。しかしのめり込んでいると生活不能になる。実際のところ気が済むまでやれば飽きるので、気が済むまでやれればいいのだが、いつになれば気が済むのか分からないのは困る。結果として身につけた処世術は「適当な目標を決めて、それを達成するまでやり続ける」である。目標を達成するまで一週間なり音信不通になっても、一週間で済むならよいという考えである。

いつもの処世術を適用すべく、6144 という目標を決定した。その地点で 3072 + 1536 までは達成したのでいけるだろうと思ったのだが、3072 + 1536 + 768 まで達成するのが限度であった。実際のところ、16 マスという狭いプレイエリアにさらに 384 を詰めることにはより大きな技術と幸運を必要とする。もう少しだと思わせて実は先が長いという構造は、いわゆるコンプガチャと通底しており邪悪にも思われる。ゲームデザインとして意図したことではなさそうだが、少し失敗か。

ここまで読めばおわかりだが、目標が達成できないといつまで経っても生活できないという、致命的な欠点がこの処世術にはある。現に正月休みを過ぎても 6144 を作れずにいて労働に支障が出ていた。それでは困るということで目標を修正すればよいのだが、「自分への約束」たる目標値を修正することは中々容易なことではなく、自分を納得させるための相当な理由付けなりを必要とする。

ずっと粘ってればそのうち 6144 を作れる気もしていたが、しかし将来的なことも考慮するならばセルフコントロールを改善すべきである。その一つの方法として、文章に昇華させることはできないかと思いついた。

その試みは完全に成功に成功で、この文章を書き終える前のとっくに Threes をやり続ける気というものをなくしていた。これは一つの収穫で、素直にめでたいことだと喜んでいる。

冷静になってみると、なぜ恣意的に決めた数値にこだわるのだろう。誰かに「よくがんばったね、十分だよ」と言ってもらえればそれで済むのではないかとも思う。孤独であるのがよくないのだろうか。アルコール依存については孤独が極めて大きな要因だとも効く。愛着（attachment）がぶっ壊れてるんだろうかとも思う。入門的な和書や英語版 Wikipedia 記事を読むのは疑似科学かと半信半疑ではあるものの楽しい。自分は主に不安型であるだろうと感じつつ、回避型の要素も否めない。ただし回避については、コミュニケーションの齟齬で互いに傷付かないかという合理的な不安というふうに、自分の中では論理で説明できるように感じている。だからこそ説明不能なものとして不安的な要素を自覚しやすいのだろうか？

将棋・逸脱

ここ数年将棋連盟のモバイル中継で将棋観戦を楽しんでいる。観戦を始めたときは駒の動かし方と、美濃囲い・四間飛車・矢倉囲い・棒銀の名前くらいしか知らない程度だったが、解説の助けなどもあり、一つ一つの駒の動きに合理性があることの美しさや、難解な終盤のスリルを楽しんでいる。始めに観戦したのが先手藤井聡太七段（当時）後手広瀬章人八段の、挑戦者決定戦となる2019年王将リーグ戦だったのは非常な幸運だったと言える。名局賞特別賞にも選ばれた一局で、矢倉のジリジリした序盤からの激しい攻め合い、終盤戦での逆転に次ぐ逆転、そして最終盤のドラマと、全くの素人にも凄さが伝わってくる濃密な一局であった。

将棋ウォーズなどを始めて自分で指したいとも思いつつ、時間を無限に溶かしてしまうのが怖くて手が出せなかったりしている今日この頃。

大晦日にはニコ生で『大晦日将棋ライバルズ』を視聴し、改めて棋士の集中力に恐れ入り、見習いたいと感じていた。Threes で好スコアを出せないのも、集中力が足らずに構想立てや読みを省いて感覚でやってしまうところに原因があると考えている。仕事ではプログラミングの速度も課題である。集中方法と言えば登さんの記事を思い出す。「論理的思考」をどこまで行うかのバランスは人や状況によって変わりそうではあるが、没我的な集中状態を持続させることが肝要なことは確かだろう。わたしはまだまだ精進が必要である。

プロ棋士なんて「ゲーム廃人」そのものではないかとふと思ったことがあるが、そんなことはない。まずもって、将棋によって生計を立てられる。社会生活に支障がないなら依存症とは呼ばない。さらに対局時間に出席することは当然必要で、スポンサーを伴ったプロとしては様々な作法やファンサービスも求められる。歴史の発明だろうか、一つのゲームが人生の全てになってしまう依存的な振る舞いを一歩手前で止めるブレーキが備わっているように感じられる。少なくとも十分に適応的だとは言えるだろう。

十分に適応的であるならば精神的に真に健康と言えるだろうかと考えてみて、わたしは YES と応えたい。より狭い範囲を真に健康と定義するなら、人間について何らかのモデルが必要となる。近代が大量に必要とした工場労働者や軍人、あるいは近世における農民がその例だろう。そこから外れた人たちは、たとえそれなりに幸せに生きていても真に健康とは言えない。権力者から見ればその通りだったのかもしれない。

しかし、現代はより複雑な時代である。素朴であるが強力な反論だ。対しては、ではまた単純な時代になったらどうする？という問いかけが浮かんでくる。わたし個人としては「そんな時代にはしない」というのが本命の回答となる。これからも情報科学技術が世の中を大きく変えるだろうが、画一化された人間を求める方向に向かわないよう微力でも尽くしたい。一方で、大穴の回答としては「遺伝子操作で人類を変えれば済む」というのもある。いや、遺伝子操作技術が進歩したときにどうなるかはわからない。たとえばものすごく賢いヒトを作るのか、電子計算機の下働きとして適切なヒトを作るのか。尊厳を守るための枠組みを作るとして、人類が合意できる「尊厳」とはなんだろう。

2020

2020-05-25T04:46:33Z

2020 は 101 の倍数です。新年明けましておめでとうございます、と思っているともう半年経ってました。時間は流れる。

近況

なんとか修士課程を修了して、各方面にご迷惑おかけしながら博士課程には進まないことになり（@各方面ごめんなさい）、データ分析企業で深層学習を用いたプロダクトを作ることになって、しばらくしてから転職しました。今の職場では、独自開発の深層学習用プロセッサ向けにコンパイラやランタイムといった諸々の開発をやっています。わりと良いタイミングで応募することができたので、すんなり転職が決まったのかなと思います。人並みに忙しいことは忙しいのですが、物質的・心理的にすこし余裕ができたのは嬉しいです。

ここ数ヶ月は、COVID-19 の流行により引きこもり生活を送っています。世の中どうなるのか本当わからないですが、できることをやるしかないですね。

人生

人生むずかしいですね。今はバリバリ開発やってる（と思ってる）のですが、そんなにスタミナ溢れる人間でないので、いつまで続けられるのやら。ほとんど本読んだり映画観たりできてなくて、純粋に技術的な面以外では過去の蓄えをすりつぶしていそうで少し怖かったりもします。これは職場がどうこうでなく、自分のコンテキストスイッチがポンコツだったり、疲れっぽかったりするだけなのですが……。うまい具合にやっていきたいです。

最近はなにか真に意味のある知識を人類に残さねばならないみたいな観念が薄れてきていて、なんらかの形で少し貢献できるくらいでいいかという気持ちになっています。これは進歩なのか老化なのかわかりません。あるいは、小学生のときはふと死ぬのが怖いと思うこともよくありましたが、高校くらいになるとそういうことも減ってました。そういう類の、適応的な老化とでも呼ぶべきものなのでしょうか。受け容れるしかないでしょうね。

ずっと感覚がわからないのが、計画的な人生みたいな概念です。人生なんて風に吹かれる落ち葉みたいなもので、ただし落ち葉には自我があって小さなモーターを備えていて、あるいはそう思い込んでいて、少し自分の運命を操作することができますが、その結果を予測することなんてできようか。別に大きな社会の変動に振り回されることを気にしてるわけではなくて、むしろ自分の周りの小さな変動です。これまでの経験からして、出会う人や組織そして出会いのタイミングなどによって、人生を予測不能なものにするには十分な程度に自分の考え方までも大きく変わるように感じています。世間という大きな正則化項があんまり効いていないのか、元気があるかないかで100倍くらい火力が変動する人間だからか、まあそういう性質が表れているのでしょう。

独り身をやっていると意味不明な方向に突っ走って自爆しそうで、将来的にパートナーが居ればなあと思うようなことが増えています。ただ、恋人・パートナーは単なる自分の精神安定剤ではなくお互い win-win であることが最低限の前提であり、他の誰かではなく自分のような破綻した人間といてもいいことなんてあるだろうかと思ってしまいます。その割にマッチングアプリ的なのも本当に嫌で、出会いの偶然性を大切にしろ！恋のトキメキはないのか！という心情を拭えません。というか相手に求める条件みたいな概念がまるでピンと来なくて、好きな人のためなら物理法則の範囲内でいくらでも頑張れるし生産性100倍になるとか思っちゃう……。いわゆる就活を全くやらずに済んで、◯活と呼ばれるものをしたくないという無意味なプライドを得てしまっただけかもですね。

博士進学したいとぼんやり思うこともありつつ、精神的に不調になって各方面に迷惑かけるだけになるのが怖くて当面は考えられない……。本当に滅茶苦茶だった修士課程のときと比べればもう少しはマシにやれる自信はあるものの、まだちょっとねえ。

インターネットと肉体

どうしてインターネットはつらい場所になってしまったのでしょう、とくに twitter ですよ。特定の属性に向けたほとんどの批判めいた言葉は、まるで批判として成立しておらず

別にそんなことを言っている人はいない
一部の過激な人にしか当てはまらない
単なる揚げ足取り

という程度になってると感じます。「批判めいた」とすら呼べない明白な罵詈雑言はさらに多数です。Twitter で議論ができるなんて過剰な期待をし過ぎというのはまた適切な指摘に思いますけど、うーん。

それと、「党派性」に対する否定的な反応を多く見る気がすることも気にかかります。一人では政治的に無力だから党派を組むわけでして、党派性が力に繋がるのならそれは必ずしも思考停止と呼ぶべきものではないと考えています。

とはいえ、とくに感染症の拡がるこの世において、インターネットという技術はトータルとしてプラスの役割を果たしているとも信じています。インターネットを諦めない。

今の情勢ニューノーマルだのがもてはやされますが、ちょっと懐疑的なところもあります。リモートでのコミュニケーションも悪いものではないですが、人と人の対面のコミュニケーションで行われていた（それこそ飛沫といった）物質の交換がないことを無視していいのかわかりません。体表の化学物質は多くの生物において社会的行動をもたらす決定的なメカニズムであり、高次の情報処理が発達したヒトにおいても一定の役割を果たしているのでないかと思ってしまいます。本質的に人間は肉塊であるとも感じていて、プログラマに有りがちな「身体捨てて意識だけの存在になりたい」という発想もピンと来なかったりします。まあ、だからどうこうと主張があるわけではないです。

計算機

速い・安全・抽象的！がモットーです。いやはや。

深層学習バブルは COVID-19 がトドメとなって終わるとしても、深層学習の有用性は確かでしょう。これまでも深層学習は東京の土地くらいには価値があると話していました。90年代のバブル崩壊以上に東京の土地の価値が怪しくなってる現状からすると、どうも不吉なことを言ってしまっていたかもしれないですが……。それはそれとして、エンジニアリングの観点からみて深層学習がチャレンジングで面白い対象であることは確かです。これまでのワークロードと色々な部分で性質が違っていてうまく既存のパラダイムに載らず、様々な部分を新たに作る必要性が生じています。さらにそれでお金を稼ぐことができるので、世界中でハードウェアやソフトウェアの開発競争が起きているのは当然に思います。ちょっと過当競争すぎて効率を損なってる気はしないでもないですが。

さて、深層学習手法は学習結果の再現性がないとか言われますが、そんなのはエンジニアリングのやる気が足りないだけだろうと常々感じています。ハードウェアが変わる場合は最適な数値計算の順序が変わってしまって確かに難しいのですが、同じハードウェアなら完璧に計算結果を再現すべきで、ハードウェアや並列度が変わった場合でもデータセットや正則化手法で用いるランダムサンプリングは再現しろと常々思っています。 multfly および melty2 の counter-based pseudo random number generator を作ってみたのもそういう動機からで……、ちょっと放置してしまってますが。再現性が取れていることはもちろんアカデミックに有意義ですし、実務的にも学習が発散した場合などに原因を特定するのが簡単になるという大きなメリットがあります。

学習の再現性というのは、モデルの固定化を意味するものではありません。機械学習モデルを用いた人間の評価が社会的偏見を固定化させ得ることはいまや問題視されていますが、このメタレベルでのモデルの固定化とでも言うべき現象は、評価関数を始めとしたモデルの設計の問題です。ある一つのモデルがなんらかの隠れたバイアスを有しているために同じ「AI」の特徴量の気まぐれによって誰かが不利益を被り続けるという、より字義通りのモデルの固定化については、別のシードを使って再学習するなどの非決定性を持たせれば基本的には解消可能と思われます。そう、それぞれの人間もまた、いかに賢い人であろうとも理不尽なバイアスを持っているのです。ある人間に低く評価されたなら他の人間を当たってみることができるように、他の「AI」を当たることができればよいのでしょう。そうすることが可能な形で機械学習モデルが運用されることを願っています。

今の仕事では低レイヤ寄りの最適化などもやっているのですが、ハードウェアの都合が面倒くさいといった感覚はそんなにないです（非本質的な部分は面倒に感じることもありますが。）とりあえず、電子を無駄に動かすような回路を作ると無駄にエネルギーや製造コストがかかるという制約からは逃れられないと思っていて、ハードウェアはそういう物理法則にしたがって設計されているわけですので。計算機科学は物理法則と論理の橋渡しをする学問である、という自己流の定義がしっくりくるこの頃です。

QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる

2016-08-21T07:07:41Z

基本的にLinuxデスクトップ環境で過ごしているが、WindowsでBlu-rayを再生したいこともある。この要求を満たす環境の構成としては

Windowsの下でLinuxを仮想マシンのゲストとして動かす
デュアルブート
物理的に二台動かす

といった選択肢が考えられますが、1はLinux側で使えるリソースが減るのが気に入らず、2は面倒くさい、3はハードウェアと場所と電気が必要と、それぞれ大きなデメリットがあります。

このような難点を解消することはできないか。実はディスクリートGPUが挿さったマシンにおいては、PCIパススルーを行うことで、Linuxの下で仮想マシンのゲストとして動くWindowsから直接GPUにアクセスさせることができます。Linuxの方ではCPU内蔵のGPU（あるいは別のディスクリートGPU）を使います。SCSIパススルーを行うことで、WindowsからBlu-rayの読み込みなどもできます。こうすれば全ての難点はクリアされ、実際かなり快適に過ごすことが可能となりました。

始めは取っつきにくく、実際数日がかりの試行錯誤になりましたが、なんとなくわかってしまえばシンプルです。むしろこんなにすっきりしていて正常に動作する足回りが開発されていることがすごいなあと感じます。

必要なハードウェア

（Intelの場合）VT-xとVT-dをサポートしたチップセット・CPU
UEFI（GOP）をサポートするVGA

VT-dはちょっと前までローエンドや倍率ロックフリーのCPUだとサポートされてなかったので注意が必要です。他はすごく古くなければ問題なさそうです。

このあたりの機能がない場合、色々無理をしないとGPUのパススルーはできないです。技術的な詳細を追っていないので不正確かとは思いますがわたしの理解を書いておきます。

VT-dはIntelによるIOMMUの仕様です。IOMMUは、MMUがプロセスがアクセスする仮想メモリアドレスを物理メモリアドレスにマップするのと同様に、PCIデバイスがDMAする先を物理メモリアドレスにマップします。これによって、PCIデバイスが仮想マシンの下にある物理アドレスに正しくDMAできるようになると同時に、メモリ保護を実現できます。また、IOMMUはPCIデバイスが発生させる割り込みをVMに送信する機能も提供しています。

QEMUはVFIOというLinuxの機構を通じてPCIパススルーを行います。VFIOとはPCIデバイスに対応するioctlで操作できるファイルディスクリプタをユーザー空間に公開することで、ユーザー空間からPCIデバイスをフルに操作できるようにする機構です。ユーザー空間からDMAリクエストを行ったときに好き勝手なメモリアクセスをしないようIOMMUが使われます。QEMUはVFIOファイルディスクリプタをPCIデバイスとして仮想マシンに見せるわけです。

しかしGPUは普通のPCIデバイスみたいに単純ではありません。OSが起動する前に画面に何か描いてる地点でそれは明らかなのですが、特にBIOSで起動する場合はVGA BIOSというレガシーなABIを用いることとなり、システム全体にわたって固定されたアドレスを使ってデバイスとやり取りすることになります。なので複数のVGAを使う場合VGA BIOSをがんばって切り替える必要が生じてきて、さらにVGA BIOS領域にVFIO fdを介した変換される前のMMIOアドレスが見えてしまうのをなんとかしないといけません。このためパッチが必要になったりします。

一方でUEFIではそういったアドレス空間に関する問題はなく、OS起動前の画面表示はGOPというプロトコルで行っています。なのでより安全にパススルーができることになります。

参考

Linuxカーネルソース添付のvfio.txt
VFIO tips and tricks このAlexさんがLinuxカーネルのこの辺を色々開発してるらしい。IntelチップセットでのIOMMUグループのQuirkもこの人のおかげ。
VGA Assignment Using VFIO Alexさんのスライド
Replacing VGA, GOP implementation for UEFI AMDの人のスライド
ハイパーバイザの作り方 syuuさん
PCI configuration space - Wikipedia, the free encyclopedia

その他有ったほうがいいハードウェア

要するにこれは二台のマシンを動かすのと大体同じような構成です。よって以下のものは有ったほうがいいです。

ディスプレイ関連

ホストとゲストが別々に画面出力を行うことになるので、それぞれをディスプレイに接続する必要があります。このために

複数の入力端子があるディスプレイ
複数枚のディスプレイ
ディスプレイ切替器

のいずれかが必要となります。

キーボード・ポインティングデバイス関連

ゲストは仮想スクリーンに描画するのではなく全く独自に画面出力をしているのですから、カーソルをゲストのスクリーンの上に持っていくとゲストを操作できるというような、空気を読んだ挙動はできません。なので、ホストとゲストの双方に、別々に入力機器をつなぐ必要があります。

具体的には

複数のUSBコントローラの一部をゲストに渡した上で、USB切替器を使って入力機器を接続するUSBポートを切り替える
入力機器一式を二つ用意して、片方をゲストで使う

のいずれかが考えられます。後者は力技ですが単純で、特定のUSBデバイスをゲストに渡してやるだけです。前者では、一部のUSBコントローラのPCIデバイスを丸ごとPCIパススルーしてやり、切替器を使うことでホスト・ゲストそれぞれが制御するUSBコントローラに対応するポートにUSBデバイスを繋ぎ替えます。

わたしはUSBオーディオインターフェースの切り替えも行いたい都合でサンワサプライの2x2スイッチを使いました。また自分が使っているキーボード（HHKB）にはUSBハブがついているので、そこにトラックボールをぶら下げることにしました。外部電源を取っているおかげで無理がないからか、以前使っていたスイッチよりもキーボードが安定して認識されていて好調です。

           +----------+
ポート1----|          |----USBオーディオIF
           | スイッチ |
ポート2----|          |----キーボード（HHKB）----トラックボール
           +----------+

複数のUSBコントローラを用意するには、PCIeやPCIでUSBポートを増設すればいいです。一部のポートだけがUSB3.0であるようなチップセットではUSB3.0のコントローラが内部的に分かれています。なのでわたしのMBでは、USBポートの数や片方ではUSB3.0が使えなくなることを気にしなければ、増設の必要はありませんでした。（PCIeスロットが埋まっていることに気づかずPCIe機器を買ったり、その後PCI機器を買ってPCI-PCIeブリッジによる割り込みの問題で使えなかったりと、無駄足を踏みましたが。）

理論的にはハードウェアに依らなくとも、特定のキーボードショートカットやコマンドを実行したときに適当なUSBデバイスをゲストにアタッチ・デタッチさせるよう、ホスト・ゲストの環境をそれぞれ設定すれば、USBデバイスの切り替えは可能です。ゲスト側からのQEMUの操作にはGuestAgentが使えます。しかし確実に動くよう設定するのは中々大変そうです。

PCIデバイス・IOMMUグループの確認

PCI passthrough via OVMF - ArchWikiを参考にやりました。

わたしのマシンは

MB: ASUS P8H77-M
CPU: Core i5-3550 (IvyBridge)
GPU: GTX750Ti

です。ArchWikiにあるように

$ for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d); do echo "IOMMU group $(basename "$iommu_group")"; for device in $(ls -1 "$iommu_group"/devices/); do echo -n $'\t'; lspci -nns "$device"; done; done

を実行すると、

IOMMU group 0
        00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller [8086:0150] (rev 09)
IOMMU group 1
        00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)
        01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
        01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fbc] (rev a1)
IOMMU group 2
        00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09)
IOMMU group 3
        00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
IOMMU group 4
        00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
IOMMU group 5
        00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
IOMMU group 6
        00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
IOMMU group 7
        00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
IOMMU group 8
        00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4)
IOMMU group 9
        00:1c.5 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev c4)
        04:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 03)
        05:00.0 USB controller [0c03]: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] (rev 62)
        05:00.1 USB controller [0c03]: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] (rev 62)
        05:00.2 USB controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 65)
IOMMU group 10
        00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
IOMMU group 11
        00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC Controller [8086:1e4a] (rev 04)
        00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
        00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
IOMMU group 12
        02:00.0 Multimedia controller [0480]: Altera Corporation Device [1172:4c15] (rev 01)
IOMMU group 13
        03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09)

となっています。GPUはIOMMU group 1です。USBは、結局使ってないもののPCIでUSB2.0ポートを増設してしまっていたり、背面ポートと前面用のポートが別のコントローラにぶら下がってたりして見にくいですが、IOMMU group 10とIOMMU group 5をゲストに渡します。

ホストのLinuxの設定

わたしの環境は

カーネルを自分でビルド
initramfsは使わない
systemdで起動

というものです。ディストリビューションはGentoo Linuxですが、ディストリビューション依存の設定は特に行っていません。

カーネルコンフィグ・モジュール読み込み

QEMU-KVMに必要なオプションはQEMU - Gentoo Wikiに書いてます。PCIパススルーに関係するコンフィグはPCI passthrough - InstallGentoo Wikiを参考に

CONFIG_INTEL_IOMMU y
CONFIG_IRQ_REMAP y
CONFIG_VFIO m
CONFIG_VFIO_PCI m
CONFIG_VFIO_PCI_VGA y

とします（Intel CPUの場合）。

さらに

CONFIG_INTEL_IOMMU_DEFAULT_ON

も有効にすることで起動時のカーネルオプションが不要となります。

vfio-pciモジュール読み込み、モジュールへのオプション指定、VFIO fdのパーミッション設定を行います。

/etc/modules-load.d/pci-thru.conf

vfio-pci

/etc/modprobe.d/pci-thru.conf

options vfio-pci ids=10de:1380,10de:0fbc,8086:1e26,8086:1e2d

/etc/udev/rules.d/10-vfio.rules

SUBSYSTEM=="vfio", OWNER="root", GROUP="kvm"

そして、vfio-pciモジュールが指定されたPCIデバイスを先に制御下に置くことができるよう、パススルーするデバイスに対応するモジュールをカーネル組み込みから外します。わたしの場合は

CONFIG_SND_HDA_INTEL
CONFIG_USB_XHCI_HCD
CONFIG_USB_EHCI_HCD
CONFIG_USB_UHCI_HCD

をモジュールにすることとなります。またNVidiaのグラフィックドライバは、オープンソース・プロプライエタリなもの両方とも消しました。

こういうアドホックなカーネルコンフィグをしなくても、オプションを適当に渡すとか後からモジュールをunbindするとかすれば大丈夫なようです（PCI passthrough via OVMF - ArchWikiなど参考）。

ネットワーク周り

仮想マシンをLANに公開したかったので、ブリッジの下にTAPインターフェースをぶら下げることにします。TAPインターフェースの説明はLinuxカーネルソース添付のtuntap.txtなど。

まずブリッジを作って物理NICを入れて、ブリッジインターフェースにIPアドレスを割り当てます。

/etc/systemd/network/00-bridge.netdev

[NetDev]
Name=br0
Kind=bridge

/etc/systemd/network/10-eth-bridge.network

[Match]
Name=eth0

[Network]
Bridge=br0

/etc/systemd/network/50-bridge-static.network

[Match]
Name=br0

[Network]
Address=192.168.1.40/24
Gateway=192.168.1.1

QEMUのWikiには、適当なオプションを付けてQEMUを実行したら、non-rootユーザーからでも自動でTAPインターフェースを作ってブリッジに入れることができると書いていますが、Debianではセキュリティを懸念してqemu-bridge-helperのsetuidを外しているのでrootでしか使えないようで、Gentooでもsetuidは外れていました。あんまりrootで起動したくなかったので、自分でkvmグループからアクセスできるTAPインターフェースを作っておきます。

/etc/systemd/network/00-tap.network

[NetDev]
Name=tap0
Kind=tap
User=root
Group=kvm

/etc/systemd/network/10-tap-bridge.network

[Match]
Name=tap0

[Network]
Bridge=br0

QEMUの起動

QEMUのオプションは正直なところアレでした。短いけど汎用性のない古いオプションと、より汎用的な新しいオプションがあります。暗黙に色んなことが設定されて、それを上書きしたり、取り消したりするオプションが色々あります。こういう指定をするときにこう書くというパターンが確立されてるわけでもなさそうで、人によってバラバラです。ユーザーガイドに載っていないことも結構あります。直接起動するよりlibvirtを使うのがいいのかもしれません。

ともあれ、わたしの起動スクリプトは以下です。

    #!/bin/sh

## to add the optical drive
# device_add scsi-block,bus=scsi0.0,drive=sr0dr,id=sr0
## to remove the optical drive
# device_del sr0

qemu-system-x86_64 \
	-nographic -nodefaults -monitor stdio \
	-rtc base=localtime -enable-kvm -cpu host,kvm=off -smp 3 -m 4096 \
	-drive file="$HOME/edk2/Build/OvmfX64/DEBUG_GCC49/FV/OVMF.fd",readonly,if=pflash \
	-drive file=/dev/sdb,format=raw,cache=none,if=virtio \
	-device virtio-scsi-pci,id=scsi0 \
	-drive file=/dev/sr0,format=raw,cache=none,if=none,id=sr0dr \
	-vga none -device vfio-pci,host=01:00.0,x-vga=on -device vfio-pci,host=01:00.1 \
	-device vfio-pci,host=00:1a.0 -device vfio-pci,host=00:1d.0 \
	-netdev tap,id=vmnic,ifname=tap0,script=no,downscript=no -device virtio-net,netdev=vmnic

  

-drive file=/dev/sdb,format=raw,cache=none という指定は、/dev/sdb として認識されているSSD一枚を丸ごと仮想マシンに割り当てるための設定です。光学ドライブ関係は後で書きます。

Windowsのインストール

WindowsにはvirtioドライバがないのでRedHatが署名したドライバを入れる必要があったり、Windows 10へのアップグレードが上手くいかなかったりします。QEMU - ArchWiki: Preparing a Windows guestに書いてます。

SCSIパススルー

virtioでHDDや光学ディスクドライブを半仮想化する方法として、半仮想化されたブロックデバイスをゲストに見せるvirtio-blkと、半仮想化されたSCSIコントローラをゲストに見せるvirtio-scsiがあります。SCSIパススルーに使うのは後者です。/dev/sdX とか /dev/srX とかをファイル名として指定してやると、自動的にSCSIコマンドのパススルーが行われます。

しかしメディアが入っていない光学ドライブを指定して起動できなかったりと、メディアの出し入れ周りが完全にはならないようです。なのでQEMUのホットプラグ機能を用いて、device_add コマンドと device_del コマンドでデバイス自体を付けたり外したりすることで動かしました。

近況・DC1

2016-05-21T22:45:36Z

ここしばらく、論文やら、学振DC1（博士課程生が生活費と研究費をもらえる制度）の申請書やらを書いていて、疲れました。金くれ。具体的な申請書を上げたりはしませんが、知ってる人になら、言ってくれれば多分見せます。

だいたい申請書を書くのに三週間近くかかりました。なんとなく埋めるのは割とすぐでしたが、あれこれとやっていると専攻内の締切の一日後まで割とかかりっきりになってしまったという感じです。熱い戦いを振り返ってみますが、他の人の参考になるかはわからないです。

申請書を書く上でつらかったこと

筋を立てるつらさが3割、枠に収めるつらさが7割でした。既存研究を調べるのにも時間は使いましたが、楽しかったのでつらくはなかったです。

筋を立てるというのは、まず第一に研究計画に軸線を立てて目標をはっきり定めるということです。なんとなくやりたい研究はあるものの、なんとなくやりたいと書くだけでは当然ダメです。始めから筋がはっきりしている人もいるでしょうけど、わたしの場合は意識的に筋を通す必要がありました。それからこれまでの研究の背景なんかも、そうやって通した筋に沿うように書くことになります。もちろん研究内容はやったことを素直に書けばいいのですが、どの問題意識を重点的に書くべきかなどは、これからの計画によって変わってくるかと思います。

後は枠です。書きたいことを書いたら枠はさっさと埋まってしまいました。これを、内容を取捨し、言い回しを取っかえ引っかえして、またパッと見の印象があまりと黒々と詰まりすぎないように、削っていくことになります。図表もギリギリまで調整することになって、ことはミリメートル以下を争います。 PDFファイルを画面に表示すると線をピクセルにフィットさせてレンダリングされるので微妙な配置がわからなくて、高解像度ディスプレイがあると便利なのにと心底から思いました。この作業を締切前日まで行ったのが、つらさの3.5割でした。残りの3.5割は後にでてきます。

散歩

六義園を散歩しました。小高く築かれた丘から、緑の狭間にさっと水辺に架かる橋が見はるかせたのは圧巻でした。よくも計算して造られているなあと、申請書もこう計算して書かれるべきであると、書類に追われる身には感じられました。それから、なんかそのへんの道端にいるのよりも、鳩が綺麗な気がするんですよね。食べてるものが違うのかもしれないですし、気のせいかもしれないですが。この鳩のように、美しいところに居られる美しい存在であれたらと思いがよぎりました。だけど、きっとそう在れるのはほんのひと握り。

炎上

申請書が一通り完成した締切前日の夕方に、フォントサイズが規定よりも小さくなっていたことが発覚しました。原因は、ドキュメントクラスとして元々jarticleを使うようになっていたのを(lt)jsarticleを使うように変更したことです。どうもプリアンブルにあったフォントサイズ指定が効かなくなっていたようです。とりあえず、疲れたので寝るとメールを送ってふて寝をしました。

あくる締切当日に、フォントサイズを上げるように設定を行いました。幸いにも行間はそれなりに空いていたので、行幅を変えずにフォントサイズを上げることはできます。とにかく早く終わらせることを優先して、フォントサイズ指定が効かない原因を調べないままfontspecのscaleオプションでごまかしました。やってみると、ほぼあらゆる段落が一行ずつ伸びて悲惨なことになっています。

それからは、事務室に一日遅れるとお詫びを入れた上で、ひたすらにあらゆる段落を縮めました。言い回しを変えたり、内容を減らしたり、別の段落に内容を移動させたり、段落をマージしたり、まあ色々としました。これが最後の一日に降りかかってきた、つらさの3.5割です。おかげで深夜4時半くらいには全体が完成して、昼に起き出してから目が覚めた頭で見返して修正し、なんとか締切翌日には提出することができました。

その他申請書の内容について

基本的な戦術としては、「こいつは凡百な研究をしているわけではないっぽい、これを落としてはいけない」、と思わせる圧倒力を狙いました。ちょっと高密に書いたので、読む側としては大変かもしれないと少し申し訳なくはあります。ただ、それだけを理由として落とされることはないかなあと。漢字のひらき具合などは学振の書類と同じくらいを意識しましたが、別に申請内容の言葉は書類のメタな言葉とは違うので、あとからするとそんな意識はいらなかったなと思っています。

DC1・DC2で書かないといけない自己評価は、どんな人材が求められていることは意識しつつも、わりかし正直に思っていることを書きました。小説家でもない凡庸には、正直に思っていなければパワーのある文が出てこないもので、そういうパワーは投げつけてもいいかなあと。まあ、自分の良いっぽいところを見てゴーマンなことを書くことにはなります。あとは一般的なこととして、逐一あざとく主張には理由をつけるということも意識しました。

締切を終えての感想

この前の論文の締切よりは体力的には全然マシでしたが、精神的にはきびしいタイプの締切でした。やりたくないなあという思いが強いです。

特に最後の炎上のようなものは、それ自体は鎮火できたのでもういいのですが、どうやってこれから防げばいいのやらと思うとむずかしいです。自分としては当たり前のように使いなれた文書クラスに設定しただけで、そこに大きな問題があるとは全く考えていませんでした。当然同じミスは今後しないでしょうが、どうしたって本質的に同じような見落としを自分一人でなくせるとは考えにくいです。わたしの作業を随時みてくれる人がだれか居ればそれで済むのですが、そんなことを好き好んでするような人もいないですし。どれくらいの出力を求められるような生活するかは考えたほうがよくて、とくに自分は各能力の差がはげしいので、上側に合わせすぎないようにすべきでないかとも思った次第です。

natsu

2015-06-30T16:38:27Z

また夏が通りがかる。スローモーションの縄跳びが足をすくうように。ぼくは跳ぶ必要がない、なぜならずっと浮いているから。ぼくは悲しい。

φ

2015-03-10T18:46:50Z

Shrine（JR東日本田端駅）

2015-03-10T18:42:53Z

x86_64 Linux上でELECOM WDC-433SU2Mを用いて802.11acな通信を実現する

2015-03-07T13:41:50Z

追記：カーネルのバージョンは3.18.0で試しました。 3.18系では動作するものの3.19.1ではコンパイルが通らないようです。コメント欄参照。 id:nosada さん、ありがとうございます。

バイト先のオフィスがフロアのEthernetケーブルをなくしてWi-Fiメインにすることになったので、Wi-Fiでそこそこ高速に安定した通信を行う必要があり試した結果です。Macbook ProにGentoo Linuxを入れて使っているのですが、これまでは基本的に有線LANで運用していました。Macbook内臓のBroadcomのWi-Fiチップのドライバが、プロプライエタリなものは不安定でオープンソースのものは遅かったので。

さて、WDC-433SU2Mが使っているチップはRalinkという会社のもので、この会社は今はMediaTekという会社に買収されています。MediaTekはLinux向けのドライバのソースを公開しているので、そのドライバを適当にデバイスIDなど書き換えた上で使えばよさそうです。既に、 Elecom WDC-433SU2Mで802.11acな通信を実現したかった - テクニカルプアおよび Elecom WDC-433SU2Mで802.11acな通信を実現したのかわからないけどとりあえず動いた - テクニカルプアに手順などが記載されています。

ただし、そこで二つ問題があります。

ドライバのソースが64bit対応されていない
802.11acに対応する設定方法がドキュメントに記載されていない

上でリンクした記事においても、この問題でハマっていました。

64bit対応に関しては、幸いにも有志によって64bit対応されたドライバがGitリポジトリとして公開されているので、そちらを用いました。自分が用いたコミットはbe2e5d4です。

また、ソースコードを見たところ実際には802.11acに対応しているようで、ソースコードから推測した以下の設定を行いました。

具体的には、64bit対応されたドライバに対して以下のパッチを当てました。

    diff --git a/Makefile b/Makefile
index 25d87aa..f1e8fa5 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,7 @@ endif
 # rt8592(for rt85592), mt7650e, mt7630e, mt7610e, mt7650u, mt7630u, mt7610u
 
 ifeq ($(CHIPSET),)
-CHIPSET = mt7610u
+CHIPSET = mt7650u mt7630u mt7610u
 endif
 
 MODULE = $(word 1, $(CHIPSET))
@@ -196,9 +196,10 @@ endif
 
 ifeq ($(PLATFORM),PC)
 # Linux 2.6
-LINUX_SRC = /lib/modules/$(shell uname -r)/build
+#LINUX_SRC = /lib/modules/$(shell uname -r)/build
 # Linux 2.4 Change to your local setting
 #LINUX_SRC = /usr/src/linux-2.4
+LINUX_SRC = /usr/src/linux-$(shell uname -r)
 LINUX_SRC_MODULE = /lib/modules/$(shell uname -r)/kernel/drivers/net/wireless/
 CROSS_COMPILE = 
 endif
diff --git a/common/rtusb_dev_id.c b/common/rtusb_dev_id.c
index 061362a..fb7bf4d 100644
--- a/common/rtusb_dev_id.c
+++ b/common/rtusb_dev_id.c
@@ -38,6 +38,7 @@ USB_DEVICE_ID rtusb_dev_id[] = {
 #ifdef MT76x0
 	{USB_DEVICE(0x148F,0x7610)}, /* MT7610U */
 	{USB_DEVICE(0x13B1,0x003E)}, /* MT7610U */
+	{USB_DEVICE(0x7392,0xb711)}, /* WDC-433SU2M */
 	{USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7630, 0xff, 0x2, 0xff)}, /* MT7630U */
 	{USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7650, 0xff, 0x2, 0xff)}, /* MT7650U */
 #endif
diff --git a/conf/RT2870STA.dat b/conf/RT2870STA.dat
index 0240bd5..172df59 100644
--- a/conf/RT2870STA.dat
+++ b/conf/RT2870STA.dat
@@ -1,12 +1,12 @@
 #The word of "Default" must not be removed
 Default
-CountryRegion=5
-CountryRegionABand=7
-CountryCode=
+CountryRegion=1
+CountryRegionABand=1
+CountryCode=JP
 ChannelGeography=1
-SSID=11n-AP
+SSID=
 NetworkType=Infra
-WirelessMode=8
+WirelessMode=14
 EfuseBufferMode=0
 Channel=0
 BeaconPeriod=100

  

802.11acに対応するための設定は、RT2870STA.datでのWirelessMode=14の部分です。同ファイルにおけるCountry周りの設定は日本で使うことが許されている周波数帯を指定するものです。MakefileにおけるLINUX_SRCの設定はGentoo Linux依存のものなので、環境によっては必要ありません。

この上で、makeしてmake installすれば上手く動作しました。スピードテストの結果802.11acで動作しているであろうことが確認できました。また、しばらく使った感じだと、どうも三日に一回くらい落ちてしまう（抜いて挿し直させば復活する）のですが、それ以外は安定して動いているようです。

神戸 150104

2015-01-07T19:09:01Z

二次元の場合の接吻数問題を算数で

2014-10-30T02:18:38Z

接吻数問題（Kissing Number Problem）と呼ばれる問題があるそうだ。Wikipediaでは「（n 次元）接吻数問題（せっぷんすうもんだい、kissing number problem）とは『n次元の単位球の周りに単位球を重ならず触れ合うように並べるとき、最大何個並べることができるか』という問題である。その個数のことを接吻数という。」と述べられている。二次元の場合は、もちろん円の周りを6つの円で囲うのが解であるから、接吻数は6である。

この二次元の場合の接吻数問題を中学入試程度の算数の問題にできないかとこの前考えていた。算数の問題であるから、三角関数や三平方の定理を使ってはいけない。考えてみた結果、なんとかできそうだった。

誘導なしというのはちょっと厳しい気がしたので、以下のような小問に分割する。

半径2cmの円を1つ描き，その円に接するように半径2cmの円を6つ，それぞれ重ならないように（接してもよい）描け．
任意の⊿ABCについて∠B<∠CならばAB>ACを示せ．
⊿ABC，⊿A’B’C’がAB=AC=A’B’=A’C’を満たすとする．∠A<∠A’ならばBC<B’C’を示せ．
1つの半径2cmの円に接するように，それぞれ重ならない半径2cmの円を7つ以上描けないことを示せ．

1.は単なる作図である。半径2cmと4cmの同心円を描いて、半径4cmの円上に頂点を持つように一辺4cmの正六角形を取って、正六角形の各頂点を中心とする半径2cmの円を書けばよい。1.をもって接吻数が6以上であることが示されたとする。

2.を解くためには以下のように補助線BDを引けばよい。AD=ACが成りたつことからAB>ACである。

3.は以下のような図において△CBB’について2.の結果を適用すればよい。

4.は、ある円を取り囲む円を7つ以上描いたときに必ずどれか2つの円が重なることを示せばよい。このように円を描いたとすると、外側に描いた円の中心は、真ん中のある円の半径4cmの同心円上に載っているはずである。この同心円は、7つの頂点によって7つの扇型に分割されることとなる。もし7つの扇型の中心角が全て60°以上ならば和が360°を超えてしまうので、ある扇型について中心角は60°未満。この扇形の弦の長さは、3.の結果より中心角が60°の場合の弦の長さよりも短い。中心角が60°の場合は弦の長さは4cmであるから、弦は4cm未満ということになる。すなわち、2つの円の中心の距離が4cm未満ということとなり、このとき二つの円は重なってしまう。

LuaLaTex-jaでプロポーショナルかなを使う

2014-08-07T02:54:24Z

ごたくを並べる前に、プロポーショナルかなを使う組版例を以下に示す。プロポーショナルかなを用いたのが上側、普通のかなを用いたのが下側である。

    \documentclass{ltjsarticle}
\usepackage{metalogo} % for \LuaLaTeX command
\usepackage{luatexja-fontspec}
\newopentypefeature{PKana}{On}{pkna} % "PKana" and "On" can be arbitrary string
\setmainjfont[
    JFM=prop,PKana=On,Kerning=On,
    BoldFont={YuMincho-DemiBold},
    ItalicFont={YuMincho-Medium},
    BoldItalicFont={YuMincho-DemiBold}
]{YuMincho-Medium}

\begin{document}
\LuaLaTeX で、あっと驚きのプロポーショナルかな組版。

\jfontspec[]{YuMincho-Medium} \LuaLaTeX で、あっと驚きのプロポーショナルかな組版。
\end{document}

  

好き嫌いはあるかもしれないが、プロポーショナルかなの側では、まず明らかに「っ」の横幅が小さくなっているほか、「き」が浮いている感じがなくなり「プロポーショナル」というカタカナ語のまとまりもよくなっている。

’’’

以下、どのようなことを行っていることを説明する。ただ、TeXにもOpenTypeにもさほど詳しくないのでいいかげんなことを書いているかもしれない（OpenTypeについては http://kanji-database.sourceforge.net/fonts/opentype.html の記載、およびそのページからリンクされている一次資料が、大いに参考になる）。

まず背景として、 LuaTeX-ja というpTeXに代わる日本語TeX環境を開発するプロジェクトの存在がある。LuaTeXという新しいTeXのエンジンをベースにし、Luaスクリプトによって和文組版を実現するというものである。LuaLaTex-jaにおいては、LuaTeXの持つOpenTypeやUnicodeのネイティブサポートを始めとするモダンな機能をそのまま日本語TeXで用いることができる。

日本語TeX環境において、和文グリフの大きさなど（メトリクス）は、JFMと呼ばれるファイルに指定されている（なおLuaTeX-jaではJFMはLuaスクリプトである）。LuaTeX-jaの標準では和文グリフの横幅をTeXの側で固定にしているJFMファイルが使われるのだが、当然このままではプロポーショナル幅のフォントを使ったところで意味がなくなってしまうので、「フォントに指定された横幅を使う」という設定になっているJFMファイルを参照するようにしないといけない。なお、このことはLuaTeX-jaのドキュメントにも記載されている。

しかし、それだけではプロポーショナルかなは使えない。游明朝体で普通にかなを使った場合に参照されるグリフは、固定幅になるよう設定されているかなグリフであるからだ。おそらく、プロポーショナルかなが使える他のOpenType書体でも同様である。フォントファイルの中に存在するプロポーショナルかなのグリフを参照するためには、“pkna”という機能（feature tag）を使いたいと指定した上で、グリフ（のCID）を別のグリフ（のCID）に置き換えるテーブル（GSUBテーブル）を引かなければいけない。技術的には縦組用かなと横組用かなの切り替えと同じである。LuaTeXはOpenTypeのfeatureの指定に対応しており、LuaTeX-jaからも使えるようになっている。

ついでに、ペアカーニング機能も有効としたい。ペアカーニング機能は、特定の文字が並んだときに横幅を調整する機能である。欧文では一般的で、たとえば“AW”は横幅が詰められる。こちらも、GSUBテーブルで設定するというわけではないのだが、おおむね同様にOpenTypeの“kern”というfeatureを指定することで対応できる。

さて、ここまではplain TeXの話である。(Lua)LaTeXで使う上ではfontspecの枠組みの中でプロポーショナルかなを使えるようにしたいところである。fontspecではOpenTypeのfeatureを直接指定する代わりにあらかじめ定義されたオプションをfontspecに与えるようになっている。kernに相当するオプションはKerningなのだが、pknaに相当するオプションは現状定義されていので、こちらは自分でオプションを定義してやる必要がある。すると残りはJFMである。和文フォントの指定のためには素のfontspecではなくLuaLaTeX-jaが提供するluatexja-fontspecを用いることとなる。luatexja-fontspecは、実はJFMをオプションとして指定できるようになっている。

ここまでの内容を全部TeXで書くと、上のLuaLaTeX-jaのソースとなる。

指数時間かかるけれども空間消費量がほぼ定数（厳密にはO(n)）のフィボナッチ数計算

2014-06-10T07:18:09Z

再帰による実装ではスタックに途中結果を保持することで木構造を葉から根に辿るような順序で加算するが、そうではなく加算の順序をスケジュールして1ずつ加算するようにすれば可能。ステートを保持するためのスタックのようなものはどうしても必要になるが、計算結果を保持する必要は無く1bitしか取らずに済む。

    (define (fib-naive n)
  (if (< n 2) 1 (+ (fib-naive (- n 1)) (fib-naive (- n 2)))))

(define (fib-scheduled n)
  (define (go m prev state acc)
    (cond
      ((= m (+ n 1))
        acc)
      ((< m 2)
        (if (even? state)
          (go (+ m 1) m (quotient state 2) (+ acc 1))
          (go (+ m 2) m (quotient state 2) (+ acc 1))))
      ((= prev (- m 2))
        (if (even? state)
          (go (+ m 1) m (quotient state 2) acc)
          (go (+ m 2) m (quotient state 2) acc)))
      ((= prev (- m 1))
        (go (- m 2) m (+ (* state 2) 1) acc))
      (else
        (go (- m 1) m (* state 2) acc))))
  (go n (+ n 1) 0 0))

(display (fib-naive 30)) (newline)
(display (fib-scheduled 30)) (newline)

  

キャベツの新生活有吉玉青

2014-06-10T06:35:46Z

偶然立ち寄った新橋の古書祭りで文庫を眺めていたら、タイトルが面白いので手にとってしまった本。カバーも綺麗で良いですね。読んでみるとかなりの当たりでした。

どうして生きているのか。自分は何者なのか。そんな問いかけに高尚な自己実現だなんて題目を振りかざすのではなく、ただ生活を通じて自分自身の過去から何かを見出そうとする姿勢が見られます。真っさらなデザイナーズマンションで家具を買おうとするも、さてここからどんな部屋にだってできるのだと思うと、何も決められない。椅子を買おうとインテリアショップを巡ってみて、どれもこれもしっくり来ない。そんな情けないようなおかしいような話に、自分をどこにも定位できないという難問が重ね合わされる。個人的にはなかなかに好きです。

ただ異性愛絶対という感があるのがどうしても引っかかったけれど、そこは本質ではないと思って読めば十分に楽しく読めました。

Coqに入門

2014-05-27T00:26:20Z

前からやりたいと思っていたCoqを初めてみる。心が沈んで何もする気がしなかったのだけれど、夜の12時くらいに何となくCoqを書き出してみると、久しぶりに味わうような高揚感があり気がつくと朝に。自分の単純さがちょっとおかしくなる。

入門となる資料としては、主に Software Foundations を参考にしたのだけれど、どうも古いバージョンに基づいた記述なのか、そのままじゃ動かないところがあった。

Software Foundationsに載っているExerciseを一つ一つやるのも面倒くさかったので、Proof By Inductionの Advanced Exercise として載っていた、SuccとZeroによる自然数の表現と二進数としての表現の間の変換が正しいことの証明を行ってみることに。二進表現の一番上の桁に無駄に0が入ってしまわないように正規化しないと同じ自然数に複数の二進表現が対応してしまう。Exerciseでは列表現を二進表現にしてまた列表現に戻して元の表現になることだけを示せば良いのでこのことは問題にならないが、さらに正規化されているなら二進表現を列表現にしてまた二進表現にして元の表現が帰ることを確かめる証明も自分で行った。

とりあえず証明のコード。試行錯誤で書いてみたが、全然綺麗に書けていない。CoqIDEを使うと仮定の中身を示してくれるので仮定の名前を適当にしたまま証明が書けてしまうが、後から読み返すと読みづらい。あと、途中まで簡約した上でrewriteすれば済むところを、rewriteの対象となるtermおよびrewriteに用いるequationの両方をsimplしてからrewriteしているところがあるのだけど、途中まで簡約するのはどうするのだろうか、もしくはこういうのはsimplしてしまうのが一般的なのだろうか？

話がそれるけれど、GNU Source-highlightはCoqに対応していないのね……。Camlのシンタックスハイライト扱いにしてお茶を濁したけれど、Pygmentを使ってみるのも良いのかもしれない。

    Inductive binary := Eb : binary | Zb : binary -> binary | Sb : binary -> binary.

Fixpoint bin_to_nat b :=
  match b with
    | Eb => 0
    | Zb b' => bin_to_nat b' + bin_to_nat b'
    | Sb b' => S (bin_to_nat b' + bin_to_nat b')
  end.

Fixpoint succ_bin b :=
  match b with
    | Eb => Sb Eb
    | Zb b' => Sb b'
    | Sb b' => Zb (succ_bin b')
  end.

Fixpoint nat_to_bin n :=
  match n with
    | 0 => Eb
    | S n => succ_bin (nat_to_bin n)
  end.

Lemma plus_n_Sm : forall n m : nat, n + S m = S (n + m).
  intros n m.
  induction n.
    reflexivity.
    simpl. rewrite -> IHn. reflexivity.
  Qed.

Lemma homo_succ : forall b : binary, bin_to_nat (succ_bin b) = S (bin_to_nat b).
  intros b.
  induction b.

    reflexivity.

    reflexivity.

    simpl.
    assert (forall n : nat, (S n) + (S n) = S (S (n + n))).
      intros n.
      induction n.
        reflexivity.
        simpl. rewrite -> plus_n_Sm. reflexivity.
    rewrite -> IHb. rewrite -> H.
    reflexivity.
  Qed.

Theorem id_nat_bin_nat : forall n : nat, bin_to_nat (nat_to_bin n) = n.
  intros n.
  induction n.
    reflexivity.
    simpl. rewrite -> homo_succ. rewrite -> IHn. reflexivity.
  Qed.

Inductive regular_bin : binary -> Prop :=
  | regular_se : regular_bin (Sb Eb)
  | regular_zind : forall b, regular_bin b -> regular_bin (Zb b)
  | regular_sind : forall b, regular_bin b -> regular_bin (Sb b).

Lemma homo_double_z : forall n : nat, nat_to_bin (n + n) = match n with 0 => Eb | S _ => Zb (nat_to_bin n) end.
  destruct n.
    reflexivity.
    induction n.
      reflexivity.
      rewrite plus_n_Sm. simpl. simpl in IHn. rewrite IHn. reflexivity.
  Qed.

Lemma regular_z : forall b : binary, regular_bin b -> bin_to_nat b = 0 -> b = Eb.
  intros.
  destruct b.
    reflexivity.

    assert (bin_to_nat b = 0).
      simpl in H0. destruct (bin_to_nat b). reflexivity. inversion H0.
    induction b.
      inversion H. inversion H3.

      assert (bin_to_nat b = 0). simpl in H1. destruct (bin_to_nat b). reflexivity. inversion H1.
      inversion H. apply IHb in H4. inversion H4. apply H1. apply H2. inversion H0.

    inversion H0.
  Qed.

Theorem id_bin_nat_bin : forall b : binary, regular_bin b -> nat_to_bin (bin_to_nat b) = b.
  intros b.
  intros H.
  induction b.
    reflexivity.

    simpl.
    inversion H.
    destruct b.
      inversion H1.

      pose H1. apply IHb in r. rewrite homo_double_z. 
      assert (~(bin_to_nat (Zb b) = 0)). unfold not. intros. apply regular_z in H1. inversion H1. exact H2.
        case_eq
          (bin_to_nat (Zb b)). intros. unfold not in H2. apply H2 in H3. intuition.
          intros. rewrite <- H3. rewrite r. reflexivity.

      apply IHb in H1. rewrite homo_double_z. simpl. simpl in H1. rewrite H1. reflexivity.

    simpl.
    inversion H.
      reflexivity.
      destruct b.
        reflexivity.

        intros. rewrite homo_double_z.
        case_eq (bin_to_nat (Zb b)).
          intros. apply regular_z in H2. inversion H2. exact H1.
          intros. rewrite <- H2. apply IHb in H1. rewrite H1. reflexivity.

        apply IHb in H1. rewrite homo_double_z. simpl. simpl in H1. rewrite H1. reflexivity.
  Qed.

  

cold boot attack、耐タンパー性の極北

2014-05-03T18:52:16Z

cold boot attack という攻撃手法は、DRAM（いわゆる計算機の「メモリ」）は電源が切れてすぐにはデータは消えない（温度によるが数秒から数分）ということを逆手にとって、DRAMを物理的に冷却した上で、電源断→起動を高速に行うもしくはDRAMを外して別の機械から読み出すというものである。

たとえばBitLockerなどでラップトップマシンのストレージを暗号化した上で、ログインが必要になるようロックしておいたとしても、ディスクを暗号化するための鍵は（多くの場合）メインメモリ上にある。なので、この間にマシンを盗まれてしまうと、 cold boot attack によってディスクを暗号化する鍵が読み出され、ディスクの中身を奪われる危険性がある。TPMを利用したところで、結局のところ鍵はメモリ上に保持されるのだから同じことだ。特に現在ではスマートフォンにおける危険が大きい。

対策としては、暗号化するための鍵をメモリ上に持たないようにするしかない。上のようなケースでは、ロックを解除するときに入力するパスワードでディスクを暗号化するようにすれば良い。たとえば、マシンをサスペンド（ACPI S3）にするのではなく休止状態（ACPI S4）にすれば、安全ということになる。Androidでも画面をロックする度に内部ストレージをunmountすれば安全になるわけで、実際に DeadBolt という実験的な実装が存在する。

しかし、この方法は利便性という面から見ると完全に腐っている。ロックを解除する度に、（ブルートフォースを防ぐために十分に複雑である必要のある）暗号化キーを入力するというのは面倒極まりない。ロック画面で入力するパスワードは短くした上で、数回誤った入力が行われたら電源を落とし、そこで暗号化キーを要求するという方がよほど使いやすい。

あるいは、別の問題として、サスペンドしていない稼働中のマシンをひったくられるという局面に際しては全く無力であることも挙げられる。ただ、このような攻撃はCPUのレジスタ上の暗号化キーを保持することで対処可能であり TRESOR というLinuxカーネルなどのパッチなどの実装が存在する。しかし、デバッグ用のレジスタを使うなどの工夫はしているもののやはり暗号化キーにレジスタをいくつか専有されるのは他のアプリケーションにとって邪魔であり、また暗号処理を必然的にCPUの汎用レジスタ上で行うことになるため、空間消費の多いアルゴリズムは実行できず、そうでなくとも時間と空間のトレードオフによる性能の劣化は起こりうる。

さて、これらを踏まえた上で、安全性と利便性を両立するためにどのような方法があるだろうか？結局のところ求められているのは、物理的にマシンを奪われて何をされたところで、中身を読み出されることの無い記憶装置だ。TPMがそうだと言われるかもしれないが、あれは周辺機器の構成やRAMに読み込まれるプログラムの正しさを検証するのに役立つものの、プログラムを実行するハードウェア自体の耐タンパー性を高めるようにはできていない（脱線するが、Trusted Computing Groupの提供しているTPMなどに関するドキュメントを色々読んでいたもののやたらと分かりづらくて弱った）。また、TPMは容量が小さく遅い。暗号化のような処理をパフォーマンスの問題無く遂行するには、この記憶装置はキャッシュメモリのようにCPUに組み込まれるしか無いだろう。十分な耐タンパー性は物理的に大変なのかもしれないが、少なくともダイサイズに関しては最近のCPUが数MBのキャッシュや特定用途の命令（のための演算器）を平気で持つことを考えると問題無いレベルであろう。そういえばCellはCPUによるデータ保護を提供していたような気がする（調べ直す気力が無かった）。

さらに、フラッシュメモリのような不揮発性の記憶が、耐タンパー性のあるモジュールとしてCPU内に提供され、また現在TPMによって行なえるようなプログラムの検証が行われるとしよう。ロック画面で何回か短いパスワードの入力を間違えると長い暗号化キーの入力を要求するようにしようと上に書いたが、不揮発性の記憶を提供することで、これを電源断の後の通常のブート時にも行えるようになる。要はディスクを暗号化するキーおよび、パスワードを間違えた回数を不揮発性の記憶に保持すればいい（BitLockerのようにディスクを暗号化するキー（を暗号化するキー）をTPMに保持しても良いのだが）。この不揮発性の記憶がCPUに組み込まれていないと、たとえば信号線に細工して物理的に特定のアドレスへの書き込みを無効化することでパスワードの入力を間違えた回数を記憶させないようにする攻撃が可能になってしまうだろう。

そこまでするならTPMもCPUに組み込んでしまえば良いのではないかという話になる。外部の配線を介して繋ぐと何でも遅く危険になるし、貧乏臭いデバイスはプログラマにとっても使いづらい。やはりCPUというのは計算機にとって約束された聖域である。国家機関からの圧力などによってCPUにバックドアを仕込まれる危険はもちろんあるが、そもそもCPUにバックドアがあったら全てのプログラムが処理する情報が筒抜けなわけで、今更何が変わるということもない。CPUは信用するしかないというわけだ。

モバイル端末の普及によって、物理的なコントロールが奪われても計算機を守り抜かねばならなくなっているのは間違いない。分解しようとすると爆発する時限爆発のように、時にはフェイルデッドも必要なのだろうか。ただ、これは本当に実体のあるモノを守りぬかねばならないというのとは訳が違うと思う。それは、一箇所を完璧に守りぬくことができれば、後は暗号化を適切に施すことによって、そうでない場所を保護することができるということだ。ここに計算機の勝ち目がある。まだまだリアルワールドより安全だ。

さて、CPUの製造者に全てを委ねるというのは良いのだろうか。GNU的には LEON のようなオープンソース（さらにLEONはGPLライセンス）のCPUを使うのが正しいのかもしれない。ただ、オープンソースで提供されるのはCPUの回路記述であり、誰でもASICを作れるわけではないし、FPGAを使うにしてもFPGAにバックドアが無いことも論理合成ソフトウェアにバックドアが無いことも保障されない。

そもそも、ソフトウェアは誰にでも複製可能な存在であるが、優れたハードウェアを製造出来るのは限られた製造者だけだ。およそ工業製品と呼ばれるものは、製造のための装置に金がかかるもので、その装置を苦労して手に入れたものが大量に生産するものだ。もちろんさほど複雑な初期投資を必要としなくても作ることのできる工業製品も存在するが、悪いことに最近のCPUやFPGAは初期投資が極端にかかる類の工業製品だ。

確かに、性能の極めて低い半導体製品であれば、個人が作れるとは言わないがもっと小さい規模の組織でも作れるかもしれない。しかし、そんな性能の低い計算機を誰も求めていない。さらには、電力に対して性能の低い計算機を使うことはエネルギー問題の観点からみると罪ですらある。

このジレンマはどうにもしようがないが、個人的には諦めとともに楽観するような気分である。国家と言えども神ではない。CPUに仕掛けたバックドアを経由して個人を監視するほど暇も技術も有るとは限らない。計算機づくりは国際的な仕事（アメリカに集中しているのは否めないが、いつまでも続くとは限らない）であるからして、一つの国家が全てを支配していられるというわけでもない。そもそも一つ国家からして一筋縄な存在で無い。仮に個人を監視する仕掛けが存在したとしても、少し工夫すればしばらくの間は撒くことができるかもしれない。支配者にとって善良な者であれば気にしないことにすれば初めから困らないし、あるいは支配者にとって善良で無いものは昔からある程度世を忍んで暮らしていたのだから何も変わらないとも言えるのだ。

ちょっと話は外れるが、CPUにバックドアを仕掛けるなんて圧倒的な火力で攻めるという米軍のドクトリンであるかのような正攻法に思いを巡らせたくなる気持ちはあるものの、中国製製品の仕業である無線LAN経由でウイルス攻撃を行なうアイロンが発見されるなんてのも面白く、実はこれからの脅威かもしれないとも思われる。

SSE2などを使ったROT13の高速な実装

2014-04-11T17:01:18Z

ROT13と呼ばれる、アルファベットを13文字離れた文字に置き換える操作を行うプログラムを、SSE2を中心としたx86_64のSIMDによって高速化しました。結果としてテーブル引きによる実装と比べて4倍程度速くなりました。

ソースコードは https://github.com/grafi-tt/rot13-simd で公開しています。

基本的な発想は、何文字だけずらすかを比較演算の結果を元にして算出した上で元の文字に足し合わせるというものです。

大まかには、

各文字を0xDFでマスクして、小文字を大文字にする。
各文字を’A’-1、’M’、’Z’と比較する。比較結果は、-1あるいは0として得られる。
それを元に、「足す数」 / 13 + 1を算出する（or演算を上手く用いて命令数を削っている）。「足す数」は負になり得るが、ここで算出する数は必ず0以上。
その数に13をかける。8bit単位のSIMD乗算はできないが、変な繰り上がりがないので16bit単位や32bit単位で乗算しても問題は無い。このためにさっき0以上にする必要があった。
元の文字から13を引く。
4.と5.の結果を足し合わせる。

という流れで行います。

具体的な式を考えます。

dA := if c > 'A' - 1 then -1 else 0
dM := if c > 'M' then -1 else 0
dZ := if c > 'Z' then -1 else 0

とすると、ずらす文字数は (- dA + 2dM - dZ) × 13 となります。

2dM + 1 は、 dM | 1 で算出できます。これから dA + dZ を引けば、3.のステップが行えます。

実は乗算を使わなくても、

j = (dM - dA) × 13
k = (dM - dZ) × 13

としたときに、 dM - dA および dM - dZ は 0 か -1 にしかならないことから -j = (dM - dA) | 13 、 -k = (dM - dZ) | 13 として算出できるので、ここから j + k を求めることで「足す数」をいきなり求めることができます。

しかしこうすると、依存関係が伸びてスケジューリングが悪くなる関係なのか、微妙に遅くなってしまいました（SSE4.1のblendを上手く使えばひょっとしたら速くなるかも）。

両端の処理もmaskmovを用いてSIMDで行いました。maskの生成は結構大変だったけど何とかなりました（説明は省きます）。

ただ、maskmovがかなり遅くて短い文字列に対してはかなり（アンロールした実装と比べて10倍近く）遅くなります。両端はテーブル引きするようにすれば、テーブルがL1キャッシュに載っている限り速くはなりますが、なんか中途半端にテーブルを使うのは負けた気がします。maskmovを使わずに文字列の範囲外には元と同じ文字を書き込むようにすれば一気に速くなるし、ページ境界を跨ぐことは無いので多分セグメンテーションフォルトは起きないような気がするのですが、文字列を読み込んだ直後に他のスレッドからその部分の文字が書き換えられた場合にデータが壊れてしまいます。別にスレッドセーフじゃないといけないとかは思わないのですが、範囲外の文字まで安全じゃないというのは気持ち悪いです。atomicな加算を使えないかとも思いましたがやっぱりアトミックにメモリを操作するのは遅かったです。

CPU実験おしまい

2014-04-10T05:26:06Z

単位も来たので、CPU実験が完全に終了しました。約27億命令、44.8秒でした。

わたしのコアは https://github.com/grafi-tt/Maizul で公開しています。

流れ

10月前半

コンパイラ係になるつもりでいたけど、じゃんけんで負けてしまい、何となくコア係になってしまう。何をすればいいのか分からないので、試験勉強がてら図書館で借りて少しだけ読んでいたヘネパタ4th editionを買って、まずはひたすら読んでいた。

その後、いきなりパイプラインアーキテクチャを作るという方針でコアの実装を始める。途中まで実装が進んだあたりで命令セットの設計を完全にやり直したりも。

10月後半

コアのテストに必要なので機械語のシミュレータを書く。

SRAMが動かず何度も地下に泊まっては未明の本郷を徘徊しながら悩んだ末に、ついに論理的には初めから正しくてxst（論理合成プログラム、コンパイラのよなもの）のオプションを変更すると動くということを突き止める。これで機械語を手書きしたフィボナッチ数列を計算するプログラムが動作する。

その後、アセンブラを一応動く状態に持っていく。

11月前半

アセンブラとコンパイラを概ね完成させる。

MinCamlのライブラリ関数をアセンブラでひたすら書いたり、FPUの実装やテストなどを行ったり。

このあたりで見えてきた命令セットの微妙なミスを並行して修正する。

11月後半

まずは残ったFPUを実装。マンデルブロ集合をプロットするプログラム（MinCamlに付属）が動く。

コアの実装が解読できなくなってきてこのまま完動させる自信が無かったので、behavioralにデータパスを書き直す。ひたすらコアのデバッグを行い、MinCaml付属のmin-rt.mlが動作する。

そのあとレイトレ向けにコンパイラを修正し、無事11月中に完動。13erでは一番早かった。

12月〜2月前半

しばらくはお茶を濁すように形ばかり作業をしていたが、次第に何も進捗がなくなり進捗発表に行かなくなる。わたしが引きこもっているうちに他の班員が進捗を語っているかもしれないと思っていたが、どうやらそうでもなく一定期間班が消えていたらしい。

とりあえず冬休みに分岐予測だけは実装した。パイプライン実装だと分岐予測の実装はすぐにできると言われるし、実際簡単だと思っていたが、レイテンシの調整が複雑で相当手間取った。データパスの変更が必要だったこともあるけど、今から思うと実装方針が悪かったかもしれない（後述）。

あとは、余興でイーサネットを行うことにする。必要な資材を買い集める。

2月後半〜進捗発表

これまで逆数および平方根は加算と乗算を使ってアセンブラで実装して動かしていたが、VHDLによる実装が出来たとFPU係から報告を受ける。試してみるとほぼそのままで問題なく動く。チームプレイってこういうものなのかとしみじみ喜ぶ。

試しにクロックを上げてみると、少しFPU周りのパイプラインを調節すれば110MHzで安定した。121MHzは動かずあきらめる。

コンパイラ演習で壊れているスケジューリングを実装していたので、動くように直して取り込む。分岐予測も壊れていたので、一応直す。（ただしこのあたりは本当に直っているかあやしい）

また、min-rt.mlの初期化ルーチンの改変は許されているので、実質的にグローバル変数として確保されている配列をアセンブラに移して、MinCamlの上でクロージャが作られないようにしておいた（無論グローバル変数の検出をコンパイラで行うのが本当は正しい）。進捗発表直前に地下でコンパイラ係と二人で作業して何とか間に合わせた。

イーサネットキットは必死こいてハンダ付けしたが、ハンダ付けが完了したあたりで力尽きた。FPGAからの制御方法は一応考えたのだけど……。

感想

CPU実験ではチームプレイを学べるという噂がありますが、わたしに限って言えばあまり学べなかった気がします（反省点があるという意味や向き不向きが分かったという意味で全く学べなかったとは言いませんが）。それよりも、がんばればこのくらい大きなものがこれくらいの期間で実装できるんだなという感覚が学べたように思います。

12erが11月中にほとんど動いていたという話がプレッシャーになって、かなり無理して11月中の完動にこぎつけたところはあります。やる気を喪失したのはその反動もあるとは思いますが、ではどうすればよかったのかと言われると分かりません。祭りのような、それを行うことに何らかの権威的なお墨付きが与えられた上でチームで行う活動に対して、傍から見ているとあんまり関わりたくないと感じるものの、いざ自分がコミットしてみると結構快楽を感じる、そういう性格をしているように思います（もっともこれは多くの人に当てはまる性格かもしれない）。コミットする際に感じるのはあくまで自分の中で閉じた快楽であって、周りの人と心を通わせてた上で何かをすることを楽しいと感じているのかというとそうでは無いような気がします。別にそれ自体が必ずしも悪いことでは無いのですが、ちょっと嫌な面かもしれません。

あとは、わたしはライブラリ関数やテスト用のプログラムをコンパイラが安定してからもMinCamlで書かず全てアセンブラで書いていたのですが、それはやはり自分が設計および実装に携わったことによる慣れや思い入れがあったからのような気がします。そう考えると、自分でコンパイラをフルスクラッチしていれば、MinCaml（を拡張した言語）をもっと書く気になっていたかもしれません。

ご指導頂いたTAや12erの方々に感謝します。班員の方々には勝手に動きすぎたことをやや申し訳なく思うとともに感謝します。13erのみなさん、特に技術面や精神面で多大な支えとなって頂いた @nemunemu3desu に感謝します。またこの文脈で適切かは分からないですが @alpicola には限りなく感謝します。

アドバイス

取り立てて速く動かしたわけではなく何かすごいものを作ったわけでもないのに色々と書くのはおこがましいのですが、まあ思い当たるところを書いておきます。

コア

はじめに断っておきますが、2命令以上の同時発行やアウトオブオーダーに関しては分かりません。他の人を当たってください。

また、ここに書いてあることはいかにもRISCくさいですが、いっそCISCに振りきれるのも楽しいかもしれません。

HDLの書き方

process文はクロックの立ち上がりでレジスタに転送するためだけに用いて、基本的にsignalのみでデータフロー的に書くのが良いという噂をIS周辺で耳にしました。確かにsignalのみを使ってプログラムするのは、VHDLの複雑さと係わらずに済むという意味で分かりやすく、ハードウェアのモデルと近いので論理合成の結果に問題が出にくいのかもしれないとは思います。

しかし、VHDLはデータフロー的なモデリングを行うためだけの言語ではありません。xstはif文やループくらい組み合わせ回路に展開できるし論理圧縮もやってくれます。実際、Web上のHDLプログラミングに関するリソースにも、データフロー的にVHDLを書くことを推奨するような記述は全く見当たりません。signalはコンポーネント間の接続やクロックをまたいで保持する情報などに用いて、ロジックはbehavioralに書けば良いのではないのでしょうか。

といってもやみくもに書こうとすると良い書き方が分からずかなり苦しみました。 @hiyuh さんからtwitterで教えた頂いた A strucutured VHDL design method （スライド）という論文で説明されている、twoprocというデザインパターンが極めて有効な指針でした。

分岐予測

まず、「分岐するかどうかを予測する」方法と「アドレスを予測する」方法があります。後者だと例外の実装がちょっと簡単になり、関数のリターンアドレスの予測も統一できます。前者だと多分回路は少なくて済みます。どっちが良いかはよく知らないですが。

どちらにせよ、「分岐予測の失敗」に対処する必要があります。そのために分岐予測の結果をしばらくの間保持しておくことになるのですが、fetchフェーズあたりの分岐予測ユニットの中で保持する形で書くよりも、executionフェーズあたりの実際の分岐を決めるユニットまで命令と一緒に流す方が、ストールなどの処理が明らかに簡単なはずです。わたしはここで完全にハマりました。

GPR/FPRの分離

データパス周りでの配線遅延を減らすには、データを必要以上にあっちこっちに流さないようにすることが（多分）大事です。とりあえずGPR（汎用レジスタ）とFPR（浮動小数点数レジスタ）は分けた方が賢明らしいです。

さて、わたしのコアでは、ALUとFPUはそれぞれ整数レジスタおよび浮動小数点レジスタのみに書き込むようにはしていましたが、ALUの入力として浮動小数点数を使ってもよく、FPUの入力として整数を使ってもよいような実装となっていました。こうすることで、たしかにFPR/GPR間の移動や浮動小数点数の比較やitofが自然に実装できるようになります。しかし、ALUとFPUの重い命令同士が（例え重い命令ではねじれた入力を必要としなくとも）フォワーディングによってつながってしまうことになり、そのままクリティカルパスとなってしまっていました。ALUの入力は整数のみFPUの入力は浮動小数点数のみにした方がよかったかもしれません（試していないので本当に正しいかは不明。またこの場合は本当に重たい処理が存在しているわけではないので、xstのregiser balancingを有効にすればひょっとしたら解消するかもしれない）。こうすると、GPR/FPR間の移動などは特殊な命令とすることになります。

FPU

基本的にみな「神資料」に従うので没個性なパートです。また、FPUのサイクルを全ての命令で固定するなら3サイクルよりも縮めるのはおそらく相当厳しいので、逆に3サイクルで動かすにはオーバーキルな最適化を余裕がある命令に対して行う必要もあまり無いことになってしまいます。

が、実行サイクルを可変にするなら最適化の余地は存在します。まず、許される範囲で丸めを適当にすれば速くなるかもしれません。加算のレイテンシを根本的に縮めるのに有効そうなのは、 2パス加算器です。ヘネパタのAppendix.J には、加算器の数を節約しつつ一回の加算で済ませる方法の記載があります。わたしの faddの実装は、多分ヘネパタに記載の実装になっているので参考になるかもしれません（ハードウェア実験の際に自力で考えた工夫がたまたま一致していた）。わたしの FPU は全体的にある程度速度を意識しているので、ひょっとしたら参考になるかもしれません。

加算と乗算は最近接偶数丸めをきちんと行う実装があったほうが、三角関数や除算のソフトウェア実装の精度が出るはずなので好ましいかなと思います。あとは、WikipediaやIEEE754の仕様書を参考にしつつ、0の符号の扱いなどに気を付けましょう。

コンパイラ

MinCamlを改造してレイトレを動かすだけなら、基本的に雑用です。出力部を書き換えて、倍精度浮動小数点数を扱うため8byteにしているところを単精度で良いので4byteに書き換えて、ひたすらライブラリを書けば、大体動くはずです。その後の最適化はほとんどやっていないので分かりません。個人的にはMinCamlベースで改善していくよりも、余裕とやる気があるならば、最低限MinCamlベースで動かしたところできりあげて、フルスクラッチしたコンパイラで最適化するなり言語を拡張して遊ぶなりするのが楽しそうです。

スケジューリングだけやりましたが、MinCamlのバックエンドのデータ構造のハンドリングで苦労し、またOCamlの標準ライブラリが貧相で苦労しました。早めに基本ブロック単位の処理などがしやすいようバックエンドに手を入れておくとか、Janeのライブラリを使ってみるとか、すればいいのかなとは感じました。

シミュレータ

シミュレータで一番大切なことは、とにかく確実に命令を動かしてくれること。速度とかデバッグ機能とか、そんなことよりも走らせた結果に嘘が無いことが大切です。

それなりに速く動くようにするなら、まあスクリプト言語で実装するのは止めたほうがよさそうです。大人しく配列を使ってレジスタやメモリを表現すれば、関数型言語で実装してもおそらく速度的な問題は無さそうに思えます。OCamlで実装するなら64bitマシンでないとunboxedなintが31bitしかなくて遅いと語り継がれているようです。

まじめに作るなら、機械語を解釈する部分をCで実装してフロントエンド部を他の言語で作るのが最善かなあと個人的には考えます（高速な高級言語で全部実装するのもアリでしょうが）。たとえばちゃんとデバッグできるようにするなら機械語をアセンブラに変換して出力する機能くらいはまず欲しいですが、それすらCで実装するのは苦痛です。また、一番重要な箇所をCで実装することには「誰でも読み書きできる」というメリットがあります。あんまりかっこよくはないやり方ですが、シミュレータの内部状態はグローバル変数として保持するようにして、「次のブレークポイントあるいはシミュレーション終了まで実行する」関数をCで実装してexternした上でフロントエンドから呼び出しするのが、比較的やりやすいでしょうか（自信は無い）。

Cの実装に関しては、命令デコードのために 2進数リテラルもどきを使うのが便利です。コンパイラの拡張やC++14で2進リテラルが使えますが、環境依存はあんまりよろしくないです。あとは、math.hやstdint.hやinttypes.hは役立ちます（むしろFPUのソフトウェア実装で活躍しますが）。C99は正義。

サイクルアキュムレートシミュレータ（きちんと理解していないけど、多分コアのパイプライン状態までシミュレートするシミュレータ）は、有るに越したことはないと思いますが、下手するとコアをもう一つ作るようなものになってしまうので大変かなとは思います。コアと実装が完全に一致しているかどうかを確かめるのも困難な気がします。「コアの設計としようとしているものが正しいかどうか検証するのによさそう」という話は聞きましたし、それはその通りだとは思いますが、先に書いた理由や、論理的には間違っていない設計でもFPGAでの実装として筋が悪いことはあるという理由から、効果のほどはやや疑問です。ただ、コア係とシミュレータ係の相性が良ければやってみる価値はあると感じます。

アセンブラ

スクリプト言語でちゃらっと実装してしまって動くもののような気もしますが。

代数的データ型がある言語でアセンブラを実装することを考えます。この場合、全ての命令を同じ型にして、コンストラクタで命令を区別するのが自然です。さて、各命令が引数として受け取るのは、GPRやFPRや即値やラベルのてんでバラバラな組み合わせです。こうした状況で、各命令を表すデータが正しい引数を持つということを型レベルで保証するのには、OCamlの多相バリアントが便利でした（もっともこの程度なら、各命令ごとに別々の型を用意してインターフェースやType Classで処理しても良さそう）。

型安全に実装しようとすると、命令を表す文字列をコンストラクタの名前に持ち上げるためのボイラープレートが大量に出来てしまいます。Template Haskellなどでボイラープレートを自動生成するとか、Camlp4などでアセンブラのコードを直接読み込んでしまうとかすれば、ボイラープレートは無くせるかもしれません。

夢

200MHz

SRAMを半分の速度で動かせば理論的には可能ですよね。

ハードウェアレイトレ

min-rt.mlをそのままFPGAで実装すればすごく速そうです。実際FPGAで特定のアプリケーションを実装して高いスループットを得たという論文は見つかります。おそらく深いパイプラインが肝です。

Linux動作

Linux動作のためにやるべきことを考えるのが最終レポート課題（の一つ）でした。

独自アーキテクチャにGCCとLinuxカーネルをポーティングするとか、x86_64を実装してやるとか、まあ面白いのですがLinuxがサポートするシンプルなアーキテクチャ（たとえばMIPS R3000）ベースにするのが無難そうです。当たり前ですがノイマン型（命令とデータをともにSRAMに入れて、BlockRAMはキャッシュとして用いる）になりますし、TLBも必要です。あとは、RS-232C/SDカードをコアから操作できるようにして（デバイスのレジスタを適当なアドレスにマッピング）、特定の組み込みデバイスをターゲットにした既存のドライバのソースコードを参考にしつつドライバを書けば、なんとかできないことはないかもしれません。

インターネット

わたしが LF-A1 というAX88796搭載のキットを半田付けはしました（下手くそだけど）。チップをコントロールするレジスタおよび送受信バッファを命令レベルから操作できるようコントローラを書けば、理論的には動くはずです。プロトコルスタックを書けば理論的にはインターネットができるはずです。デバイスドライバを書くくらいのレイヤーで扱えるので、物理層を直で触るのに比べるとかなりソフトウェアっぽいです。

チップのレジスタへのデータの読み書きは、普通のRAMのようにしつつ、データシートを参考に適当なクロックだけ待ってやればできると思います。チップからの割り込みは、割り込み信号をFPGA上のレジスタへのAsynchronous Resetにして、コアのクロックでそのレジスタを監視すれば扱えると思います。受信バッファのデータはチップ側のクロックでDMA転送されますが、これは非同期の読み書きに対応しているXilinxのBlockRAMを使ったキューを介することで、おそらくコアのクロックで読み出せるようにできます。

ピコピコ

2014-01-19T23:29:27Z

試験勉強から逃避して、冗談でも書きます。

友人が優秀な英作文の話をtwitterでしていた。自分はろくな英語も書けないし、読む方も英語ネイティブで無いプログラマのいい加減な英語ばかり読んでいて、これはいけない少しまともな英語を眺めて心を改めるかと guardian.co.uk を開いた。そうすると、 UbisoftがテトリスのXbox One版とPS4版を出すというニュースが目に入った。テトリスに熱中した経験は誰もが有る。また、どんな計算機にもテトリスは移植される。それは言語や文化を超えていて、限りなく純粋なインタラクティブ体験。テトリスはまるで、人間の脳に直接アクセスして、脳にとってネイティブなマシン語で働きかけているかのようだ。そんな感じで記事は締めくくられていた。

久しぶりにテトリスでもやってみようかと思った。ブラウザで動くテトリスなんてごまんと有るとは思うが、とりあえず tetris.com からリンクの貼ってあった http://www.freetetris.org/game.php をやってみることにした。結構楽しい。確かに熱中した。（ただし、 http://www.twitchtetris.com/ の方がモダンで良いと思う。）

さて、他の（個人的には）快楽を感じる単純なパズルゲームとして、整理整頓自衛官が挙げられる。この二つのゲームはどう違うのだろうか。

テトリスは、決まったペースでテトリミノが落ちてきて、粛々と処理し続けることを要求される。言うなればライン工で、テトリスをしている間はテトリスのことを考え続ける。そこで訪れる忘我状態は思索を許さない。テトリスには様々なクローンがあり、ゲームバランスがそれぞれ異なれど、ゲームデザインの根本的な部分が人を惹きつける。一つ一つ振りかかるテトリミノを処理するという部分は同一であり、テトリミノを並べることに惹きつけられた脳は、身体の一部と化した単調な作業に溶かされていく。予定調和的な、あるべきディストピアの姿とも言える。

整理整頓自衛官は、やりながら様々なことを考える。好意を寄せる人のこと、友人のこと、将来のこと。粛々とした歩みは無いが、しかし一方で乱数は理不尽だ。調子が良いときはサクサクと盤面を整えておけるのだが、やがて乱数の暴力を浴びせかけられてしどけなく乱れ、はち切れてしまう。このゲームは、ゲームバランスだけで面白さが成立しているように感じられる。たまたま危ういバランスの上に成立しているだけの世界。心は揺れる。

Lua 5.2のデバッグライブラリを用いたリフレクション

2014-01-14T15:29:12Z

Luaは殆どのオブジェクトが自由に上書き可能なテーブルであるためかなり柔軟なメタプログラミングが可能な言語であるが、言語のセマンティクスの内側からはローカル変数自体を触ることができない。しかし、例えばRubyの文字列展開のようなものをプリプロセッサを使わずに実装しようとすると、どうしてもスタックフレーム中にあるローカル変数にアクセスしたくなる。printf使えば済むとか、LISPのマクロやTemplate Haskellなどによる実装の方が好ましいとか、思わなくもないが、まあとにかくLuaで何とかしたいこともある。

debug.hoge でアクセス可能なデバッグライブラリの機能を使うと、何とかすることが可能であった。割と整理された関数が提供されているものの、デバッグ向けのライブラリであるためにインタプリタの実装に近い部分のモデルに従った機能が提供されており、何をするものか少し想像が付きづらかった。公式のドキュメントでは、一度分かってしまうまでは分からない類の解説がなされており、わたしは始め読んでいて何を言っているのか分からなかった。

ここでは、Lua 5.2のデバッグライブラリを用いた変数周りのリフレクションについて、背景に有りそうだと感じられる概念を含めて書いておく。Lua 5.1とは多分微妙に違う。なおスレッドやコルーチン周りについては（わたしが知らないので）完全にスルーする。

Lua 5.2における環境とは

まず、Luaのドキュメントを読んでいてenvironmentという言葉が出てくるが、これはSchemeインタプリタにおけるenvironmentとは全く違うので注意である。分かってしまえば大したことはないが、わたしはここで激しくつまづいた。Luaのローカル変数は、Schemeと同じくレキシカルスコープに従っている。Schemeでは、レキシカルスコープに従った変数名と変数の対応付け、つまりLuaで言うところのローカル変数のマッピングをenvironmentと呼ぶが、Luaにおいては_ENVという名前のテーブルをenvironmentと呼び、これはむしろグローバル変数のマッピングとしての役割を果たす。

Luaにはローカル変数とグローバル変数があることを思い出そう。ローカル変数のスコープは単なるレキシカルスコープである。一方、グローバル変数 hoge へのアクセスは _ENV.hoge へのアクセスとして扱われる。 _ENV は、単なるローカル変数としてアクセス可能なテーブルであり、トップレベルで暗黙に定義されているとみなして良い。よって、グローバル変数は、同じローカル変数 _ENV が見える範囲内をスコープとすることになる。

以下の例がこの挙動を示している：

    local myprint = print
a = "a"
b = "b"
myprint(a) -- prints "a"
myprint(b) -- prints "b"
do
    local _ENV = {
        a = "aaa"
    }
    myprint(a) -- prints "aaa"
    myprint(b) -- prints "nil"
end
myprint(a) -- prints "a"
myprint(b) -- prints "b"

  

単一のソースコードで普通にプログラムを書く際には、ローカル変数だけで大体片がつくのでグローバル変数の概念はさして有用でもない。ただ、他のコードをrequireしたりevalしたりする際に大域的に見える関数や変数が定義される場所としてenvironemntは重要であり、また実際には単一のスクリプトを実行する際にも print のようなグローバル関数がenvironmentの上に定義されているということになっている。

Schemeでは、この際に「Schemeにおける」environmentを受け渡す。Schemeにおけるenvironmentの普通のS式での表現は自明では無く、environmentは組み込み関数によって取得可能であるが特殊なプリミティブとして扱われる（R5RSではこんな感じだった気がするがちょっと自信無い。またR6RSやR7RSでは違うのかもしれない）。一方、Luaにおいてはテーブルがプリミティブとして存在するのだから、フラットなテーブルを受け渡すと都合が良い。そしてこのテーブルがenvironmentと呼ばれると考えられる。

リフレクションに使えそうな関数は何をしている

単なる再帰によるインタプリタなり、VMなり、コンパイルされた機械語の実行なり、どのような実行形式においても変数を保持しておくためのデータ構造は必要である。概念的なレベルで良いのでこのデータ構造を考えると、Luaのデバッグライブラリの機能はすんなりと腑に落ちる。

関数が定義するローカル変数は、各変数ごとにスタックフレーム中でのオフセットを表す数値が割り当てられ、関数が呼び出された際のスタックフレームに保持される。また、関数を実行する際に外側のブロックで定義されているローカル変数にアクセスすることを考えると、現在実行している関数が外側のブロックから抜け出していないなら、スタックを字句的なネストから決まる数だけ上に辿ってアクセスすれば済む。一方、局所関数の定義がブロックの外側に抜け出すならば、変数が保持されていたスタックフレームは存在しないので、クロージャ変換を行い自由変数を捕獲しておくことになる。

デバッグライブラリは、まさにこのスタックフレームやクロージャに対して、何らかの操作を行う関数群を定義している。

`debug.getlocal([thread, ]level, local) / debug.setlocal([thread, ]level, local, value)`

スタックをlevelだけ上に辿った場所にある、local番目のローカル変数を操作する。なおgetlocalは変数の名前と値を組にして返す（これを使って、特定の名前を持つローカル変数を探すことができる）。ここで、末尾呼び出し最適化が為されるとスタックフレームが消えるので場合によっては注意が必要。カッコの有無によって末尾呼び出し最適化が変化するということも起こる。

    local function f(x)
    print(x)
    return x + 42
end
function g(y)
    return f(y)
end
function h(y)
    (return f(y))
end

  

としてf,g,hを定義すると、g内でのfの呼び出しは末尾呼び出しの最適化の対象となり、h内でのfの呼び出しは末尾呼び出しの最適化にならない（C LuaでもLuaJでも同様の挙動だったが、これがバージョンごとに変化することの無い挙動なのかは不明）。

`debug.getupvalue(f, n) / debug.setupvalue(f, n, value)`

クロージャfに捕獲されたn番目の自由変数を操作する。普通の変数代入と同じように動作する。

`debug.upvalueid(f, n) / debug.upvaluejoin(f1, n1, f2, n2)`

Luaでは変数に再代入することが可能であり、またクロージャに捕獲された自由変数への再代入は、同じ変数を捕獲している別のクロージャにも影響する。よって、一般的に参照を介して自由変数を保持していると言える。

upvalueidは、クロージャfに捕獲されたn番目の自由変数を保持する参照を一意に区別する識別子を返す。upvaluejoinは、f1内のn1番目の自由変数を保持する参照を、f2内のn2番目の自由変数を保持する参照と同じものに置き換える。ここで行うのは単なる変数への代入ではなく、参照自体の置き換えである。