本の虫: 2014/05

2014-05-29

表計算をマジなことに使わないほうがいいよ（マジで）

You shouldn’t use a spreadsheet for important work (I mean it)

経済学者はうらやましいね。コンピューター科学者とは違って、革新的な研究で、ベストセラー本をだせるときている。たとえば、 Capital in the Twenty-First Centuryだ。この本はマルクス経済を再認識させる本だ。本を読んでいない人のために要約すると、資本の増加は賃金の増加よりも高いので、資本を持つ者はますます富み、ますます強大になる。大多数は貧する。少数のエリート達が、富のすべてをかき集める。一般人には富は残らない。この見方は、彼の専売特許ではない。富の集中という概念には、富める者はますます富み、貧するものはますます貧すというキャッチフレーズまである。

同じ主張をするものはいくらでもいる。しかし、証明するのは難しいし、一部の経済学者は、反証すら見つけている（Wojciech Kopczuk and Allison Schrager | The Inequality Illusion | Foreign Affairs）。今日、高額な遺産相続によって大金持ちのリストに乗るのは、1970年より難しい（更に詳しくは、Women, Wealth and Mobility, Earnings Inequality and Mobility in the United States: Evidence from Social Security Data Since 1937, Top Wealth Shares in the United States: 1916-2000: Evidence from Estate Tax Returnsを参照）

Pikettyの研究で興味深いのは、彼は自分の主張の裏付けとして、膨大なデータと解析を元にしていることだ。残念ながら、実に多くの人間がそうするように、Pikettyはまともなソフトウェアを書く代わりに、表計算を使った。高評価できる点としては、彼はコードを公開した。低評価としては、Pikettyのコードには誤りがあったということだ。

表計算には、オリジナルのソースの打ち込み間違いや、間違った数式が使われていた。中略。ファイナンシャル・タイムズが修正したところ、ヨーロッパの数字は、1970年以降、資産の不公平な増加傾向は見られなかった。外部の専門家も、ファイナンシャル・タイムズと同じ懸念を表明している（ファイナンシャル・タイムズ、2014-05-23）

その結果として出たのは、中略、他のデータからの解析結果でも、新しいデータによる数字の更新でもなく、泥水で滑ることで、人為的な傾向が、潤滑油により「滑らか」に修正され、中略、その結果は、解析に申告な問題があるにも関わらず、主要な学術誌によって印刷された（Phillip W. Magness » Piketty Tricketty & Historical US Wealth Data）

驚きはしない。去年、筆者はReinhart-Rogoffの事例を検証した。二人の著名な経済学者は、過去のデータに基づく複雑な統計解析に基づき、多額の負債は経済発展率の低下につながると結論づけた。残念ながら、彼らも表計算を使ってしまったのだった。

だいたい、表計算というものは手早いやっつけ仕事には向いているものの、真面目で重要な作業には向いていないのだ。

まともなソフトウェアには詳細なテストが付随するべきである。テストなしで、どうして自分の書いた機能が、自分が意図する通り正しく動作すると言えるのだ？　表計算は、テストをサポートしていない

表計算は、コードレビューを困難にする。コードは何十、何百もの小さなセルの中に散らばっている。コードを自分で注意深く検証できず、また他人による検証も難しい状況で、どうして信頼できようか？

表計算はコピペプログラミングとやっつけ仕事を自然と行わせてしまう。コードの検証、テスト、保守を難しくする。

筆者は、生徒の成績処理とか、退職後の貯金推定とか、去年支払った税金の計算などの作業には、表計算で満足だ。しかし、筆者は、銀行運営とかスペースシャトルの軌道計算に、Microsoft Excelは絶対に使わない。表計算はお手軽だが、間違いやすい。表計算は、間違いがそれほど問題にならないか、問題が簡単な場合にのみ適しているのだ。Pikettyは複雑な処理を行っていたし、彼のキャリアの進展は、結果の正確性にかかっていたようだ。

ReinhartとRogoffのように、Pikettyは問題があることを否定しなかった。しかし（ReinhartとRogoffのように）、彼は自身の誤りは些細なものであり結論に影響するものではないと主張した。

反論に対する第一声で、Pikettyは相手に証明を押し付けた。「もちろん、ファイナンシャル・タイムズの統計と資産ランキングが逆の結果を出したのならば、私としてもその統計を検証するし、もちろん結論を変えるよ」と

Pikettyは問題を正しく認識していない。正しい答えがでることだけでは十分ではないのだ。バグだらけのソフトウェアを搭載した飛行機に乗りたいと思うかね。プログラマーはバグが飛行に影響するものではないと主張しているとしてもだ。そりゃ、飛行機は安全に着地するかもしれん。だが、それは単に運がよかっただけであるかもしれんだろう？

Pikettyは、自分はコードを公開したという事実を強調するという点でも、問題を認識していない。そりゃ、解析に悪意があったわけではなかろう。だが、正しいとも限らん。

人は間違いを犯すものだ。表計算にしろ何らかのアプリにしろ、何かソフトウェアをリリースしたとしたら、確実に何らかのバグが含まれているのだ。どうしようもない。しかし、バグを防ぎ、見つけ、悪影響の範囲を制限するために努力したはずだ。筆者は毎日プログラミングする。少なくとも、筆者のプログラミング時間の半分は、バグを探すことに費やされている。Pikettyは、Reinharは、Rogoffは、一体どれだけ解析結果の精度の検証をしたというのだ？　彼らが表計算を用いたという事実が、精度にそれほど気を使っていなかったという事実を如実に物語っている。そりゃ、優秀な外科医は、タキシードを着たままキッチンナイフで腫瘍切除ができるかもしれん。しかし、いったい手術が正しく行われるという自信はいかほどか。データ解析に基づいて600ページもの本を書くのであれば、何ヶ月もの間、解析の検証、テスト、ドキュメント化に費やすべきだ。

これがPikettyのキャリアのどれだけ影響を与えるのか、興味深いことではある。先週、何十人もの経済学者が、Pikettyはノーベル賞確実だと話すのを聞いた。果たして今もノーベル賞を取れるのか？　解析がどれだけ間違っていたのかと、論文にある解析の品質によるだろうとしか言えん。

Pikettyは、経済学者としては膨大なデータを扱った。思うに、経済学者もこれからは複雑で莫大なデータを扱わなければならなくなる。より一層複雑な解析が必要となる。彼らがまともなツールと技術を使うことを覚えるといいのだがな。

参考文献：

Piketty’s Data Is Full of Errors (Slate)

Did Piketty Get His Math Wrong? (New York Times)

Thomas Piketty’s Inequality Data Contains ‘Unexplained’ Errors (Huffington Post)

Are there major mistakes in the bombshell economics book of the year? (Quarz)

追記：Richard Tolも、最近間違ったデータ解析のしっぽを掴まれた経済学者の一人だ。彼もまた、Excelを使っていた。

追記2：経済学者がExcelを使うというのがどれほど一般的なのか、筆者は知らない。そんなに一般的ではないのかも知れない。経済学者のSergio Salgadoは書いている。「まともな統計解析は、STATAかSASか、まあ、最低でもRかFORTRANを使うものだ。Excelなんて使う奴はいない」と。

ドワンゴ広告

ドワンゴ社内のデータマイニングに使われているツールについて、筆者は詳しく知らない。本人が最も使いやすいと思うツールを使えばいいのではないかと思う。ドワンゴでは、優秀なデータマイニングのエンジニアは大歓迎であると聞いているし、実際に中途の採用募集もしているようだ。本物のデータマイニングエンジニアは、本物C++プログラマーより希少かもしれない。

ドワンゴは本物のC++プログラマーも募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-28

妖怪ハウスの環境をさらに改善した

野方にある筆者の住むシェアハウス、妖怪ハウスは、問題を抱えていた。冷蔵庫が小さすぎることと、洗濯機が貧弱すぎることである。

いま、妖怪ハウスには、定期的に料理をする人間が増えている。しかし、冷蔵庫は小さすぎる。大きな冷蔵庫が必要だが、あまりにも高すぎる。

また、洗濯機も甚だ古臭く、汚く、動作も怪しいものであった。

今日、別の用事で高円寺を歩いていた筆者は、中古の大きな冷蔵庫を見つけた。この大きさの冷蔵庫は、中古でも相当高いのだが、なぜか4万円だった。みると、表面に傷がついている。機能的には問題がないそうだ。大きな冷蔵庫は、すぐに売れてしまうので、何日も迷うことはできぬ。思い切って買ってしまうことにした。

また、これから梅雨になるので、洗濯物を乾かすのが不便になるだろう。たまに晴れた日に洗濯が集中してしまう。乾燥機付きの洗濯機が欲しい。2万3千円で、温風による乾燥機付きの洗濯機が売られていたので、財布に痛かったが、冷蔵庫と一緒に運んでもらえば輸送と設置費用が安くなるので、購入した。

かくして、妖怪ハウスにはまともな冷蔵庫とまともな洗濯機が、明日やってくる予定だ。

また、ふとん屋でマットレスを買った。これで、筆者が夜寝ている妖怪テントの床を、マットレスで敷き詰めることができる。テントであれば、銀マットのようなものの方が雰囲気がでるかもしれないが、あれは性能が甚だ貧弱である。同じ値段で、もっとまともなマットレスが買えるのであれば、マットレスのほうが良い。

さて、妖怪テントの床をマットレスで敷き詰めたことにより、居心地は良くなった。しかし、これから蒸し暑くなってくるであろうし、布のマットレスは肌触りが悪い。ゴザを買って来るべきだろうか。

そして、真夏の暑さを妖怪テントで乗り切る方法について、いまだに解決方法が見つからないでいる。やはり、小型のクーラーを設置するのが一番だろうか。

ちなみに、妖怪テントの防水対策であるが、一切行わないことにした。テントは20分もあれば設置撤収できる。雨が降る時は片付ければよいのだ。

2014-05-27

Boost勉強会 #15 札幌に参加した

Boost.勉強会 #15 札幌が、下記のとおり行われた。

Boost.勉強会 #15 札幌 - boostjp

Boost.勉強会 #15 札幌 : ATND

5月22日

「あたし、ガールズバーのホームページ作ってるんだよね」と、三十路過ぎの女が言った。「とにかく、可愛い女の子がいっぱいいますってことにしなくちゃいけなくて、本当大変」

「悲惨だな」と筆者は答えた。悲惨としか言いようがない。「そもそも、何故人と話すのに金を払わねばならないのだ。今、私がここでお前に金を払って、会話してくれと頼むのは、おかしいだろう」

「でも、あたしみたいな三十路過ぎの女じゃなくて、二十代だし」

謎だ。筆者には、女の魅力というものを、世間一般が評価するように、正しく評価できない。人の魅力の評価というのは、筆者に欠如した能力であるらしいのだ。この三十路過ぎの女は、その年齢と、そして鍛えていない肥満した体躯から考えれば、世間一般には、魅力のない方に分類されるのであろう。しかし、誰だって20年もたてば、魅力のないオッサン、オバハンに成り下がるのだ。ことに、体を鍛えていない人間の、加齢による魅力の低下は悲惨だ。ガールズバーで働いているような女は、真面目に体を鍛えていないであろうし、不健康、不衛生な生活習慣であることが多いであろうから[要出典]、10年後は、目の前にいるような肥満した三十路女に成り下がるのであろう。

そもそも、なぜ会話するのに金を払わなければならないのか。なるほど、もし相手が医者であるとか弁護士であるとか、何らかの専門知識を持っていて、その専門知識を元に判断を下してもらいたいときは、金を払うのは道理だ。しかし、筆者の聞くガールズバーというところは、そういう専門知識を乞う場所ではない。

相当に有能な話し手、あるいは話の聞き手であれば、金を払う価値があるかも知れぬ。

筆者は、並み居る聴衆を相手に、昼寝をさせずに何時間も講演ができる人物に会ったことがある。話の内容は、無価値である。本当に何の価値もない話である。そんな無価値な話だけで、何時間も聴衆を飽きさせずに話ができる人間なのだ。講演の最中、筆者は講演者に対して恐怖を覚えた。この能力を使えば、詐欺師や宗教開祖になれるであろう。

有能な話の聞き手にも、筆者は会ったことがある。適切な頷きや相槌、次の話題を促すための答えやすい狭い質問。このような人物と話すと、自分が極めて有能な話し手になったかのように錯覚する。有能な話の聞き手も、また危険な人間である。

なるほど、能力を年齢から判断するべきではない。経験は当てにならぬ。しかし、若い女ばかりの偏った集団に、そのような有能な、金を払う価値のあるほどの会話の達人ばかりがいるというのは、どうにも考えにくい話だ。

単に人と世間話がしたければ、話せばいいのだ。そこに金銭が介在する必要はない。

「でもねー、江添さん、世の中江添さんみたいな強い人間ばかりじゃないんだよ。お金を払わないと女の子とお話できない寂しい四十代、五十代のオジサン達がいるんだよ」

これはかつて、ガールズバーで働いているある若い女に対して、その存在意義を問うた時、返ってきた答えだ。筆者は金を払ってこの女と会話したのではない。この女は、およそ、若いことと、肥満していない体型と、服装と、化粧により、世間一般的には女としての魅力があるであろうこと以外には、なんの価値も持たぬつまらない人間であった。その価値は単に若いことによって生じているのであって、十年後には価値が極端に下がっていることだろう。悲惨であるが、本人が自らの意思でその境遇に身を置いている以上、どうすることもできぬ。自ら意思を示さぬものは、助けようがない。まあ、意思を示したとしても、筆者にできることはあまりない。悲惨だ。

「いや、本当うちの店は悲惨だよ。コンビニで一本千円ぐらいで売ってる黒霧島とかが、一本一万とかするんだ。コンビニで売ってるポテトチップスとかが、皿にほんのわずかに入って何千円もするんだ。それで、お会計が5万ぐらいになって、そっとお会計を伏せて、申し訳なさそうに持って行って、払ってもらうんだが、なんとこのオッサン、財布に一万円札がぎっしりなんだよ。軽く50万はあった。うわ、このオッサン、持ってるわ。で、このオッサン、一晩5万は必ず使うんだが、それで毎晩うちに来るんだぜ」

昔、ガールズバーで店員として働いていた男から聞いた話だ。金はあるところにはあるようだが、使い方が人として間違っている。

しかし、ガールズバーで働く人間は、その性格上、あまり貯蓄しない。何らかの方法で散財してしまう。したがって、こうして市場に出た金は、すぐに右から左へと流れていく。金は死蔵していては価値がない。動かなければ価値がない。したがって、ガールズバーのような、倫理的に悲惨な、人として間違っているはずの商売は、経済的には最高の存在であることになる。

一体、これは何なのだ。なぜ、明らかに間違っているはずのことが、結果的に、最良の結果を出しているのは、いったいどういうことだ。天地の間には、汝の所謂哲学では夢想だにしないことがあるのだ。

