Unityでunsafe codeは使えるか？
UnityのC#でのヒープvsスタックの話を書いてから、「unsafe codeが使えればもう少し簡単に高速化できる」というような話をいくつかいただきました。そこで問題となるのは、Unity環境でunsafe codeが使えるかどうか、ということです。
ちょこっと調べてみた限りでは、「Unity環境ではunsafe codeは使えない」というのが結論のようです。マニュアルに明記されてはいないのですが、「まあ使えないでしょ」みたいな書き込みがいくつか見つかります。
以前のバージョンではビルドスクリプトを書き換える事で対応が可能だったとか、そんな情報もありましたが、それもweb playerでは使えないとか、色々と制約があったようです。
10分ゲームプログラミング（構想）
「Unityを使って10分間でゲームを制作する」というネタを、ちょっと考えてみている。台本付きで作るなら、実はそれほど難しくないかもな、と思う。
上は試しに、おやつを食べながら30分間ぐらいで作ってみたメダルプッシャーゲーム。間を空けずに詰め込んで作業すれば10分に収まるのではないかな……
C#におけるヒープVSスタック問題、あるいはUnityにおけるスクリプト高速化。
個人的にC#はグルー言語であるという認識が強くて、パフォーマンスを意識したプログラミングの経験が無い。しかしUnityのスクリプトをC#で書いていると、そこを意識しなくてはならないケースに出くわすことがある。
最近あったのは、テンポラリな配列のアロケーションが大きなオーバーヘッドを生み出しているという状況だった。これは結局、配列の使用をやめてstructのメンバー変数にパックするよう変更したところ、パフォーマンスは著しく改善された。言い換えれば、テンポラリオブジェクトの所在をヒープ上からスタック上へと移すことによってオーバーヘッドが解消された、という格好だ。
問題となっていたのは、まあざっくりとこんな感じの、ゲームステートを保持するクラスだった。
public class State { byte[] cells = new byte[16]; public State() {} public State(State src) { src.cells.CopyTo(cells, 0); } public byte this[int i] { get { return cells[i]; } set { cells[i] = value; } } }
これをAIで処理する際に、大量のオブジェクトコピーと、比較的少量の書き換えアクセスが発生していた。ここでは似たような負荷を発生させるために、こんな感じのテストコードを使うことにする。
int pos = 0; State state = new State(); for (int i = 0; i < 1000 * 1000 * 10; ++i) { State temp = new State(state); int pos2 = (pos * 11 + 1627) % 1637; temp[pos & 0xf] = (byte)(temp[pos2 & 0xf] + 1); pos = pos2; state = new State(temp); }
このコードを手元のUnity環境で実行すると、終了までに約19秒かかる。
このコードが重いのは、メモリロケーションとオブジェクトコピーに問題があるのだろう。それは書いている最中から想像できたし、プロファイリングの結果もそれを示唆していた。それならばと、Stateクラスをこんな感じのstructで置き換えてみた。
public struct State { private uint cells0, cells1, cells2, cells3; public byte this[int i] { get { int sh = (i & 3) * 8; switch (i >> 2) { case 0: return (byte)((cells0 >> sh) & 0xff); case 1: return (byte)((cells1 >> sh) & 0xff); case 2: return (byte)((cells2 >> sh) & 0xff); default: return (byte)((cells3 >> sh) & 0xff); } } set { int sh = (i & 3) * 8; uint mask = ~(0xffU << sh); uint add = (uint)(value & 0xff) << sh; switch (i >> 2) { case 0: cells0 = (cells0 & mask) | add; break; case 1: cells1 = (cells1 & mask) | add; break; case 2: cells2 = (cells2 & mask) | add; break; case 3: cells3 = (cells3 & mask) | add; break; } } } }
大きな違いは、classではなくstructを使っていることと、配列ではなくメンバー変数を用意し、そこに値をパックしていること。これで、ヒープ上に確保されていたオブジェクトはすべてスタック上へと移ってくれるはずだ。
変更後のコードは0.6秒で終了した。30倍以上の高速化だ。これは極端な例だけれど、シンプルな処理を反復することの多いAIの内部ループでは、同様の対処によって高速化の望めるケースがあると思う。
Wikipediaの顔写真バナーの裏に潜む科学
The Information Is Beautiful - THE SCIENCE BEHIND WIKIPEDIA’S JIMMY APPEAL
最近、Wikipediaを閲覧していると、やたらとジミー・ウェールズの顔が出てきてウザ……いやいや、何と言うか、気になってしょうがない。この「創立者からのメッセージ」という形で顔写真を前面に押し出すスタイルのバナーは、とても良い効果があったようで、他のバナーと比較して高いクリックスルーレートや募金額を記録している。上のThe Information Is Beautifulの記事は、その結果をビジュアライゼーションしたものだ。
このビジュアライゼーションのソースとなっているのは、WikimediaのFundraising委員会がまとめているバナーテスト結果ページだ。Wikipediaでは様々なタイプのバナーを試験しており、このページには過去に試したバナーの内容とその結果がまとめられている。定量的なパフォーマンステストの結果と考察が集積されており、とても興味深い。
たとえば"donate now"と"please read"ではどちらの方がいいのか、画像の内容はどのように影響するのか、リンクだけの場合とボタンを加えた場合ではどのように異なるのか、メッセージの内容は真面目な方がいいのかユーモアがあった方がいいのか……等々。こういった舞台裏の部分が、見ようと思えば誰でも自由に見られる状態になっているというのは、なかなか面白いことだと思う。
MacBookの据え置き運用
導入前はスペックに不安を感じていたMacBook Air 11″も、現在はすっかりメインマシンとして活躍している。動画編集以外の作業はほぼすべて、このMBAの方で行っている。ここまで実用になるとは、正直なところ思ってもいなかった。
それで、今まで使っていたMacBook 13″の方は、常時クラムシェルモードで据え置きマシンとして使っていくことにした。
クラムシェルモードとは、MacBookを閉じたまま使うモードのことだ。この辺りの記事の解説が分かりやすい。
AdobeのツールやVirtualBoxなど、容量を食うソフトはこちらに入れて立ち上げている。iTunesのライブラリもこっちに入れてある。MBAはXcodeとUnityとLiveとiWorkだけ。普段の作業のほとんどはそれらのツールで完結しているから、それで済んでしまうというわけだ。
Tumblrを使いこなす人たち
Tumblrは色々な使い方のあるサービスだ。もっぱらreblog用のサービスという印象があるけれど、中には普通のブログとして使いこなしている人たちもいる。
Minecraftの作者のブログThe Word of NotchはTumblrを利用している。これは本当に普通のブログとして使っている例。ちゃんと使いこなしている感があってかっこいい。
他に僕が知っている例としては、ＵＩデザイナーのMax Steenergen氏のブログが、やはりTumblrを利用している。こちらは半ブログ、半リブログといった感じの中間的な雰囲気になっていて、これはこれで面白い。
現在、はてなダイアリーの使い勝手には少し不満があって、他のサービスへの移行をうっすらと考えている。WordPress.comが最も無難だろうと思っているのだけれど、Tumblrを使うというのも、ちょっと面白そうだ。