筆者は考えることをやめた。明日は北海道に飛ばなければならないのだ。そう、明日は札幌でBoost勉強会なのだ。

筆者がBoost勉強会 #15 札幌に参加するに至った経緯

ドワンゴに入社した直後、@ignis_fatuusからtweetが来た

@EzoeRyou ご就職おめでとうございます。札幌でBoost勉強会を5月頃にやろうかという話があるのでぜひC++の啓蒙のためにお越しください。
— いぐにすさん @πλασμα (@ignis_fatuus) February 13, 2014

札幌、北海道か。まあ、5月ともなれば給料も出ているだろうし、旅費はあるだろう。

しかし、C++の啓蒙ならば、仕事のうちではないか。

江添「Boost勉強会行きたいんですけど旅費だして」
上司「じゃあ、出張ってことで」
上司「航空券とホテル、手配しといたよ」

名目はドワンゴのC++に対する取り組みを社外に宣伝し、もってドワンゴがC++エンジニアを求めていることを知らしめるためとなった。かくして、筆者はBoost勉強会に参加するために、北海道に飛ぶことになった。

5月23日

さて、Boost勉強会#15札幌は、午前11時という早朝（ドワンゴ基準）から行われるため、前日に現地入りすることにした。東京から北海道へ移動するには、飛行機が最も適切である。列車では、一日がかりな上に、値段も飛行機より高い。ところで、筆者は、今まで飛行機に乗ったことはない。一度も体験したことがないことというのは、緊張する。まあ、何にでも初めてはあるということだ。

どこかの誰かのように、飛行機を乗り過ごす失態をしてはならぬ。筆者は離陸の4時間前に家を出て、三時間前に羽田空港に到着した。

はじめての飛行機は、特に、どうということもなかった。ただし、飛行機ほどの質量を持つ物体が、離陸に際して急激に加速するのには興奮した。飛行機の中で、筆者はカサノヴァ回顧録を読んだ。カサノヴァは、真に自由人として生きた男である。世上には、その女性遍歴が有名であるが、カサノヴァの価値はそこだけではない。実に才気あふれる方法で、幾度も窮地を乗り越えた本物の自由人である。

さて、二時間ほどで、飛行機は無事に、新千歳空港に着陸した。空港から札幌駅まで、電車で一時間、運賃は1070円である。高い。

さて、札幌駅に着いた筆者は、まず明日の勉強会の会場となる北海道大学まで歩いて位置を確認し、しかる後に、今日の宿に向かった。宿はホテル京阪札幌で、部屋には無線LAN、有線LANがあり、快適であった。ただし、筆者の考える本当の面白さは得られない宿であった。筆者は、しっかりとした予定をたてて、そして予定通りの物事が運ぶのを嫌う。それでは面白くない。もし、計画が計画通りに進んだとしたら、それは計画が素晴らしかったということであり、実行は、単なる計画の実証に過ぎない。事前に予期していない状況こそが面白い。もっとも、明日は確実に勉強会に出席しなければならないし、一日集中するために十分な睡眠が必要であることを考えると、今回は冒険できぬ。

冒険は出来ぬと書いたが、まだ午後5時頃である。腹が減っているのを幸い、夕食を認めるために、どこか適当な食べ物店に入るとしよう。どこかうまい店に入るか。あるいは、足のおもむくままにどこかの店に入るか。いずれにしても、日本全国どこにでもあるような系列店はやめておこう。

筆者は、普段は外食をしない。外で食事をする必要に迫られた時も、全国展開しているような店に入る。なぜならば、結局、タバコを吸う忌々しきニコチン中毒者どもを避けて、飲食店の唯一の正しいありかたである禁煙の店を選ぶには、遺憾ながら、全国展開している店を選ぶのが、最も手軽だからだ。そのような飲食店は、完全に平均化されていて、面白さは一切ないが、タバコの害から逃れるためには、致し方ない。

Twitter上で、札幌駅周辺の飲食店のおすすめがないものかどうかつぶやいたところ、地下鉄ですすきのまで行って、だるま本店でジンギスカンを食べるといいという。あるいは、寿司か、ラーメン横丁か。いずれにせよ、すすきのまで出て行くのがおすすめだという。

筆者は歳のためか、あまり肉を好まなくなってしまっている。ただ、せっかく北海道にいるのだし、推奨されたことでもあるので、この機会に、羊肉を食べてみようと思う。

さて、地図で確認すると、札幌駅からすすきのまで、わずかに1.4kmである。この距離は、歩いていける距離である。どうせ今日は寝るだけなので、時間に余裕はある。歩いて行くことにした。

さて、ほどなくすすきのについて、だるま本店に入った。幸い、空いていたし、タバコを吸うろくでなしどもはいなかった。

問題は、ジンギスカン自体が煙たいということだ。狭い店内のカウンターにジンギスカン用の鍋が所狭しと設置され、排気設備は貧弱すぎる。羊肉はまずくはなかったが、筆者としては、ネギのほうがうまかった。年を取ったものだ。

一切おかわりせずにだるま本店を辞した筆者は、次に寿司屋に向かった。聞説、よい寿司は回っていないらしい。筆者の入った寿司屋の寿司は止まって見えた。しかし、だからといって、特にうまいとは思わなかった。まあ、うまいというのは相対的なものだ。筆者がこれまでに体験し得たうまい寿司屋と比べると、大したことはなかった。

寿司はそれほどうまくもなかったが、ひれ酒が飲めたので、よしとした。ひれ酒は筆者の大好物である。日本酒は、あまり真面目に作っている酒蔵がすくなく、ひれ酒のようにして飲まなければ、飲めたものではない。

すすきのは、歓楽街として有名である。聞説、不思議な三助のいる特殊な浴場があるという。もうひとつの肉というわけだ。何も言うまい。ガールズバーより、なお悲惨だ。

宿に戻って午後9時に就寝した。筆者は早寝早起きなのだ。

5月24日

午前5時に起きた筆者は、身支度を済ませ、朝食を認めてから、会場となる北海道大学、クラーク会館に向かった。

Boost.勉強会 #15 札幌 - boostjp

高橋晶による、「マルチパラダイムデザイン – 再利用性の高いアプリケーションの設計」

この発表は、筆者の印象にまったく残らなかった。何やらコンサルの話しそうなことを話していた気がする。

西山信行 (5mingame2)による、「iPhoneアプリ『ういろう』のboost以外成分」

この発表者と申すは、お立ち会いの中にご存知の方もござりましょうが、不自由なiPhone用の不自由なゲーム、「ういろう」の開発者にござる。ギターを抱えて登壇し、「聖地サッポロー」と叫びつつ、始終浮かれて発表ありし故、さだめて由あるべしと不審あり。

さてこのゲーム、テキストを画面外からささっと動かして、所定の位置に配置すれども、テキストの移動速度が線形なる時は、あまりにも無味乾燥として興ざめなればとて、ai/easings.netなるライブラリを用いて、非線形にふわっと動かすことこれあり。いや、細かいようなれども、かかる配慮のあるときは、人の目は楽しむものなり。

また、一枚絵をういろうのごとくぷよ感をだして振るわせるための計算に、バネの減衰運動の数式を用いているよし、承り候。さては、ギターをかきならせしは、さだめて弦の振動との関連なるべし。

なお、札幌が聖地なる故は、かのボーカロイドの販売買社、クリプトン・フューチャー・メディアの本社が札幌にあるためなりとす。

ほっと (hotwatermorning)による、「C++ Windows GUI ライブラリ「balor」の紹介」

不自由なWindowsのWin32 APIのみを考えた移植の難しい薄いGUIラッパー。読者は使うべきではない。以上。

でちまるさん（実際かわいい） (decimalbloat)による、「二分探索法」

忌まわしき太古の技術であるCプリプロセッサーを用いたプリプロセス時プログラミング技法の実装方法の紹介。

Cプリプロセッサーは、トークン列に対する置換のためのマクロであり、プログラミング言語ではない。たとえば、再帰をサポートしていない。Cプリプロセッサーメタプログラミングでは、実用的な回数のループを実現するために、大量のマクロを定義して、文字列連結した結果をさらにマクロ展開させることにより、ループのようなものを実現している。その時、手動展開されたバイナリサーチを用いて、目的のマクロに一致させているという。そういう技法を紹介する発表であった。

これはぜひとも、いずれドワンゴでも勉強会を開いて、発表してもらわねばなるまい。

にゃははー (Flast_RO)による、「オーブンレンジ2014夏モデル」

この発表における筆者の関心ごとは、lambda-captureを持たないlambda式から生成されたクロージャーオブジェクトは、default-constructibleでもcopy-assignableでもないということだ。なぜこのような制約があるのだろうか。すでに、そのようなクロージャーオブジェクトは、関数ポインターへの変換関数を提供している。

template < typename Func >
void f( Func func )
{
    Func f ; // default construct
    f = func ; // copy assignment
    f() ;
}

int main()
{
    auto a = [](){ } ; // closure object
    void (*b)() = a ; // function pointer
    f( a ) ; // Error
    f( b ) ; // OK
}

上記の例で分かるように、キャプチャーしないラムダ式のクロージャーオブジェクトは、default constructibleかつcopy assignableであってもいいように思われる。なぜこのような無意味な制約があるのか。

当時の議論を思い返しても、このような制約が着いた理由は思い当たらない。ただ、関数ポインターへの変換関数は、C++11規格制定の直前になって認められた機能であるので、特に強い制限緩和要求がなかった以上、そのまま捨て置かれたのではなかろうか。

将来的に制限緩和できるかも知れないが、どうだろうか。

池田公平 (hgodai)による「vectorの逆襲」

vectorは遅い。遅い理由は、C++のアロケーターがreallocをサポートしていないためである。ストレージ領域をそのまま引き伸ばせる状況では、コピーを回避することができる。reallocが必要だ。そのために、Boostのvectorやアロケーターでは、reallocに対応した設計と実装を行っているという。

江添亮 (EzoeRyou)による、「スタックからのメモリ確保の標準化」

実にいい並び順で、筆者の番になったものだ。前野発表は、ヒープからのメモリ確保のrealloc、これは、スタックからの動的なメモリ確保のreallocである。

極めて短時間だけメモリを確保したい場合、スタックからメモリを確保するのは、様々な利点がある。問題は、スタックから動的にメモリを確保するのは、今のC++では難しい。Cから受け継いだallocaは昔からあるが、型安全ではない。

C++14には、実行時サイズ配列と、std::dynarrayが入る予定であった。しかし、色々と問題が会ったため、スイスのNBコメントにより、TSに移動した。

この巻き添えで、std::optionalもTS行きになった。筆者はコア言語が専門であり、ライブラリの事情はあまり追っていない。幸い、ライブラリに詳しい高橋晶氏がその場にいたため、std::optionalの問題を聞いてみた。問題は、標準化委員会内で、比較関数の実装方法の合意が取れなかったためだという。なるほど、標準化委員会内で合意の取れないような機能は、野に解き放ってはいけないのだ。標準化委員ですら納得させられずに意見の分断を引き起こすような機能は、一般のC++ユーザーにとって、極めて使いづらい難解な機能になる。exportしかり、コンセプトしかり。賢明な判断だ。

実行時サイズ配列の問題は、クラスによるabstractionができないということだ。また、クラスのデータメンバーに実行時サイズ配列を認める提案を採択したとしても、そのクラスは自動ストレージ上にしか構築できない制約を受ける。これは、C++では、型はどのようなストレージ上にも構築できるという大前提を崩壊させる、例外的なルールを導入することになる。

std::dynarrayはスタックから確保できない文脈では、自動的に動的ストレージからの確保にフォールバックする。これは、ほとんどのC++ユーザーが求めている挙動ではない。それに、C++では、デストラクターを明示的に呼び出して、生のストレージ上にオブジェクトを構築できる。std::dynarrayでは、スタックから確保するという特性上、これができない。これも、C++の大前提を崩壊させる。

この問題を解決するには、ネストしたスタックからのストレージ確保方法を、標準化しなければならない。これはまだ、具体的な提案はなされていない。まだまだ議論しなければならない状況だ。

そして最後に、ドワンゴの宣伝を行った。

筆者が勉強会に参加し、何かC++について発表するということは、ドワンゴのC++に対する取り組みを宣伝するよい方法である。ただ愚直に、「ドワンゴは優秀なエンジニアを求人中です」などと叫ぶより、よほど効果的であるはずだ。

そのため、もし各地で開かれる勉強会で、筆者がC++について何か発表して欲しい場合、呼んでもらえれば、宣伝として行くことができる。ぜひ呼んでもらいたい。

また、筆者は常々、ドワンゴは本物のC++プログラマーを募集しているが、「本物」の定義を教えてもらいたいという質問が出た。「本物」という語は、「本物のプログラマーはPascalを使わない」という、有名な文章のタイトルから来ている。

人の能力の評価は難しいが、すでにドワンゴで働いているC++プログラマーについて書いておこう。ドワンゴ社員のC++プログラマーは、仕事でC++を書くにあたって、筆者を必要としない。

これは当然の話だ。一般的なプログラマーが、C++を書くにあたって、規格の詳細な知識を求められるとしたら、それは規格の敗北である。多くのプログラマは言語を表面的な理解だけで使っている。それでいいのだ。

それにドワンゴ社員は、必要であれば、C++規格書や提案論文ぐらい読める。彼らが普段読まないのは、純粋な規格の文面解釈と格闘するよりも、具体的に動くコードを相手に格闘したいからだ。筆者は、今C++に提案されている新機能について、社内の現場のエンジニアの意見を求めるために、紹介している。しかし、筆者の紹介する提案は、何の変更もなく今の提案のまま採択されたとしても、正式に規格として発行され、主要なコンパイラーで実装され、現場で使えるのは、早くて10年後というものばかりだ。今の仕事には役に立たない。もちろん、技術者は常に学び続けなければならぬとはいえ、筆者の紹介する機能は、あまりにも遠い未来の話だ。表面的な理解であれば、実際に使えるようになってから学んでも遅くはない。プログラミングを学ぶ方法がわからないと書いたのは、自ら学べなければ、本物のプログラマーとはなれないからである。

そして、筆者は規格と格闘して、現実の問題に対処する、泥臭くも動くコードは書いていない。筆者は本物のC++プログラマーとは名乗れないであろう。この事実は筆者の自尊心を傷つける。しかし、誰かが規格を解釈して、日本語で解説しなければならないにもかかわらず、誰もやっていない。皆、動くコードが書きたいとみえる。当然だ。誰もやっていない以上、幸いに文章読解に快感を覚える筆者のような本物ではないC++プログラマーがやるしかないのだ。

懇親会

今回の勉強会では、様々な分野の人間と話をした。特に、ういろう作者の西山氏は、専門学校の講師でもあるらしく、これはいい機会と、プログラミングを学ぶ方法がわからないで提示した、プログラミング以前の基礎的なコンピューターの操作方法から教えてもらいたい初学者の存在問題について聞いてみた。

西山氏は、この違和感を質問者本人に納得させるため、以下のたとえを使っているという。

「ディズニーランドへの行き方を他人に聞くか？　お前がどこに住んでいるかによって、行き方は異なるではないか。お前の状況によって異なる答えを、なぜ他人に聞くのだ。電車の乗り換えは、今は便利な検索サービスが存在する。なぜ自分で探さないのか」

この諭し方により、ハッとする人もいたという。

技術以外の話もした。

ドワンゴに入社する前、筆者に対して、「カネは人を自由にする」と主張した男がいた。曰く、「金は選択肢を増やし、自由度を高める」と。

筆者はこの意見に反対の立場である。カネは単に利便性を上げるだけで、自由とは違うのだ。選択肢が増えたからと言って、自由であるとは限らない。カネがあると物事がやりやすくなるだけだ。この勉強会に参加できるのも、つまりは利便性の向上だ。自由と利便性を混同してはならない。

この勉強会には、四十路を超えてなお現役でコードを書いている本物の男がいた。酒の席で、四十路男は、妻子を持っているために若い時ほどプログラミングに自分の時間を避けないことを語っていた。しかし、四十路男の顔には後悔の表情は見られなかった。自分の子供は猫よりも可愛いこと、自分は結婚などしないと心に決めていても、どうしても離れられない大切な人は現れるものだということを、この四十路男は語っていた。いずれも、筆者の理解の範疇を超える話であった。

なぜ、このような話が身の回りに起こるのであろうか。結局、筆者とても、いつの間にか、いい年齢に達しているためであろうか。そして、もし身を固めるのであれば、そろそろ身を固めておかなければ、統計的に取り返しのつかない年齢に近づきつつあることも事実だ。

はて、統計的には、歳を取るほど結婚は難しくなる事実はありながら、理論的には、違和感がある。というのも、三十すぎのオッサンやオバハンが、二十歳の青年や小娘と結婚すると、周囲からは奇異の目で見られるであろうが、五十歳と四十歳の結婚は、特に周囲から奇異の目で見られない。しかし、年齢差は、どちらも10年である。つまり、歳を取るほど、交際可能な年齢幅が広がり、交際可能人数も増えるのだ。

xkcd: Dating Pools

女「ああ、やだやだ。初婚年齢の中央値は26よ。独身は減っていくばかり。もう時間がないわ」
男「いや、実際のとこは違うね」

男「確かに、年齢の高い独身者はより希少ではある。しかし、歳を取るにつれ、交際可能な年齢幅は広くなる。18歳の年齢幅は16歳から22歳であるが、30歳の年齢幅は22歳から46歳ぐらいだろう」
男「標準奇異ルール：デートする年齢下限\(\left(\frac{AGE}{2} + 7\right)\)」

男「先週、ちょうど国勢調査の数字に対して解析したところなんだ。交際可能人数は、実際には中年まで増えていくんだよ。だから、そう、気をやむことはないよ！」

女「あなたの解析とやらは、週末をグラフ作って過ごす人の交際見込みについては、何か分かるの？」
男「おいおい、よしてくれよ。ベル・カーブの端っこには、僕に合う女の子だっているはずさ」

「ベル・カーブの端っこには、僕に合う女の子だっているはずさ」というセリフは、オタクぶるために使える便利なセリフだ。

筆者のような人間には、平均から相当離れた端の端を探さなければならないだろう。探す気が出ればの話だが。

さて、懇親会はすでに三次会となり、場所をカラオケ屋に移動した。筆者は、カラオケの喧騒が苦手であるし、なにより、部屋がタバコ臭いし、眠くもあるので、途中で辞して、宿に帰った。

5月25日

飛行機で帰宅した。おみやげに定番の白い恋人、白いバウムを買った。また、イカの塩辛、松前漬け、鮭のルイベ漬け（鮭とイクラの醤油漬け）、ジンギスカン用の味付きの羊肉を買って帰った。

その日の妖怪ハウスはオッサンばかりが集まっていたので、巨大なホットプレートに羊肉と野菜をぶち込んでジンギスカンを作った。うまかった。料理はやはり、こうでなくてはならぬ。行列をなす店やお高い店に独りでいっても、本当にうまいものは食べられない。

また、羊肉というのは、そんなにいいものを使わなくてもよいらしい。冷凍の形成羊肉で十分にうまいらしい。今度、妖怪ハウスで盛大に作ってみようと思う。

ドワンゴ広告

この記事は、もちろんドワンゴ勤務中に書かれた。

Boost勉強会でだいぶ宣伝したので、今回は宣伝を控えめにする。どうしてもドワンゴ広告が読みたくてならぬという奇特な人間は、当日私が使ったスライドを読むといい。

Boost勉強会で使ったドワンゴ広告スライド

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-22

プログラミングを学ぶ方法がわからない

最近、プログラミングをどうやって学べばいいのかわからなくなってしまった。

筆者はドワンゴに雇われている。ドワンゴに入社して早4ヶ月になろうとしている。ドワンゴに雇われている名目は、C++の啓蒙である。C++の啓蒙にはC++の教育も含まれる。したがって、筆者はそろそろC++の教育をしなければならない。

筆者は、プログラミングを教育する最良の方法は、参考書を執筆することだと考えている。直接対面して教えるのは非効率的だ。文章を書いておけば、大勢が学べる。では、どのような参考書を執筆すればいいのか。すでにC++11のコア言語の参考書は書いた。

EzoeRyou/cpp-book

C++14対応も、正式なC++14規格制定後に行わなければならない。そしてライブラリは、もし他にやる人がいないのであれば、やらなければならないだろう。

しかし、これらの本は、C++をこれから学び始める人向けではない。C++を学び始める人向けの入門書も、そろそろ考えなければならない。

東京に来て数カ月、筆者に対して、C++を学びたいと直接告げてくる人が何人もいた。興味深いことに、私に直接会ってC++を学びたいと告げた人たちには、共通の要望があったのである。

その要望とは、コンピューターの基礎的な操作方法から教えてほしいというものである。ターミナルやBashのようなシェルの使い方、基本的なCLIコマンド、GCCやClangなどのC++コンパイラーでソースコードをコンパイルする方法、Makeなどのビルドシステムの使い方、はては、ソースコードであるテキストファイルをテキストエディターで編集する方法にまで及ぶ。これはC++以前の話だ。

不思議だ。何故こういった、プログラミング以前の基礎的なコンピューターの操作方法から学びたがるのだろうか。筆者は、このような基礎的なツールの操作方法で苦労した覚えがない。かといって、筆者は基礎的なツールの操作方法の達人ではない。ただ、必要な箇所だけ、その都度調べて使っているだけだ。したがって、筆者はこのような基礎的な操作方法について、教育できるほどの上級者ではない。

なぜ、彼らは、こういった基礎的な操作方法の教育を必要としているのだろうか。すでに、これらの基礎的なツールの操作方法のドキュメントは、いくらでもネット上に文章として存在する。筆者よりもはるかに、それぞれのツールの上級者によって書かれた文章が存在する。いまさら筆者が中途半端な知識で解説する必要はないと思われるのだが、いったいどういうことだろう。

筆者は長い間、不自由なMicrosoft Windowsユーザーであったが、2年前、GNU/Linuxに転向した。それまでVisual StudioというIDEがあり、テキストエディター、ビルドシステム、C++コンパイラーの操作が、マウスだけで行える環境から、CLIのC++コンパイラー、GNU Make, Vimの環境に移った。操作方法が完全に変わったが、しかし、それほど苦労はしなかった。もちろん、まだGNU Makeの機能をすべて把握しているわけではないし、Vimを上級者のように使いこなせてはいないが、特に操作方法に苦労はしていない。いずれも有名なツールのみを使っているので、わからない操作方法は、調べればすぐに分かる。誰かがすでに同じ問題にぶちあたって、解決方法をドキュメント化しているからだ。

かつて筆者が、15年前、2年前に、それぞれ乗り越えていったはずのプログラミング以前の基礎的なツールの学び方を、筆者は覚えていない。それほど苦労した覚えがない。

しかし、現実にC++を学びたいと望むものは、C++以前の、基礎的なツールの使い方から教育されたいと願っている。自分で調べればすぐに分かることを、教えて欲しいらしい。

これはいったいどうしたものか。このような基礎的なツールの操作方法を自力で調べられない者は、後々も必要な情報を自分で調べられないであろうから、本物のC++プログラマーとはなれないであろうと、切り捨てるのは簡単だ。しかし、それでいいのだろうか。

ある同僚が言うには、この手の人は、最小限の労力で目的を達成する方法を求めているのだという。C++でプログラミングをするという目的はあるが、そのために費やす労力は最小限にしたいという。

しかし、この手の基礎的なツールの操作方法というのは、いくら学んでも損はしないのだ。たしかに、Bashの大部分の機能は、C++プログラミングをする上では、直接役には立たない。GCCの全オプションを覚える必要はない。今や、Makefileは自動的に生成する時代だ。ユーザースペースのコードを書く上で、カーネルの知識が直接に役立つことはない。しかし、基礎的なツールをひと通り触っていれば、いつか役に立つ機会があるかも知れないのだ。以外なことに、思いもしなかった知識が、後々になって役に立つものである。

「学問に王道はない」とはよく言ったものだ。

理想はともかく、全くの初心者には、おそらく足がかりが必要なのだろう。そういう基礎的なツールの使い方を触りつつC++を始めるまでの段階を解説した、入門書を書くべきであろうか。第一章、GNU/Linuxのインストール方法、第二章、パッケージマネージャーでC++コンパイラーをインストールする方法、などなど。

とにかく、なにかやるとしよう。

せっかく、100人入るセミナールームが使えるようになったのだから、勉強会も積極的に開催していきたい。

ドワンゴ広告

筆者はドワンゴに雇われている。ドワンゴに雇われている名目に、ドワンゴの宣伝がある。宣伝をしてほしいとは言われたが、どのように宣伝せよ、とは言われていない。そこで、筆者は自分が正しいと信じる方法で宣伝をしている。

そもそも、広告とは、本来必要のないものである。ドワンゴが優秀なエンジニアを求人しているのは、いまさら言うまでもない。ドワンゴに限らず、まともな企業ならば、優秀なエンジニアは常時喉から手が出るほど欲しいに決まっている。広告など、いまさら行うまでもないのだ。

そして、広告というのは、極めて邪魔なものである。もし広告が邪魔だと感じられてしまうようであれば、それは広告としての機能を果たしていない。むしろ逆効果である。即座にadblockのフィルター行きになることは確実である。特に、優秀なエンジニアであれば、adblockは当然使っているであろうから、なおさらだ。現に筆者は、自分のブログの広告をadblockで消している（ドワンゴ広告は消していない）。読者も当然消すべきである。

そのため、筆者は、消さずとも許容できる広告を書くことにした。許容できるとはいったいどういうことか。他ならぬ筆者がadblockで消すほど邪魔でもないと感じるのであれば、あるいは、読者も許容できるかも知れない。

矛盾するようだが、筆者にとって許容できる広告は、adblockで消せる広告である。広告は広告であるとマークアップで意味付けするべきである、もし、広告がCSSセレクターで指定しにくいマークアップであれば、許容できない。そのような広告を使うWebページ自体が許容できない。

したがって、このドワンゴ広告は、adblockのようなユーザー指定のCSSで消しやすいマークアップをしている。

これにより、広告が邪魔だと感じられるようであれば、即座に消されてしまうわけだ。広告が邪魔だと感じられないような努力を強いられる。

もし、読者がこのドワンゴ広告を邪魔だと感じているが、消す方法が分からず、消し方を調べようともしない場合、残念ながら、読者は本物のエンジニアではないと言わざるを得ない。

ドワンゴは本物のエンジニアを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-21

Matthew Garrett、開発者にMacユーザーが多いことについて語る

mjg59 | The desktop and the developer

Matthew GarrettがGNU/Linux上で動くソフトウェアの開発者であっても、不自由なOSであるMacユーザーが多いことについて記事を書いている。

Matthew Garrettは、今や開発者の作業環境は、ターミナルとWebブラウザーなので、作業環境という点で、GNU/LinuxがプロプライエタリなMacに対して十分な利点を提供できていないとしている。

開発には、単にコードを書く以外の作業も多い。Webブラウザーで複数のWebサービス間を行き来して情報をコピペしたりするのは、極めて非効率的であるし、開発者の好む作業ではない。とはいえ、開発者がやらなければならない作業であることには変わりない。

このため、デスクトップ環境に、一般的な開発ワークフローを支援する組み込み機能を増やすなどして、GNU/Linuxを、開発者にとって魅力的な環境にする必要があると主張している。

今週、OpenStack Summitに参加した。OpenStackの主要デプロイ先はLinuxベースであるにもかかわらず、カンファレンスにおける主要なラップトップベンダーは、Appleであった。参加者は、Linuxにデプロイするためにコードを書いているにも関わらず、コーディングは全く別のOSで行っているわけだ。

興味深いのは、Macユーザーが作業に使っているツールだ。肩越しに覗きこんでみると、ターミナルとWebブラウザーが見える。開発者がMacを使っているのは、Macでしか動かないツールがあるからではない。Macを使っているのは、他の理由だ。デザインがかっこいいOSであるとか、iTunesだとか、市場最高品質のトラックパッドハードウェアとそのドライバーだとかだ。彼らは、家と仕事とで、同じラップトップを使っているのだ。通勤途中にも、動画を再生するだとか、仕事をさっさと終わらせて帰るための準備だとかに、このラップトップを使っている。Appleを使う理由は、仕事と趣味とで、別々のハードウェアを使いたくないためである。

私の周りにいた開発者は、10年前のテクニカルカンファレンスにいた連中ではない。彼らはユーザーエクスペリエンスを重視した時代で育った世代であり、より詳細な改造が可能であるという理由でLinuxを選ぶことに価値を見出していない。仕事で自由ソフトウェアを使う（多くの場合、自由ソフトウェアに貢献や保守もしている）人が、自分にとって価値あるものを犠牲にしなければならないという理由で、自由ソフトウェアOSを使っていないのだ。Linuxでも、同じターミナルとWebブラウザーが使えるが、Linuxの貧弱なマルチタッチ処理は、作業の妨げになるのだ。Linuxに移行するのは開発効率が落ちる。

だが、たとえこの問題に対処したとしてもだ、なぜ移行しなければならないのかという疑問がある。我々が提供できる利点としては、同じような操作性に加えて、ソフトウェアの改変が可能な自由だけだ。これは、それほど魅力的な利点ではない。なぜならば、もしそれが魅力的であるならば、単に技術的優位に立つだけで市場シェアを得られるはずだからだ。我々は別の視点から考える必要がある。

開発者のユーザーエクスペリエンスについて議論するとき、Linuxのデスクトップ環境における開発者のユーザーエクスペリエンスについて話が及びがちである。開発にたまたまLinuxを使っている人は話に上がらない。この手の人は、よりよりAPIドキュメントを必要としているわけではない。よりよいIDEを必要としているわけでもない。必要としているのは、毎日使うサービスにアクセスできるためのデスクトップ環境である。現在、もし誰かが、ある開発者に責任があるところのバグを報告したとしたら、その開発者はメールを受け取る。メールをクリックして、バグを確認するWebページを辿らなければならない。もし、そのバグ報告が、すでに別のブランチで修正済みのものであれば、開発者はおそらく、githubに移って問題を修正したバグ番号を見つけだし、またバグトラッカーに戻って、番号をコピペし、重複であるとマークする。面倒で、いやで、気が散る。

もし、デスクトップにバグトラッカーを監視する機能が組み込まれていて、わざわざクリックせずとも、複数の別々のアプリケーションを使わずとも、必要な情報やオプションが表示されるのであればどうだろうか。もし、gitコミットがローカルでインデックスされていて、開発者は関連するコミットを、わざわざWebブラウザーでたどったり、新しいターミナルを開いてローカルのチェックアウトを探さずに済むのであれば、どうだろうか。現在、何度もコンテキストスイッチを行わなければならない、本来は単純な作業が、とても素早く行えるではないか。

これはほんの一例だ。問題はもっと深い。Webサービスを使って開発プロセスの多くの部分を担わせるのは、自前のインフラを保守する必要がなくなる。とはいえ、その過程で、開発者に複数のWebサイトの全く異なるUI間を行ったり来たりさせるし、直接情報を共有する方法がない。時間が浪費される。開発者が不幸になる。

デスクトップを開発することと、開発者のワークフローを最適化することは、Webブラウザーに浪費する時間を少なくし、もっと開発に割く時間が多くなるという保証によって、開発者をOS Xからこちらがわに引き寄せることになるだろう。また、これはLinuxと他のプロプライエタリな代替品との差別化につながる。AppleやMicrosoftは開発者ツールを改良するために多大な労力を割いているかも知れないが、彼らは、単に自社のプラットフォームをターゲットにしている開発者のためにやっているのだ。一般的な開発をやりやすくするデスクトップ環境というのは、彼らにないセールスポイントとなるだろう。

サミットで、筆者はこのことを多くの人に持ちかけてみたが、どうやら同じように考えている人は、すでにいるようで安心した。頼もしいことだが、ユーザーをないがしろにせずに、開発者の作業を簡単にする方法について、もっと関心が集まってほしい。これは、面白い挑戦になりそうだ。

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。

ドワンゴのワークフローは、残念ながらWebブラウザーを多用する。

時に、ドワンゴ社内の新しい支給コンピューターのメモリ容量が、16GBになっている。ようやく3年も前に発売された筆者の化石ラップトップのメモリ容量に追いついたようだ。この現状を批判するために、筆者は早急にメモリを32GB搭載したラップトップを入手する必要に迫られている。それまでは、ドワンゴの支給品は、メモリ容量的には、遺憾ながら十分であると言わざるを得ない。ドワンゴの支給品のディスプレイに関しては、まだ筆者の批判を免れない。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-20

Steve Wozniakによって書かれた浮動小数点数演算ライブラリのソースコード

Code written by Apple co-founder Steve Woz decades ago - Mailpin

Steve Wozniakが6502とApple IIのために書いた、浮動小数点数演算用のライブラリのソースコードが公開されている。

出典は、1976年のDr. Dobb'sと、Apple IIのマニュアルだそうだ。

2014-05-19

OpenGLドライバー品質の実情

Rich Geldreich's Blog: The Truth on OpenGL Driver Quality

本の虫: OpenGLでムカつくことに引き続き、Valve社員のRich Geldreichが、OpenGLドライバーの品質について嘆いている。

製品の対象顧客が極めて限定された実行環境でもないかぎり、まともなGL開発者は、ドライバーの実情にぶち当たる。（今、あるいは来年までに製品を実際に出荷しなければならない場合、このドライバーとやりあわねばならないのだ。単にお家で趣味プログラミングしてるだけなら、この手の現実問題と向き合う必要は多分ないだろう）

D3Dしか使ったことがないのならば、覚悟しておいたほうがいいだろう。というのも、Windows/Linux用のGLドライバーはあまりにも多岐にわたるからだ。以下が、筆者の現在のドライバー品質についての意見だ。

ベンダーA

ほとんどの開発者がこのベンダーを使うのは、このベンダーは業界最高のデキるGL開発者を集めていて、テスト工程も最高だからだ。これは「標準」ドライバーだ。かなり速く、このベンダーのドライバー開発者は、完璧に純粋な規格準拠よりも、まともな方法を選ぶ（ちゃんと動くようにするため）。お家の趣味プログラマーがこのドライバーを使うのは、魅力的だし、拡張やGLサポートの点で、楽しいからだ。D3D12やMantleに対してGLが対抗して何かしている話では、たいてい開発者はこのドライバーを使っている。残念なことに、このドライバーだけを想定する実行環境に限定してしまうと、多くの市場シェアを獲得できない。

とはいえ、Source1をLinuxに移植して、Valve開発者がこのドライバーの開発者と手を組むまで、このベンダーはD3D9/11がやっているようなバッファーのアップデート（MapやBufferSbData経由）を、パイプラインをストールさせずに行うことすらできなかったのだ。ここで行っているのは、「ドライバーパフォーマンス初歩」的なことだ。その歴史は汚点なしというわけではない。また、バグに出くわした時、このドライバーはぶっとぶところまでぶっ飛んでしまって、GPUをクラッシュさせるとか、Windowsの場合、システムをTDRさせてしまう。とはいえ、とても信頼性が高く、よく作られたドライバーであることには変わりない。

訳注：TDR(Timeout Detection and Recovery)とは、不自由なMicrosoft Windows OSの機能の一つで、GPUがハングしたことを検出し、GPUリソースを強制解放、GPUドライバーの再初期化を経て、ハング状態から強制的に復帰する機構のこと。詳しくは、Timeout Detection and Recovery (TDR) (Windows Drivers)を参照。

ベンダーAはクッソ大量の拡張（いくつかは傑作だ）をサポートしていて、まあ、大抵のものは動くが、すこしばかり真剣に使おうとすると、ドライバーのよく使われているコードパスを離れて、未開の地に踏み込み、システムをクラッシュさせたり、ほんのわずかなことで即座にTDRしたりする。

このベンダーのツールは、歴史的に、完璧にクソである。動くとしてもほんの僅かな間だけ動いて、すぐ動かなくなってしまう。あるいは、開発部署に直接コンタクトを取って助けてもらうよう請願しなければ動かない。このベンダーには巨大な、おそらくはDillbert風のツール開発部署があって、よくわからんことをしているらしい。もちろん、このベンダーのツールは、このベンダーのドライバー上でしか動かない。

このベンダーは自社社員を有名なゲーム開発部署に送り込んで仕事をさせるということを、意図的、戦略的に行っている。これは諸刃の剣だ。というのも、このベンダー社員は、他のベンダーのドライバー上で起こる問題のデバッグを拒否するし、GLというものを、自社ドライバーの実装の上からしかみていないからだ。このベンダーの派遣社員は、他のドライバーの事情を一切考慮せず、自社ドライバーでのみパフォーマンスがでる手法を、意図的に採用する。

歴史的に、このベンダーは、主要ゲームタイトルのシェーダーを全部置換したりして、よりパフォーマンスがあがるようにしたりしている（時に、相当に向上する）。ほとんどのドライバーは、たまにこの手のことをやっているが、このベンダーは特に、パフォーマンスのためなら手段を選ばない。PCゲーム業界やグラフィック開発者にとって、これは何を意味するのか？　要するに、読者のような「平凡なグラフィック開発者」にとって、自分のゲームで、同じ技術的な結果を発揮できる可能性は極めて低い（たとえ、まったく同じアルゴリズムを使ったとしてもだ！）ということだ。何故ならば、読者諸君には、ベンダーから派遣されたドライバー開発者が、読者のゲームのために（低級に最適化されたシェーダーなどを使い）、そのゲームが実行されている時に、特別にドライバーが正しいことをするように調整するといったはからいがないためだ。言うなれば、歴史的に、PCグラフィックで伝説となっているゲームは、実は喧伝されているほどすごくなかったということでもある。なぜなら、彼らには手助けがあったからね。

ベンダーAは、冗談で「グラフィックマフィア」と称されている。読者の開発部署に、ベンダーAの開発者が派遣されてきたら、気をつけるがいい。奴らはマジだぜ。

ベンダーB

完全にカオス、パフォーマンス不安定すぎ、バグありすぎ、regressionテストまともにやってない、ドライバーのマルチスレッド部分は完全に機能しておらず、もはや開発者自身にもどうしようもできてない。クソなことに、このベンダーのGPUは結構標準的で、ハードウェア的には、まあまあできるということで、組織としては、ソフトウェア面で無能集団であるにも関わらず、無視することもできないのだ。glTexStorage()のような基本的なものですらクラッシュするし、出荷されたゲームがこのバグにぶち当たって、ドライバーが修正するまで何ヶ月もかかった。Bのドライバー開発者は、ベンダーAよりも規格に準拠しようとしているが、その結果として、たいした利点もないときている。というのも、ほとんどの開発者はベンダーAのドライバーを開発に使って、ベンダーBで上手く動かなかったら、ベンダーのせいにするからだ。GL規格の品質は無視される。

ベンダーBのドライバーの主要な拡張は、全然動かない。オモチャか机上の空論拡張だ。成果表を埋めて上司に進捗報告で使うためのものだ。主要なGL開発者は、絶対にこのベンダーの拡張を使わない。動かないからだ。論文の上ではよさそうにみえて、将来性を感じさせる拡張ではある。ベンダーBの拡張は、なぜGL拡張が現実ではクソなのかといういい見本だ。

このベンダーはなにかぶっ壊さずにドライバーをアップデートできたためしがない。やつらのよこすアップデートやらhotfixやらは、なにか一つの問題を直すが、別の二つはぶっ壊す。このドライバーのエントリーポイントにステップインしてみろよ、もうこの会社で働いてすらいないだろう元開発者の残したクソみたいな何層ものレイヤーがうずたかく積み上がっている。ベンダーBには、このフジツボみたいなソフトウェアレイヤーを理解してて、安全に変更できる開発者は残ってねーとみたね。

voglreplayで有名ゲームのGLコールストリームをこのドライバー上でリプレイすると、たまにぶっ飛んだ現象に出くわす。ゲーム自体はちゃんと動くのだが、GLコールストリームをリプレイしてみると、フレームバッファーがぶっ壊れてしまう（描画ごとにGLパイプラインをフラッシュすると直る）。筆者の予想だが、このドライバーはアプリごとにプロファイルを使って、ゲームごとに個別にバグだらけの機能を無効にしてるんじゃないかな。

面白いことに、ベンダーBにはちょっとしたツール開発部署があって、実際、便利で大抵の場合はちゃんと動くデバッグツールを作ってる。まあ、ベンダーBのGPUで使うならばの話だが。ベンダーBのツールなしでは、toglとSource1 Linuxは、出荷するのにもっと時間がかかっただろう。

これは一時的な傾向かも知れないが、ベンダーBのドライバーは、どうやら安定性軸に対して下降傾向にあるようだ（そうだ。これからますますひどくなるんだぜ）

いい点としては、信じられないかも知れないが、ベンダーBはOpenGL規格について、その一音節に至るまで、熟知している。もしこのベンダーの助けが得られたならば、彼らのよこす助言は素のGLを扱う上では役立つだろう（拡張は別だ）

ベンダーC - ドライバー #1

ベンダーCに怒るなんてことは出きっこない。そもそも、こいつらはグラフィックなんてやりたくないのだ。このベンダーの主要事業からはちょっと離れているのだが、最近、ひとつのダイに全部載せが流行っていて、このベンダーはダイスペースを余らせているのだ。このベンダーは、ハードウェアの達人であるが、ソフトウェアには、実際のところ、それほど興味がない。このベンダーは、オープンソースグラフィックドライバー業界におけるリーダーであり、このベンダーのハードウェア仕様は、ほぼ完全に公開されている。このベンダーは実際、めちゃくちゃ金を持っていて、組織図はめちゃくちゃ深く広く、ドライバー開発部署を二つ持てるほどだ！（そうだよ、このベンダーは、あるプラットフォームではGLドライバー#1を、別のプラットフォームではGLドライバー#2を使っている。この二つは完全に別のコードベースで別の開発部署だ）

とにかく、このベンダーの人事部は賢い。オープンソースウィザードのガキを直接雇って、ドライバー#1を改良させてる。このドライバーは、主要ドライバーのなかでは、最も低機能ではあるが、FPSなる用語の意味を知らないのであれば、とにかく動く。もし動かなくて、やる気があれば、読者は自ら手を汚して問題を修正し、パッチを送りつけることもできる。もし、読者がこのドライバーの修正とパッチ提出に相当たくみであれば、このベンダーから仕事が得られるだろう。

とにかく、ドライバー#1は、残念ながら、GL標準規格の点でいれば、だいぶ遅れている。しかし、後1,2年もすれば追いついて、去年当時ぐらいの規格を実装できるだろう。このドライバーを無視することは出来ない。何故ならば、何しろ市場シェアが圧倒的で戦略的価値があるからだ。そこで、この市場に食いつきたい開発者としては、ベンダーAやベンダーBだけがサポートしている、かっこよさげな拡張とか最新のトレンディーなモダンGLなんかは、使えっこない。読者はよろしくすべてのドライバー間でMIN()操作をしなければならず、多くの場合、このドライバーが、何が使えるかということを決定する。

ベンダーCは、どのプラットフォーム向けにも、GLツールを出していない。すまんね、グラフィック上の問題をデバッグしたいって？　1999年にようこそ。

ベンダーC - ドライバー #2

悲壮悲劇極まりない。この開発部署のドライバーはゲームではまず使われてない。つーかこのプラットフォームのGLなんて完全に二級市民じゃんか。多くのコードパスが全然動かねぇ。バッファーをアップデートするだけでよくわからんぶっ壊れ方をする。この開発部署はパフォーマンス解析とテスト用の記録に、ゲームごとに全然違った、ユニークで、バグだらけのクソをひねり落とす。この開発部署は、「パフォーマンス」とか「正しさ」ってのは、そもそも重要なのかどうかという究極の疑問を読者に叩きつけてくれやがる。

筆者は、ある有名なゲームエンジンの開発が、一年以上も、最新のGL 4.xとトレンディーな拡張を使ったバックエンドを、このドライバー上で動かそうと苦戦するのを見てきた。よう、お前ら、このドライバーは動かないんだったら。良いかげん明らめて、workaround満載の素のGL 3.xバックエンドを作れよ（toglや他の出荷済みゲームタイトルがやっているようにさ）

まあ、ベンダーCは、こっちの開発部署には、もう一方の開発部署より詳細なハードウェアの内部情報を与えてる。そんなわけで、同じゲーム、同じハードウェアの場合、ドライバー#1よりこっちの方が数パーセント速い傾向にある。まあ、動けばの話だがな。

他のドライバー

上記の主要なドライバーの他にも、いくつかのオープンソースドライバーがある。たいていはコミュニティによって開発されている、ベンダーAとベンダーB向けのドライバーだ。GLという観点から言えば、この手のドライバーは大きく時代に遅れている。だが、少なくとも動くということは聞いている。この手のドライバーについて筆者自身の経験はなく、また十分な情報も持っていない。というのも、この手のリバースエンジニアリングによるオープンソースのドライバーに関わると、ベンダーのクローズドソース開発部署を怒らせて、手助けが得られないんじゃないかと、筆者は恐れているからだ。

結論

大きなGLゲームタイトルを出荷するには、すべてのドライバー上でコードをテストして、すべての問題をworkaroundしないといけない。よくわからんGPU不具合、ヒープ破壊、ロックアップ、TDRに出くわした時は、GL神の助けあれかし。ドライバー開発者部署とその上司や取締役とは仲良くしとけ。こいつらの助けなしには、何もできやしないのだから。

ちなみに、分かる人にはまるわかりで、余興をそぐ蛇足的なネタバレだが、一応補足しておくと。ベンダーAはnVidia、ベンダーBはAMD、ベンダーCはIntelで、ベンダーCはのドライバー#1は、GNU/LinuxやMesaなどからなる、自由なドライバースタック、ベンダーCのドライバー#2は、不自由なWindows OS用の不自由なドライバーである。

まあ、筆者の意見では、ベンダーCのドライバー#1が、現時点で最適だろう。

ドワンゴ広告

最近、ドワンゴに40代のエンジニアが中途採用されたそうだ。ドワンゴは採用に際し、年齢によるくだらない足切りを行う企業ではないとはいえ、この日本で、40代で、しかもこのドワンゴに転職してきた人というのは、相当に能力があるのではないだろうかと思っているが、実際のところはわからない。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-17

江添とタピオカボドゲ会

明日、5月18日は、野方にある妖怪ハウスで、タピオカボドゲ会を開くことにした。これは、大量のタピオカパールをココナッツミルクで胃袋に流し込みながら、ボードゲームをする会である。

タピオカパール、あるいはボードゲームに興味のある者は、妖怪ハウスまで来るといい。

当日に備えて、アメ横に行って大粒のタピオカパールを大量に仕入れてきた。また、ココナッツを5個買ってきたので、ココナッツジュースも飲める。

ココナッツミルクは6リットル買ってある。寒天と果物の缶詰も買ってきたので、ココナッツミルクと果物の寒天でも作ろうとかと思う。

また、当日はスイートポテトも作る予定だ。

今夜は、明日に備えてカレーを5リットル作った。

準備は万端だ。

OpenGLでムカつくこと

Rich Geldreich's Blog: Things that drive me nuts about OpenGL

Valve社員のRich Geldreichが、OpenGLの設計が古臭すぎることについて不満を爆発させている。

OpenGLについてムカつくことを脳内ダンプしてみる（これは個人的な件秋であって、Valveや同僚の見解ではない。あと、ここ数年、OpenGLと格闘してきたので、今日は機嫌が悪い）。これを投稿する理由はこうだ。GL APIには再設計が必要だ。というのも、思うに、MantleやD3D12がどうせ昼飯前にOpenGL APIを駆逐してしまうだろうから、この問題については、今考える必要があるのだ。

ここに見れば些細な問題もある。単にAPIのトレースの問題というのもある。しかし、それらの問題が積み重なって、他の開発者にGL APIという環境に飛び込むよう誘うのを躊躇させるほどになっている。
20年もののレガシーは、再設計と大幅な単純化を経る必要がある

コアAPIで互換性なしのゴミ満載のワゴンの周りをぐるぐると。
単純にして、KISS principle適用して、「迷ったら投げ捨てろ」
MantleとD3D12はすみやかに、パフォーマンスと開発者への訴求性という点で、GLを（また！）置き去りにしていくだろう。

Global context stateとbinding patternはクソだ。DSA(direct state access)スタイルのAPIが標準となるべきで、また必須であるべきなのだ。

口に苦い良薬をくれてやろう。大半の開発者達は、お手軽な道を選んで、PS4やXBoneのレンダリングコードをD3D21やMantleに移植するだろう。わざわざレンダリングパイプラインを書きなおして、GLコミュニティが最近パフォーマンスアップのために推奨している、超アグレッシブなバッチ処理に書きなおしたりはしねーよ。APIが近代化して簡潔になるまでは、GLは移植ターゲットとしては二級市民の扱いを受けるだろう。

GL context作成地獄

モダンなGLコンテキストを作成するのは怒髪天を突きまなじりことごとく割くほど難しく、ありえんほど間違いやすい（トランポリンコンテキスト？）　やり方があまりにも間違いやすく、プラットフォーム（時にはドライバー）ごとに違うので、俺は絶対にglXやwglなんかのAPIを直接使うことはやめて、SDLやGLFW（あるいは、GLEWのようなもので関数/拡張のポインターを取得するもの）のようなライブラリを使うことをおすすめしている。

ちょっと使うだけなのに、膨大なサードパーティライブラリの中からどれかを選んで使えとかいうのが当然になっている現状はクソだ。APIはもっと単純にして標準化して、ただ使うだけでサードパーティライブらいが必要になることがないようにしろよ。

スレッドのコンテキストは暗黙にthisポインターであるかもしれないということ

GetProcAddress()で取得した関数ポインターは、コンテキストに強く結びついているため、グローバルに使えない（GL風に言えば、コンテキスト依存とコンテキスト非依存）。要するに、GetProcAddress()をあるコンテキストで呼び出して、戻り値の関数ポインターを他所で使うと、なにか悪いことが起こるか、単にクラッシュする。

GLってC APIなのかよ？　違うのかよ？

このクソ、もっと単純化して標準化できないのか？

glGet() APIの欠点

これはちょっとトレースの都合かも知れないが、しかし、APPIのトレースが難しいことにより、ツールがクソであるか存在しないとすれば、開発者としては麺道に鳴るので、通常の開発者にも間接的に悪影響を与えるのだ。

glGet() APIシリーズ(glGetIntergerv, glGetTexImage, 等など)は"max_size"引数がない。そのため、ドライバーは渡された引数や、グローバルコンテキストの状態によって、渡されたバッファーをオーバーライトすることが可能である。この関数群は"max_size"引数を受け取るべきであり、max_sizeが小さすぎた場合、関数は失敗するべきである。メモリをオーバーライトすべきではない。

テクスチャーバッファーのサイズを計算するために、ドライバーがグローバルコンテキスト状態に依存して読み書きするのは、クソすぎる。

glGet()に渡せるpname enumには数百種類もある。いくつかは、特定のドライバーでなければ受け付けない。トレーサーとかのデバッグヘルパーを作るとき、あるpname enumで値がいくつ書き込まれるか、あるいは十分な（ロスレスな）型とかいった公式な表が一切ないときている。

それと、APIの初心者には、indexedとnon-indexedなgetsとsetsの挙動は、簡単にわからない。

glGet()メタデータAPIを付け加えるか、表を作るかしろ。

glGetError()

Win32みたいにglSetLastError() APIは存在しないので、トレースが無駄に複雑になる。一度も呼ばないアプリがある。１フレームに一回呼ぶアプリがある。リソース作成の時にしか呼ばないアプリがある。初期化の際に何前回も読んで、その後は二度と呼ばないアプリがある。筆者は、あるい有名なGLアプリが、毎フレームGLエラーを出しているのをみたことがある（これって普通のことか？　開発者は知ってるのか？）

テクスチャーターゲットとかの重要な情報を取得できない

（現在策定中のものもあるってのは知ってるよ。Cass君）。これにより、トレースやスナップショットが、shadowing（）により難しくなる。shadowingはglGetError()に影響する（呼び出しが成功したと知るまで、shadowをアップデートできない。呼び出しが成功したかどうかを確かめるには、glGetError()を呼び出す必要がある。これは、コンテキストの現在のGLエラーを吸収してしまうので、トレースされているアプリからみるGLエラーに影響を与えないよう、ヘンテコな仕組みが必要になる）

glGet()をすべて廃止しようという最近の議論について：思うに、すべての状態情報は取得可能であるべきだ（今や当然だろ）、さもなければ、APIはD3D12やMantleみたいに、最高のパフォーマンスのスケーラビリティを念頭に設計されているべきだ。D3D12やMantleのようなAPIによる付加価値は、そういう極端な用途では、理解されている。

glGet()の類を廃止することは、トレーサーとコンテキストスナップショットの仕事をさらに面倒にするだけだ。

DSA(Direct State Access) APIは未だに標準ににないし、使えないしサポートされてない

DSAは、一部のアプリの呼び出しのオーバーヘッドを劇的に改善してくれる（たとえば、Source1のGLバックエンド）。global stateへの依存をやめてくれよ。頼むし、DSAを標準に入れやがれ。
正式規格は2014年に完成しない

XML規格には、依然として強い型付けがされた引数の情報が欠けている。例えば、
<command>
    <proto>void <name>glBindVertexArray</name></proto>
    <param><ptype>GLuint</ptype> <name>array</name></param>
    <glx type="render" opcode="350"/>
  </command>
筆者の知る限り、apitraceのglapi.pyが、いまだに唯一の公開された信頼できる情報である。
GlFunction(Void, "glBindVertexArray", [(GLarray, "array")]),
glapi.pyは型を"GLarray"にしているところに注目。公式規格は、よくわからない"GLuint"型にしている。

glGet info()を公式規格に、上記のような感じで入れろ。pname enumが返す値はいくつだ？　ドライバーが埋め込んでるshadowまで含めてロスレスに値を維持できる型はなんだ？このpnameはindexed版で使っていいのか？
今週のGLSLバージョン地獄

昔のバージョンでは、GLSLバージョンは、最初に定義されたGLバージョンと同じではなかったので、無駄によくわからないことになっていた。これはGLSL拡張（GL拡張ではない）以前の話で、それも含めると、初心者置いてけぼりだ。

D3DXライブラリやツールに相当する標準や公式のものがGLにはない

ドライバーやGLコンテキストに依存しない、テクスチャーや日くせええるフォーマット変換ツール。

KTXフォーマット地獄：KTXフォーマット（DDSのGL版）を読み書きできるツールは少ない上に、常に相互に読み書きできるわけでもない。

開発者は、Direct3DのDXTEXの同等品を、ソース付きで必要としている。

KTXサンプルは、KTXファイルをGLテクスチャーに読み込む方法ぐらいしか示していない。KTXファイルと他のDDSとかPNGとかの標準的なフォーマットとを相互変換するツールが必要だ。

そういうライブラリにはGLSLコンパイラーも含まれているべきだ（HLSLシェーダーをD3DXでコンパイルできるのと同じように）

GL拡張は公式規格へのdiffで書かれている

OpenGL規格エキスパートでもない限り、拡張を理解するのはめちゃくちゃ難しい。

関連：公式規格はあまりにも広範な読者向けに書かれている。ほとんどの規格読者は、これをパースできるほどのエキスパートではない。規格は開発者にやさしい版の規格と、ドライバー開発者のための詳細な規格に分割するべきだ。拡張は規格に対する純粋な差分となるべきではない。そんなんじゃ理解できないだろ。

ドキュメント地獄

20年間ものGL APIのゴミ解説が転がっていて、Google検索のノイズになっている。初心者はクソだったり古臭かったりするドキュメントやサンプルにぶち当たってしまう。

MakeCurrent()地獄

一部の拡張（てめーのことだ、NV bindless texturing！）のせいで、追加の隠し変数のコストが、クッソ高くつくことがあるわ、glBegin/glEndに囲まれた中で呼ぶと、ドライバーをクラッシュさせるわ（GPUすらクラッシュさせる）

この関数呼び出しの挙動とパフォーマンスは、もっとまともに規格化されて、開発者の間で議論されるべきだ。

ドライバーは、APIが未定義の方法で呼び出されたとしても、GPUやCPUをクラッシュさせたりロックアップしたりすんな

いい加減分かれよ。まともなテスターを雇ってドライバーをぶっ叩け。

いやまて、もっとマシな方法があるぜ。APIを構造化して、APIで表現可能な未定義や危険なパターンを削減しやがれ。

複数のコンテキストが絡むオブジェクトの削除、コンテキスト間の参照カウントのルール、ゾンビオブジェクト

削除するオブジェクトが別のコンテキストにも束縛されてたとしたら、まあ、ご愁傷さまってこった。

削除されたオブジェクトに対してglGetを呼び出したら（別の場所で束縛されてたりするので、まだ半分生きてる）、挙動はドライバーごとに異なる。

こういうことが全部、無駄にコードを複雑にしたりオーバーヘッドを生じさせる。

100%信頼できるスナップショットやGLコンテキスト状態の差し戻しがクッソ難しくなる。

世界級の開発者が、知らずのうちにヘマをやらかしている。明らかに、APIやツール環境がぶっ壊れてる証拠だ。

シェーダーコンパイルとリンク地獄

シェーダーのコンパイルとリンクのパフォーマンス上の問題がこれだ。

シェーダープログラムをトークン分割しておくのは有益なことだ。Direct3Dは、そのいい証拠だ。素のGLSLがあふれかえっているのは、開発者がD3Dで書かれたものを移植した結果であるし、その結果としてエンドユーザーは糞遅いロード時間にみまわれていてありえん。そのくせ、GLはいまだにテキストのGLSLシェーダーしか受け付けない。

ドライバーごとに（訳注:シェーダーコンパイルの)パフォーマンスは極端に異なる。あるドライバーでは、シェーダーのコンパイルは、実質無料同然であるが、別のコンパイラーでは、クッソ高くついたりする。

プログラムのリンクは、あほみたいに時間がかかる。

リンク済みプログラムをキャッシュするドライバーもあれば、そうでないドライバーもある。

プログラムをリンクする時間は、予測不可能だ。プログラムがキャッシュされていれば速いが、プログラムがキャッシュされているかどうかを取得する方法がない。そもそも、プログラムのキャッシュをドライバーがサポートしているか取得する方法もない。

マルチスレッドコンパイルをサポートしているドライバーもあれば、そうでないドライバーもある。ドライバーがマルチスレッドコンパイルをサポートしているか取得する方法はない。

APIがクソすぎるため、トレースやスナップショットが困難になっている。シェーダーはリンクされた後にデタッチされる。リンクされたプログラムの状態の多くが、取得不可能だ。トレーサーによるリンク時間の隠匿が必要になる。

D3Dでやってることをコピペしろよ（いいか、D3Dのやり方はちゃんと動くし、開発者も理解できるんだから）

トレース、リプレイ、スナップショット、リストアの難しいAPI

ツール環境にとって悲惨で、最終的にまわり回ってAPIのユーザーを苦しめることになる。

APIは簡単にトレース、リプレイ、スナップショットできることを念頭に設計されるべきだ。さもなければ、MantleやD3D12のように、極端なパフォーマンスとスケーラビリティを重視した設計にすべきだ。

現在、GLはそのどちらの側面も備えていない。あらゆる価値観からみて、悲惨な立ち位置にいる。

API設計者は、物事がいかにして動くべきかとか、俺らめっちゃ賢いからD3Dとはまるっきり違ってたほうがいいんだとかいうことではなく、APIが実際にもたらす価値を考えるべきだ。

GL関数の終わりなき迷路（何千もありやがる！）

おい、本当に何十個ものglVertexAttrib系が必要なのかよ？　そもそも、このAPIって誰が使ってんだよ？

APIは再設計と単純化が必要だ。S/N比を上げろ。頼むし。

v3.x APIから移行する際のレガシーの厄介さ

「前方互換」、「互換性」 VS 「コア」プロファイルとかなんとか

一介の開発者は、単にAPIを使ってシェーダーでトライアングルを描画する程度のことに、こんなことを極める必要に迫られるべきじゃねーよ。

「コア」なんて用語は使われるべきですらねーんだ。

パイラインをストールさせずにDISCARDセマンティクスつきでバッファーをロックする信頼できる方法が全ドライバーで提供されるべき

mapフラグって使ってるか？　BufferData()をNULLで読んでるか？　両方やってる？　どっちかだけ？

どのロックフラグを使ってる、いや、どのフラグ使ってる？　いやちょっとまて、ドライバーはフラグを完全に無視してねーかこれ？

D3Dでは当然だったことが、GLでは難しい。エキスパートとなるか、ドライバー開発者と直接コンタクトとれないと厳しい。

これはクッソ重要なんだぞ！

ドライバー開発者に告ぐ。本物のドライバー開発者と、開発者もどきを分かつのは、このへんのところをいかに正しく実装してテストするかにかかっているのだ。この2014年において、パイプラインのストールは許容できん！

BufferSubData()はマルチスレッドドライバーで「多すぎる」データを食わせて呼び出すとストールする

「多すぎる」っていうのがどの程度なのか取得する方法はないときている。4k? 8k? 256k?

パイプラインのストール

公式の方法、非公式の方法を含めて、コールバックとかデバッグメッセージとかで、いつドライバーが諦めて、レンダリングスレッドに馬鹿でかいパイプラインストールをこしらえるのか判断するのかということを、取得する方法がない。

これはレンダリングボトルネックの最大の原因であるにも関わらず、計測のためのツールが一切存在しない（そのようなツールを作るためのAPIもない）

マルチスレッドドライバー地獄

一部の製造業者は、開発者が入念にテストして出荷した後の製品に対して、バグだらけのマルチスレッドドライバーを強制的に個別に自動有効している（なお悪いことに、開発者に告げもせずに「アプリプロファイル」とやらを変更したりしている）

あるマルチスレッドドライバーは、マルチスレッドが有効なときはglGet()が不具合だらけになって、スナップショットが悲惨すぎることになる。

ドライバーがマルチスレッドを使うかどうか取得、設定する公式の方法はない。

トレーサーが有効になっていて、大量のglGet()呼び出し（通常のアプリは行わないこと）を行うということをドライバーに通知する方法もない。

ドアホなマルチスレッドドライバーは、トレーサーがglGet()を発行するとクッソ激遅になった上に停止する（ヒューリスティックか何か使って、自動的にマルチスレッド無効にしろよ！）

一部のドライバーで、タイムスタンプの取得はパイプラインをストールさせる

クロスプラットフォーム環境で、信頼できるGPUプロファイリング目的に使えなくなる。GL規格は、このようなクエリーに対して、いつドライバーはストールを引き起こしていいのかどうかを強く規程すべきだ。無意味にストールするのは、ドライバーのバグ（このちっぽけなAPIがいかに重要であるかを理解していない無能なドライバー開発者のバグ）であると定義すべきだ。

参考のために書くと、NVidiaは正しくやっている。読者がパイプラインクエリーコード周りのドライバーを書いているのならば、頼むし、出荷する前に、お前の実装をNVidiaのドライバーと比較するぐらいのことはしやがれ。

GLは、実質X個の別々のAPIが（ドライバーごとにひとつ、時に、プラットフォームごとにひとつ）、単一のAPIのごとくよりあつまっているということ。

（マルチスレッドモードと非マルチスレッドモードを含む）すべてのドライバーで製品の動作の正しさとパフォーマンスを入念にテストしなければ、GL製品を出荷できない。ドライバーの違いには驚かされるだろう。D3Dで長年やってきた筆者にとって、これは衝撃の事実だ。

これはつまり、Khronosには、何か強制力のあるドライバーのテストや検証をやってもらう必要があるということだろう。GLはWHQL認証のようなものを必要としている。

拡張地獄

GLで喧伝される利点として、拡張のサポートが挙げられる。拡張はAPI全体を蝕むものであり、利点とはならない。

筆者は、この一年半ほど、大小規模の大量のGLのコールストリーム[訳注：一連のGL関数の呼び出しのこと]に関わってきた（それ以前には、筆者はtoglをすべてのドライバーで動かして出荷可能にする仕事をしていた。その2年以上にいかに辛酸を嘗めたかは、筆舌に尽くしがたい）。ドライバー開発者を除けば、筆者は世の中のGL開発者の誰よりも、現場で使われているGLコールストリームに触れてきた。残念ながら、多くの場合、高度でモダンな拡張というのは、かろうじて動くレベルのものだ（時に、ベンダー自身が、その事実を認めることもある）。あるいは、一見かっこよさそうにみえる拡張を使おうとすると、すぐにほとんど使われていない（つまりテストされていない）ドライバーのコードパスに潜り込んで、実用にならないことに気がつくであろう。

コールストリームの研究と仕事を続けるうちに、明らかに、開発者は現在使われていて実行環境でもあるドライバー群に対して、実装する機能としては、大胆なMIN()を行っている。これはたいてい、コアプロファイルv3.xとかで、ひょっとしたら4.xバックエンドの中のとても単純で安全な一部の操作を含むだけだ（あるいは、今がまだ1998年か2003年でもあるかのように、互換GLを使い続けている小さなゲームタイトルとか、だって、必要なものは全部揃っているしね）。開発者は、ほとんどの拡張を、わざわざ使ったりしない（特に、モダンな奴はなおさらだ）。というのも、その手の拡張は、信頼性に足るほど動かない（その機能を実装するドライバーのコードパスは、本物のアプリに対してテストされていないからだ。古典的な鶏と卵問題である）か、単にサポートしているのが立った一つのドライバーだけであるか、あるいはその拡張利用よる付加価値が、製品のテストの規模などを拡大するのに見合わないからだ。

さらに、この点のモダンな拡張は、トレースが極めて難しい。つまり、開発者が使っているデバッグツールに互換性がない。そこで、フォールバック[訳注：拡張を使わない実装]も提供しなければならない。どうせ開発者がフォールバックも実装しなければならないとするならば、最初からそのフォールバックを使った製品を出荷して（全部の環境で動くしな）、拡張なんて気にしなければいいだけの話だ（製品に超すごい付加価値が生まれるのでもなければだ）

というわけで、拡張なしのGLでなければ、信頼性と正しく動く製品を求める開発者の大勢を惹きつけられないのだ。

ドワンゴ広告

この記事はドワンゴ勤務外に会社の電力を無駄使いして書かれた。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-15

最近の妖怪ハウスの様子

最近の妖怪ハウスの様子はどうか。

妖怪ネットワークに、新しいWiFi APを追加した。たまたま、NECのAterm WR9500Nを安く手に入れたので、これまで部屋が密集している場所に設置されていたバッファローの貧弱な無線LANルーターと交換した。とりあえず、各部屋にまともなWiFiが提供されたようだ。

それにしても、無線だけで満足なこの妖怪ハウスの住人たちというのは、よくわからないものだ。筆者はもとより無線を信用していない。有線でなければ満足できないのだが。

あとは、奥の部屋がひとつ、無線難民になっている。ところが、ここの住人は、テザリングでも構わないと言っている。ますます理解できない。

妖怪ネットワークの抱えているもうひとつの問題としては、午後10時頃から深夜にかけて、インターネット回線がかなり遅くなるということだ。調べてみると確かに遅い。しかし、特に今この瞬間、誰かが帯域を大幅に消費しているわけでもない。そもそも、RTX810で"show status pp 1"した結果によれば、今月はじめから15日間でダウンロードした情報量は、1.3ギガオクテット程度である。全然使われていない。何故こんなに遅いのか。どうも、この原因は、妖怪ハウスの外にあるような気がしてならないのだが。

また、今の妖怪ハウス内のLANケーブルの配線は、とりあえず壁にテープでとめただけなので、いずれ剥がれてくるだろうし、あまり見た目もよくない。床をケーブルがはっているよりはマシになったが、これもおいおい何とかしなければならないだろう。

さて、妖怪ハウスもいろいろあったが、どうやら無事に一周年を迎えたようだ。一周年記念のパーティには、大勢の人がやってきた。筆者は、カレーとピザを作った。今回のピザ生地は、水の量が適切であったため、うまくいった。さすがに三度目ともなると慣れるものだ。次はどのような料理を作ろうか。

一周年記念のパーティの余興になるかと思い、たまたま都合よく届いていたテントを、ベランダに設置した。安物のテントではあるが、どうやら十分実用になるようだ。さながら、妖怪ハウスに部屋が一つ増えたようであった。パーティ中は、筆者のあずかり知らぬところで、勝手に占領されてしまっていたのだが。

ベランダにテントを設置できることは確認したが、長期運用するには、雨対策をしなくてはならない。下にパレットを設置して、地面から浮かすのがいいだろうと思う。パレットは、最小購入数が、50枚や100枚のものばかりで、なかなか難しい。どこかで、1メートル四方のパレットが4枚ばかり手に入らないだろうか。

一周年記念パーティの翌日の夕方、パーティの参加者で、まだ妖怪ハウスに残っていた者達で、にわかに近所の公園まで遊びに行った。リア充ごっこをしようということで、途中にあった100円ショップでバトミントンやらボールやらのリア充グッズを買い求めて向かった。しかし、平均年齢が少なくとも20代後半、ことによれば30になる上、男5人、女1人というこのデコボコ集団は、はたしてリア充と言えるのだろうか。

さて、公園についたが、あいにくと風が強く、またバトミントンも100円ショップの安物のせいか、ラリーが続かない。しまいには、ラケットをボール代わりにして投げつけ合う奇妙な遊びに発展した。果たしてこれはリア充と言えるだろうか。

そろそろ暗くなってきたので帰路についた我々リア充ごっこ一行が目にしたのは、だるまさんがころんだをしている男女比率の偏っていない大学生らしき集団であった。実にリア充らしい集団であった。我々は敗北感を感じたまま無言でその横を通り過ぎた。

帰り道に、我々はこの「リア充」なる用語の定義について話し合った。

「彼女がいればリア充か」
「しかし、たとえ恋人がいたとて、仲違いをしている状態はリア充とは到底言えまい」
「しかし、痴話喧嘩というのは、はたから見ればリア充ではないか」
「うまいものを食べていればリア充だ」
「では、70、80のじいさんばあさんがうまいものを食べているのはリア充か」
「リア充だな」
「思うに、リア充なる用語はあまりにも濫用されすぎて意味が弱くなってしまっている」

さて、18日には、妖怪ハウスで、タピオカボドゲ会をする予定である。これは、大量のタピオカパールをココナッツミルクで飲み下しつつ、ボードゲームをする会のことだ。

2014-05-14

KADOKAWA・DWANGOについて

朝起きると、今朝の02:00に日経が興味深い記事を公開していたことに気がついた。

角川・ドワンゴ経営統合　アニメなど「ニコ動」で海外へ　　：日本経済新聞

はて、どうせ日経のことだろうし、また飛ばし記事だろうかと読み飛ばして、10:45にドワンゴに出社した。ちなみに、この時間は、ドワンゴのエンジニア基準では、まだ出社している人もまばらな時間帯である。筆者はドワンゴ社員にしては珍しく、早寝早起きなのだ。

さて、ドワンゴ社内では、日経の報道する、角川との経営統合について知っている人間はいなかった。

さて、出社して、勤務時間中に、勝手にBoost.勉強会 #14 札幌で使うスライド資料を書いて公開してから、弁当を使った。今日の弁当は、五分づきご飯、グラタン、コンソメスープだ。グラタンは、昨日の夕食の残りである。筆者はしっかりとした弁当用の容器を持っているので、コンソメスープも温かいまま運搬可能なのだ。

さて、昼飯を食べた後、ドラゴンズストーンというボードゲームをした。このゲームはなかなか戦略が練れそうだが、ルールを把握しているものは誰もいないので、今回はルールの把握がてら、手探りで遊ぶことになった。

さて、恒例の昼ボドゲ終了後に、OpenGLネタの興味深い記事をブログで紹介しようと思ったが、やや眠気を覚えたので、昼寝をすることにした。考えてみれば、昨日は実質6時間しか寝ていない。すこし仮眠して眠気を取ってからとりかかろう。

さて寝ようと横になったところで、同僚がやってきた。なんでも、15:15から、15階で角川の件で発表があるという。はて、そんな話は聞いていないぞ。どうやら、私がフロアを離れたすこし後に伝達されたそうだ。

さて、歌舞伎座タワーの15階というのは、近々MAGESが移ってくる。そのため、現在社内では、フロア中央のぶちぬき踊り階段を延長する工事を行っている。そのため、13階と14階の行き来が面倒になっている。フロア貫通階段は、すでに歌舞伎座タワーのドワンゴ社内を見学した人によって画像などもネット上に広がっている。

株式会社ドワンゴ歌舞伎座タワー新オフィスに行ってきた！ - 941::blog

フロアぶち抜きの踊り階段は、結構カネがかかるそうで、今まで、その価値をあまり意識したことはないのだが、今回、工事で塞がれて、初めてその価値を認識した。なるほど、踊り階段がないと、わざわざエレベーターや非常階段を使わねばならず、とても面倒だし、余計に時間がかかる。踊り階段は必要だ。

それはさておき、まだ15階への踊り階段は完成していないので、エレベーターで15階に上がった。そこには、歌舞伎座タワーにいるほぼ全員が集まっていた。さて、その場で川上会長が話した内容は、株式会社ＫＡＤＯＫＡＷＡ株式会社ドワンゴ合同発表会 - 2014/05/14 17:00開始 - ニコニコ生放送で話した内容と、全く同じだった。さてはリハーサルであったのか。

筆者は会社経営には詳しくないが、あやふやな記憶によれば、KADOKAWAとドワンゴを束ねる持株会社を設立して、両社とも上場をやめるのだそうだ。

両社は対等な関係、会長はKADOKAWA側ではなく、ドワンゴから川上会長が就くらしい。

川上会長「個人的には副会長のほうがいいんだけどね」

ある社員から以下のような質問が出た。

社員「会社名はどうなるんです？」
荒木社長「あー、やっぱり気になる。KADOKAWA・DOWANGO」
一同「あー・・・」
荒木社長「まあ、これに関しては後でいくらでもSNSでDisってください」

だそうだ。

そして、17時から記者会見をニコ生するので、仕事をサボって見てね、とのことであった。

そして、MAGESが入る歌舞伎座タワー15階フロアは、まだ金を払ってないのだそうだ。

そして、肝心のOpenGLネタの紹介は、明日以降に持ち越されそうだ。とりあえずリンクだけ。

Rich Geldreich's Blog: Things that drive me nuts about OpenGL

Rich Geldreich's Blog: The Truth on OpenGL Driver Quality

ドワンゴ広告

この記事はドワンゴ勤務中に記者会見をニコ生で見ながら書いた。

ところで、今日ドワンゴ社内で知り得た有益な情報によると、タピオカパールはアメ横に大量に売っているそうだ。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

Boost.勉強会 #15 札幌の発表に使うスライド資料

来る2014年6月24日にBoost.勉強会 #15 札幌が開かれる。筆者は、この勉強会に発表者として参加する。

そのスライド資料の草稿を書き上げたので、公開する

EzoeRyou/boost-benkyokai-sapporo

今回、筆者が話す内容は、自動ストレージ（一般的な実装ではスタック）からの動的なメモリ確保を、標準化する際の、障害についてだ。

本来C++14に入るはずだった、実行時サイズ配列とdynarrayは、この問題のためと、スイス支部がNBコメントで拒否したために、規格ではなくTS(Technical Specification)行きになった。

その問題点とは、簡単に行ってしまえば、ネストされた再確保の方法ということになる。ネストされた再確保は、今までも規格でサポートされているので、例外を設けることはしたくない。そのためには、ネストされた再確保の標準化が必要になる。その方法は、まだ提案されていない。

より詳しくは勉強会で説明する。

ドワンゴ広告

リンクしているスライド資料は、あえて休日を使わず、ドワンゴ勤務中に書いた。

Boost勉強会札幌に参加するための旅費はドワンゴが出す。

この記事はドワンゴ勤務中に書かれた。

そして筆者はこれから社内で昼ボドゲ。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-12

C++標準化委員会の国際会議に出席するためにパスポートを取得した

さて、ドワンゴに入社した筆者は、今やC++標準化委員会の国際会議に出席できる機会を得た。国際会議というのは、年数回、海外に飛んでホテルに一週間缶詰になるということだ。これにかかる費用を個人で出すのは難しい。ましてや無職では難しい。C++の規格は個人でも学べるが、金や会社がなければ行えないC++啓蒙活動もあるということだ。

さて、C++WGの国際会議に出席するには、単に金さえあればいいというわけではない。色々と準備が必要だ。とりあえず筆者個人としては、まずパスポートを取得しなければならない。

パスポートの取得は、それほど難しくはなかった。問題は、パスポート取得に至る準備が、厄介だった。

まず、パスポートを取得するには、戸籍謄本か戸籍抄本が必要になる。筆者の本籍は生まれてから移していないので、東京にはない。したがって、郵送で申請しなければならない。申請するには、本籍がある場所をしらなければならないが、筆者は知らない。たしか、住民票に書いてあったはずだが、引越の際についでに取得した住民票は、もう破棄してしまった。

そのため、本籍を知るためだけに住民票を申請する必要があった。

さて、住民票によって本籍を把握したので、さっそくその場所の役所に郵送で戸籍謄本を申請した。これに一週間かかった。

さて、パスポートの申請に必要な書類が揃ったので、パスポートセンターに行った。

顔写真は用意しなかった。思うに、パスポートセンターともなれば、周辺に顔写真を撮影する機械ぐらいあるだろうと踏んだのだ。

はたして顔写真撮影所はあった。それも、パスポートセンターの横にあった。駅やコンビニにあるようなボックス型の撮影機ではなく、撮影所であった。料金はボックス型撮影機よりは割高であったが、ちゃんと照明や撮影者がいるので、利用することにした。平日の昼間だというのに、撮影所は撮影待ちの人が大勢いた。だいぶ儲かっているといえよう。この撮影所の形態はどうなっているのだろうか。公務員がやっているのだろうか。それとも民間の業者がやっているのであろうか。

顔写真の撮影でよくわからないのが、価格だ。写真撮影の価格が、かなり高い。もちろん、部屋の中に照明があって、撮影者がいて、受付がいるこの撮影所ならば、料金がある程度高いのは分かる。しかし、無人のボックス型撮影機まで、料金が高いのは何故だろう。なぜプリクラほど安くはならないのだろうか。いや、考えてみれば、プリクラだってそれなりに高い。この機材と印刷用の紙やインクが、それなりの値段するのだろうか。

写真撮影の価格に対する疑問を抱きながら、パスポート申請の手続きをした。パスポートが発行されるにはすこし時間がかかるので、その日はそのまま出勤した。

さて、いよいよパスポート受領の日だ。再びパスポートセンターを訪れた筆者は、パスポートを受領する窓口に向かった。

筆者「パスポートを受け取りに来ました」
職員「ここに名前を漢字でおねがいします」

と職員が差し出した書類を見ると、なるほど署名欄がある。さっそく、江添亮の江のさんずいまでかいて、ふと、上の欄にある文面に気がついた。正確な文面は失念したが、以下のような意味の内容が書いてあった。

旅券に記載事項を確認し、旅券を受領しました

ん？　旅券の受領はともかく、まだ旅券の現物を確認していないではないか。

この事実を指摘すると、職員は、「では署名は後で」と、パスポート（旅券）を持ってきた。筆者は、旅券に記載された事項に誤りがないことを確認した後で、書類に署名した。

型通りのお役所仕事というのは、実に不思議だ。手順だけが目的になってしまう。

こうして、パスポートを手に入れた筆者は、職場に向かった。まだ国際会議参加のためにやることは山ほどあるのだ。

ドワンゴ広告

筆者のパスポートの申請作業はドワンゴの勤務時間を大胆に削って行われた。この記事はドワンゴの勤務中に勝手に書いたので、これも筆者の勤務時間の削減に貢献している。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2014-05-10

妖怪ハウス一周年

今月、妖怪ハウスは設立から一年を迎えた。一周年を記念して、5月10日はパーティを開く予定である。どうやら、このパーティは、広く告知していないようであるが、まあ、筆者の直接の知り合いであれば、来ても構わないだろう。どのくらい人が集まるのかは、まだわからないが、あるいはすこし騒がしくなるかも知れない。

妖怪ハウスは去年の今頃設立された。果たして続くだろうかと常に危惧されながら、どうやら一年間維持できたようだ。

聞くところによれば、妖怪ハウスの設立当初は、多大な初期費用を支払ったために、住人は貧困に苦しんだという。そして、ここで語るべきではないことどももあったと聞く。何にせよ。今はもう、過去の話だ。

シェアハウスの雰囲気は住人が決める。住人が数人入れ替わるだけで、シェアハウスの雰囲気はガラッと変わるのだ。

筆者が今年のはじめに妖怪ハウスに引っ越した時、妖怪ハウスは、筆者にとって住みにくい状態にあった。ゴミの山、散らかった部屋、汚れたトイレと風呂場。そして最悪なことに、不安定すぎるインターネット回線だ。ゴミや汚れはまだ我慢もできるが、ネット回線のような基本的人権で保証されるべきインフラが貧弱なのは、到底耐えられるものではない。

ただし、筆者は繊細な心を持ち合わせていないので、治療は荒療治になる。大雑把にゴミを捨てたり、掃除をしたりはするが、元来荒っぽい正確なためか、細かいところに手が届かない。なにより、汚れる速度に掃除が追いつかない。

ネットワークも、それほど繊細なことはしていない。ただ、ケーブルを壁に固定して、強力なスイッチングハブとルーターを導入したぐらいだ。これでもまだ、皆のネット利用が集中する午後10字頃になると、ネット回線が遅くなる（どのように遅いのかは不明だが）という意見があるので、また詳しく調べなければならない。残念ながら、午後10時というと、筆者はすでに寝ている時間なので、なかなか調査が難航している。

筆者は何かを大きく変化させることは好むところであるが、仕上げは苦手だ。それに労力の問題もあり、やはり汚れる速度が優っていた。

幸い、そのような仕上げをする人間が、新しく二人入ってきたので、妖怪ハウスは今、だいぶ綺麗になっている。

この新しく入ってきた二人は、料理も私より繊細に作る。あるいは、筆者の毎日妖怪ハウスで料理を提供するという役目も、そろそろ引き下がるべきかも知れない。私の料理は荒っぽいので、適任者がいれば譲った方がいい。

さて、現在、筆者が妖怪ハウスでとりかかっているのは、テントの設営である。妖怪ハウスには大きなベランダがあり、テントを設営するのに十分な面積を有している。去年の夏も、住人の中で、テントをはってみたいという声は上がったそうだが、その費用と労力のために断念したという。

そこで筆者は、今年の夏、妖怪ハウスに妖怪テントを設営して、そこで暮らしてみるつもりである。

さて、テントを設営するにあたって色々と調査を進めた。テント自体は安い。もちろん、よいテントは高いが、とりあえずお試しで、五千円ぐらいの安いNorth Eagle(ノースイーグル) イーグルミニドーム200IINE164 [2~3人用]を買った。いきなり高いものを買って失敗すると、金銭的損失が大きい。それに、いくら普通の家より大きなベランダを有しているからとはいえ、所詮ベランダであるので、それほど大きなテントは設置できない。このぐらいの大きさが無難であろう。

テントの設置場所となるベランダであるが、プランターが設置されていて、十分な面積を確保できない。そのため、まずプランターをどかした。これは、プランターの中に入っている土を一時的に動かして、プランターを動かし、さらに土を戻すという、結構な労力が必要であった。ただし、ものの一時間ほどで終わったので、それほどの作業量でもなかった。

さて、プランターを動かした後、筆者は思わぬ障害に出くわした。雨樋である。

なんと、テント設置予定場所に、雨樋が設置されていた。屋根の雨水をパイプでベランダに導いている。これはまずい。ここにテントを立てると、雨が降った時は、ベランダの地面が水浸しになってしまう。

さてどうするか。パイプを使って、雨樋を延長し、テントから離れた場所に放水するべきだろうか。

しかし、問題は雨樋だけではない。やはり数日テントを張るだけならともかく、一夏設営するのであれば、やはり雨水の問題は解決しなければならない。先人の意見を聞くに、やはりテントを長期運営すると、雨水が問題になるそうだ。テント設置場所の下に敷くシートや、上に張って簡易的な屋根にするためのブルーシートは買ってあったが、やはり、もうすこしマシな解決方法も必要になる。

地面からの浸水を防ぐためには、テントを地面から浮かす必要がある。そのためには、すのこ、あるいはパレットの上にテントを立てるべきだろう。簡単に手に入るすのこは、室内で布団の下に敷くためのもので、高さ、強度の点で、不満である。機能から言えば、パレットのほうが強力なはずだ。ただし、どこで買えるのか。値段はどうなのかというと、まだ調べがついていない。中古のパレットなら安いのだが、強度が心配だ。

さて、注文したテントはすでに届いているし、妖怪ハウスの一周年記念パーティのために、今日中に設置したいが、下に敷くものという点で、どうしようか迷っている。とりあえず今日はいい天気なので、一時的に設置してしまうのもいいかも知れない。

さて、本日行われる予定のパーティであるが、おめでたい日であるので、筆者は赤飯の作成に挑戦する予定だ。他にも、カレーやピザを、余裕があれば作ろうかと思っている。

妖怪ハウスは、あと何年続くだろうか。

2014-05-05

1980年代に不自由ソフトウェアを販売するということ

The Codist

1980年代に不自由ソフトウェアを販売する当時の事情が書かれている。

まず、当時はソフトウェアという概念自体が一般に知られておらず、出資を得るために説明するのが難しかった。

開発も、当然VCSなどという便利なものは存在しない。

インターネットがないので、雑誌でソフトウェアが酷評されても、反論すら難しい。

などなど。

2014-05-04

Google翻訳には秘密の特別版があるのか？

Does Google Have A Secret "Google Translate" Service?

公に公開されているGoogle翻訳と、GAndroidやChrome用のソフトウェア流通サイトに組み込まれているGoogle翻訳機能は、翻訳精度が違うというお話。

GoogleのGoogle翻訳は、おそらくオンライン翻訳サービスの最大手と言えるだろう。Googleは、このサービスを使って自動翻訳コンテンツを生成してオンライン上に公開するスパマーと戦っている。

このため、Google自身が自動翻訳コンテンツの利用者だというのは、驚きに値する。まず最初に気がついたのは、Google Playで、アプリ説明に自動翻訳を付けたことだ。後にChrome Web storeでも同様になった。

さらに興味深いことに、この翻訳はほぼ人間のように見えることだ。少なくとも、Google翻訳オンラインの結果よりは、人間らしく見える。これはいったいどういうことだ。まず観察して、それから考察してみよう。

観察：Google翻訳コンテンツ

これは翻訳されたコンテンツと検索マーケッターとGoogleに対する観察、あるいは、如何にして最近イディッシュ語がオンライン上で知名度を上げているかということ。

コンテンツを書くコストは、規模を拡大したいWebサイトにとって、とても重いものだ。たいてい、ロングテールなキーワードとか内容は、広告収入などのWebサイトのマネタイズに、簡単には反映されない。

このため、ここ数年、自動翻訳（たいていはGoogle翻訳を使用）されたWebサイトに出くわすことがよくあるのだ。翻訳結果は、一件素晴らしいように見えて、よくよく読めば拙いものである。

Webサイトが自動翻訳というダークサイドに堕ちた末に、オリジナルのコンテンツは、できるだけ多くの言語に翻訳されるようになった。

このため、コンピューターを使わない超正統主義派のユダヤ教徒の間でしか話されていないような、珍しいイディッシュ語の知名度が上がっているのだ。Google翻訳でイディッシュ語が提供されているがために、イディッシュ語がオンライン上で広がっていると、筆者は信ずる。

Googleは自動翻訳コンテンツを使うサイトにペナルティを与える

Googleは翻訳コンテンツと戦うために、二つの方法を用いている。AdSenseと検索だ。

検索：Googleは自動的に生成されたコンテンツを検出して、SPAMとして扱う。

AdSense：多くのサイトは、Google AdSenseを使って、コンテンツのマネタイズをしている。最近、多くの者が不満の声をあげていることには、Googleから「あなたのGoogle AdSenseアカウントが無効にされました」というメールを受け取ったということだ。その説明には、Googleは、「無意味なコンテンツや自動生成されたコンテンツをWebサイトが提供している」ことを検出したことにより、規約違反の可能性があるとのことだ。

Google翻訳は、自動生成されているがスパムではないコンテンツとして使うことができるか？

もし、Google翻訳が改良されれば、WebサイトはGoogleのガイドラインや罰則から逃れることができるわけだ。この可能性はあるだろうか。

そこで、筆者はあるアプリのオリジナルのテキストを、Google翻訳を使って、英語からスペイン語と、英語からヘブライ語に翻訳して、比較してみた。（Chrome Web storeの設定アイコンをクリックして言語を変えることで可能だ）

Googleがweb storeで使っている内部ツールは、公開されているオンラインツールより、いくつかの点で優れているようだ。これは自動翻訳を使う全員が注目すべきことである。

固有名詞の判定。Google翻訳は、ゲーム名(Parking Panic)を、同じ意味の用語（例えば、スペイン語では"Aparcamiento pánico"）に、間違えて翻訳してしまっている。まあ、例えば読者がAppleであったとしたら、ブランド名を"Manzana"（フランス語で果物のりんごの意）に翻訳されたくはないだろうし、この場合もそうだろう。

文法の性の判定。これもGoogle翻訳の問題だが、内部ツールには存在しない問題だ。ゲーム説明のヘブライ語翻訳は、「彼女は素晴らしいゲームだ」となるが、内部ツールは、ヘブライ語における文法の性を認識して、よりマシな「これは素晴らしいゲームだ」とする。

綴り間違い。Microsoft Wordは、内部ツールの翻訳に綴り間違いを一つしか発見しなかったが、公開ツールでは、二つの綴り間違いを発見した。

流暢性。内部ツールは、他にもいくつかの点で、公開ツールよりよい判断をしている。スペイン語とヘブライ語への翻訳では、みたところ、スペイン語翻訳は公開版でも良いのだが、ヘブライ翻訳は、内部ツールでようやくかろうじて読めるレベルになる。

なぜGoogleは持てる最高の技術を公開しないのか？

筆者の推測では、Gogoleは検出できないSPAMがあふれかえるのをおそれているのではないか。何にせよ、AndroidやChrome storeで公開できるほどであるとおもうならば、なぜGoogle翻訳で使えるようにしないのか。Google君、君の規約は我々を縛るが、その縛りはマウンテンビューにはないとみえるね。

Googleは、内部的にはもっと優れた翻訳技術を持っているが、何らかの戦略的理由で、公にはしていないのではないかというお話。

2014-05-02

Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子

Linus Torvalds - Google+ - One of the things I end up doing is do a lot of performance…

Linus Torvaldsが、最近のIntelのCPUは、通常以外の処理のコスト、つまりPage faultのコストが上がっているので、問題であるとしている。

俺はよくカーネルコードのパフォーマンスプロファイリングをやる。特に、VMとかファイルシステム周りに対してだ。

俺がよくやるのは、「うまくいってるとき」に対する計測だ。つまり、だいたいほぼ完璧にキャッシュされてる状況だな。というのも、俺はもちろんIOのことは気にかけているが、俺の個人的なワークロードはたいてい、うまくキャッシュされてるからだ。たとえば、俺にとってよくあるロードは、pullした後のフルカーネルビルドだ。これにどのくらいの時間がかかるかが問題になる。というのも、俺はまず取り込んだものが、基本的なテストをパスするのを確認した後でなければ、次のpullをしたくないからだ。

さて、カーネルビルドシステムは、実際の所、けっこう賢い。ほとんどのドライバーやアーキテクチャーのpullでは、コアヘッダーを書き換えないので、「全カーネルを再コンパイル」というのは、それほど大規模なビルドではない。大方は、「オッケー、依存してるヘッダーとファイルは変更されてないな。何もする必要がねーぜ」というチェックだけだ。

だが、これを何千ものヘッダーファイルと、何万ものCファイルで行うわけで、けっこう時間がかかる。フルビルドカーネル（"allmodconfig"なので、まあ大体フルビルド）で、「終わったぜ。pullは何もコンパイルする必要のある変更をしてなかったぜ」と言うだけでも、俺の普通のデスクトップでは、30秒はかかる。

まあ、30秒のallmodconfigは、それほどってわけでもない。だが、次のpullを始めるまでの待ち時間としては長すぎるし、コーヒーでも1杯といくには短すぎる。

要するに、うざいということだ。

そこで、俺はこのクソをぶっ殺すためにプロファイルしたが、半分ぐらいは、"make"が遅かった。これは、実際には、珍しいことに、カーネル由来のロードである。なぜならば、makeは大量のpathname lookupをしていて、けっこうな量の短命なプロセス（短いシェルスクリプトとか、"make"がfork/exitするとか）もやっているからだ。

従来、この手の問題の原因は、VFS pathname lookupで、もちろんいまだに大きな問題ではあるのだが、最近はそれだけの問題ではなくなっている。

最も大きいコストは何か？　CPUによるPage fault handlingさ。

この「CPUによる」という部分に注目してもらいたい。カーネルVMはよくやってるのだ。問題はPage faultのコストそのものと、（小規模だが）、page faultから戻る"iret"のコストだ。

この問題を特定するために、ちょっとしたテストプログラムを書いたが、その結果が興味深い。俺のHaswell CPUでは、page fault一回のコストは、約715サイクルだ。"iret"で戻るのは330サイクルだ。そのため、page faultとreturnは、約1050サイクルだ。このコストは多少の誤差があるかもしれないが、近い値だ。他のテストでは、1150サイクルあたりに計測された。だが、これにもっとノイズが大きいので、1050は最小コストとしてはありえるだろう。

なんでこれが興味深いかって？　カーネルソフトウェアが、ページを見つけてページテーブルに設定するためのコストは、はるかに小さいからさ。最悪の状況で（固定のzero-pageをマップしたばかりという、あからさまに作り上げた状況だが）、この1050サイクルは、全CPU時間の実に80.7%を占めるのだ。これは、カーネルもユーザースペースもpageをfaultさせるのにほとんど何もしていないという極端な例だが、俺の実際のカーネルビルドでは、全CPU時間の5%を占める。

古い32bitのCore DUoでは、俺のテストプログラムは、page faultオーバーヘッドは、80%ではなく、「たった」の58%だと計測している。これは、page faultが遅くなっているからだ（Core Duoのコストは、「たった」の700 + 240サイクルだ）

この問題の理由の一つとしては、Haswellは通常のコードでは改良されている（ので、faultオーバーヘッドが相対的に意識されやすい）が、コストが明後日の方向に向かっているのは、なんだかなぁ。

Intelエンジニアと話つけて、これを改良できるかやってみるか。

G+やHacker Newsのコメント欄では、ユーザースペースのビルドシステムの問題が指摘されている。

そもそもいまだに旧態依然のMakeを使っているのが問題なのだ。ビルドシステムに大量の小さなシェルスクリプトや、fork/exitのようなものが発生するから遅いのだ。例えばChromiumを見よ。規模はLinuxカーネルと同程度だが、まともなビルドシステムを使っているため、何もしないビルドは、数秒で終わるぞ。

といった意見だ。これに対しLinus Torvaldsは、

いや、そりゃ確かに、makeはブタでやりすぎだが、GNU makeの拡張機能や複雑な変数やらその他のよくわからんシェルエスケープやら何やらを駆使したところで、状況は改善しない。

だから、いわゆるmakefileコンパイラーが、この状況を最適化できるのは確かだ。だが、make代替品は自分でいくつも試してみた。imake, cmake, qmake, こいつらは問題の一部は解決しているが、やはり特有のクソさがある。

makeが超効率的になるのはありがたいが、俺としては、makeが必要とする部分のカーネルを最適化をしたいし、CPUに手間取ってもらいたくない。

というのも、まあ考えてみろ。たといカーネルビルドひとつ、超効率的になったとしてもだ、現実はそうじゃない。言っておくが、カーネルビルドでやっている「大量の小さなシェルスクリプトとか何とか」というのは、よそでもやっている現実のワークロードだ。page faultを最適化するのは、他のワークロードのためにも役立つのだ。

この話は、Old New Thingの記事を思い出した。

The hunt for a faster syscall trap - The Old New Thing - Site Home - MSDN Blogs

syscallトラップのパフォーマンスは興味深いものだ。

15年前[訳注：この記事が書かれたのは2004年なので、1989年頃]、IntelとMicrosoftと会議があった（残念ながら、私はこの会議に参加していなかったので、この話は伝聞なのだが）

Microsoftというのは、Intelの最大の顧客のひとつなので、Intelの代表はよくMicrosoftを訪問して、最新のプロセッサーを紹介したり、カーネル開発部に新しいプロセッサーの機能をサポートするようロビーしたり、どのような機能を追加すれば、もっとも役立つかという知見を吸い上げたりしていた。

この会議で、Intelの代表がたずねた。「でさ、たったひとつだけ、速くして欲しいところがあるとすれば、どこ？」

躊躇なく、カーネルの開発主任が答えた。「無効命令のfaultingの高速化」

Intel社員は笑い転げた。「いやぁ、Microsoftのエンジニアは愉快でいらっしゃる」というわけで、会議は冗談で締めくくられた。

研究所に戻った後、IntelのエンジニアがWindowsカーネルのプロファイルをしたところ、驚くなかれ、彼らはWindowsがかなりの時間を、無効命令例外をさばくためにつかっていることを発見したのである。何だと！　ひょっとして、Microsoftのエンジニアは冗談を言ったのではなかったのか？

冗談じゃない。

この当時の80386チップで、V86モードからカーネルモードに移行する最速の方法は、無効命令を実行することだったのだ！　そのため、Windows/386は、無効命令をsyscall trapに使っていたのであった。

この話の教訓？　よくわからない。たぶん、何か物を作ったならば、それが作成者の意図しない方法で使われるだろうということか。

立っている者は親でも使えとは、それこれこれを謂か。

ゲームスペース柏木でドミニオンをした

ゲームスペース柏木の毎週木曜日に行われている木ドミに参加して、ドミニオンをしてきた・・・と思う、たぶん。私の知るドミニオンとは、だいぶ趣が違ったのだが。

ゲームスペース柏木というのは、新宿区百人町1-24-7のタウンプラザ3Fにある、ゲーム用の部屋だ。極めてわかりにくい場所にある上、タウンプラザという建物自体がカオスだ。何やら小規模な店舗が多数入っている。

さて、新宿駅から明後日の方向に向かって進んだ挙句、途中でブックオフを発見してしまったので、やむを得ずして立ち寄った後、ようやく柏木に到着した。中では、4卓はドミニオン、1卓はアグリコラをしていた。

さて、ある卓でのプレイが終わったので、入れ替わりに入って、ドミニオンをした。

ドミニオンというのは、覚えやすいルールでありながら、選択の余地が大量にあって、大変面白いゲームである。筆者はまだ、数えるほどしか遊んでいないが、筆者の知るドミニオンとは、カードを迷いつつ買って、相手が悩んでいるのを待つゲームであったはずだ。

しかし、この空間におけるドミニオンは、筆者が知っているドミニオンとは、だいぶ様子が違った。

まず迷わない。皆、手番を即座に終えてしまう。

迷わない結果、待たない。筆者が手番を終えて、カードをシャフルして、5枚引いて、さてどうするかと考えつつ、ふと顔を上げると、すでに手番が一巡した後で、皆、筆者の手番を待っている状態であることがほとんどであった。

そして、ゲームも短時間で終わる。その終わり方も唐突で、一人が一瞬にして得点を得て、しかもゲームの終了条件を満たすような終わり方であった。

今日、筆者は初めて、ドミニオン、ガチ勢の戦いを目の当たりにしたのであった。筆者にとって、この卓は極めて場違いであり、存在を申し訳なくも思った。こういうガチ勢の戦いに初心者が混じっている場合の上級者の感じるいらだちは、筆者も経験上知っている。もちろん、ゲーム人口を増やすためにも、初心者と遊ぶことは重要であるし、紳士であれば、そのいらだちを表に出すことはないが、感じるいらだちは否定しようがない。ドラクエで例えれば、ゲームを開始してラダトーム城を出たら、りゅうおうがあらわれた　コマンド?　級の場違いさを感じた。

筆者は、ドミニオンのようなゲームは、あそこまでのめり込むほどの魅力を感じない。TCGの流れを組む、デッキ構築に、筆者はそれほど楽しみを覚えないのだ。デッキ構築という概念は、好きな人は好きで、特に、人が思いもよらないような戦略で勝つことを楽しみとする人までいる。

それにしても、このゲームスペース柏木という空間はどうなのだろうか。いわゆるコワーキングスペースに似通ったような空間ではあるが、これで利益が出ているのだろうか。興味深いところだ。

時に、今月の18日はカタン月例会だそうだ。ゴクリ。

2014-05-01

PCを置き換えるもの

Replacing the PC

なかなか興味深い考察を読んだので紹介する。

PC、すなわち、今のデスクトップやラップトップといった形のコンピューターを置き換える新しい形のコンピューターについて考察している。

PCを置き換えるのはタブレットだろうか。PCの売上が低迷しているなか、タブレットの売上はうなぎのぼりだ。

これは違う。なぜならば、タブレットの利用者の年齢層をよく見ると、オッサン、オバハン世代だからだ。アーリーアダプターが若い世代ではないというのは、いったいどういうことだ。

なぜタブレットはオッサン、オバハンに受け入れられているのか。それは、今のオッサン、オバハンは、コンピューターといえばデスクトップやラップトップから入ったので、その延長線上にある、タブレットを欲しがるのだ。用途は、ソファに座ってテレビを見ながらの操作だ。

では、時代を形成する今の若い世代は、何を使っているのか。スマートフォンである。今の若い世代にとって、コンピューターやインターネットとは、スマートフォンを意味するのだ。

ところで、タブレットとスマートフォンの新製品の傾向が興味深い。タブレットの大きさは、年々小さくなりつつある。逆に、スマートフォンの大きさは、年々大きくなりつつある。

これは、今のタブレットのサイズは、今より大きすぎるし、スマートフォンは小さすぎるためであろう。

すると、将来的には、タブレットとスマートフォンは融合して、ひとつの種類のコンピューターになるはずだ。

タブレットとは、ディスプレイとバッテリーの技術的な制約により生まれた一時的な産物に過ぎず、技術が進歩した将来は、タブレットとスマートフォンの区別がなくなり、それこそがポストPCなコンピューターであると結論している。

なかなか面白いが、スマートフォンやタブレットでは、まともにコードが書けないので、ポストPCなど幻想に過ぎない。

あるいは、将来、コンピューターの性能が極端に上がり、マウスもキーボードもディスプレイも何もかも、無線で接続できるようになるのかもしれないが。