もうちょっと真面目な光線追跡 [光線追跡エンジンを作る]
こないだ書いたようにある有名な光学設計ソフトが使えなくなった。僕は多群ズームなんか設計しないので、ほとんど使わないんだけど、仕事をする上で光線追跡して設計を評価することは必要になる。しかしその光学設計ソフトが使えていたこれまででもお客さんから「読めるデータを寄越せ」と言われたときに使っただけで、自分用にはずっと前Mathematicaで書いたのを必要になるたびごとに手を入れながら使うほうが多かった。
それはなぜかというと、汎用ソフトは僕にとって余計な機能ばっかりで痒いところに手が届きにくいのと、とくに評価結果をグラフにするときに、決まった形式でしか描けなくて一番的確な表現にならないのがもどかしいから。見慣れた人は複数枚のグラフから言いたいことを読み取れるんだろうけど、一枚に描いた方がわかりやすいのにそうならない、なんてことがある。そのプロットもビットマップしか出力できなくて見苦しい、というのもある。ようするにもともと気に入らなかった、ということなんだろうな、結局。
ところが、最近たくさん光線を飛ばさないといけない仕事ができた。Mathematicaに書いたのはマルチカーネルを意識せずに書いたので、非常に遅い。今からマルチに書き換えたとしてもせいぜいコア数倍になるだけで、1桁2桁速くするのは難しい。またどこでも実行できるわけではない。
ずっと前計画していたObjective-C版は作っただけでほったらかしになっていた。なぜかというと、Mathematicaには表示のためのグラフィクス描画機能や、数値計算のための関数が揃っていて、書き足すものは少なくてすむけど、Ojbective-Cで書いた光線追跡エンジンだけでは、その他にたくさんのものを書かないと使えないからである。
どのみち僕が使えればいいだけなので、勉強を兼ねてSwiftでやろうという気になってきた。また例によって収束するかどうかわからない「車輪の再発明」を始めようと考えはじめた．．．
それはなぜかというと、汎用ソフトは僕にとって余計な機能ばっかりで痒いところに手が届きにくいのと、とくに評価結果をグラフにするときに、決まった形式でしか描けなくて一番的確な表現にならないのがもどかしいから。見慣れた人は複数枚のグラフから言いたいことを読み取れるんだろうけど、一枚に描いた方がわかりやすいのにそうならない、なんてことがある。そのプロットもビットマップしか出力できなくて見苦しい、というのもある。ようするにもともと気に入らなかった、ということなんだろうな、結局。
ところが、最近たくさん光線を飛ばさないといけない仕事ができた。Mathematicaに書いたのはマルチカーネルを意識せずに書いたので、非常に遅い。今からマルチに書き換えたとしてもせいぜいコア数倍になるだけで、1桁2桁速くするのは難しい。またどこでも実行できるわけではない。
ずっと前計画していたObjective-C版は作っただけでほったらかしになっていた。なぜかというと、Mathematicaには表示のためのグラフィクス描画機能や、数値計算のための関数が揃っていて、書き足すものは少なくてすむけど、Ojbective-Cで書いた光線追跡エンジンだけでは、その他にたくさんのものを書かないと使えないからである。
どのみち僕が使えればいいだけなので、勉強を兼ねてSwiftでやろうという気になってきた。また例によって収束するかどうかわからない「車輪の再発明」を始めようと考えはじめた．．．
Xcodeが勝手に12.3に [日常のあれやこれや]
さっきXcodeで書いてたら、急にコンパイルできなくなった。エラーの内容がよくわからなかった。必要なものがパスにない、というメッセージがずらずら並んでいる。OSそのもののsdkもないという行があった。なんでやねん。自分のアプリバンドルの中にあるのに。
調べると、Xcodeを開いてるにも関わらず12.3がインストールされてファイルが中途半端に置き換わっていた。ひでえ。なんでそんなことするの。やるなら閉じてるときにしろよ。ってここんとこずっと開きっぱなしか。でもそうなら、通知で「新バージョンがあるよ」ぐらいの表示しろよ。理由がわからんから焦ったがな。
これって僕だけ？
調べると、Xcodeを開いてるにも関わらず12.3がインストールされてファイルが中途半端に置き換わっていた。ひでえ。なんでそんなことするの。やるなら閉じてるときにしろよ。ってここんとこずっと開きっぱなしか。でもそうなら、通知で「新バージョンがあるよ」ぐらいの表示しろよ。理由がわからんから焦ったがな。
これって僕だけ？
Brad Mehldauが面白い [ジャズ]
先々週くらいからBrad Mehldauというピアニストばっかり聴いてる。僕はアンテナ超低いジジイなのでこれまで知らなかったが、世間ではけっこうな人気らしい。いや、知らなかったというのはウソでもう何年も前、女房が「面白いから」と僕に聴かせたらしいんだけど、僕はちょっと聴いて「難しいことをすればいいと思ってる」とかなんとか否定的なことを言ったようで、女房はそれからCDを買ったりYouTubeをチェックしたりと、一人でやってたらしい。それも僕は知らなかった。
去年トリオで来日したとき（もちろん僕は知らなかった）女房は聴きに行こうとしたんだけど、僕が興味を示さなかったのと、サントリーホールの大ホールでのコンサートだったので、結局やめたという。ジャズのトリオなんかもっとデッドな環境で聴かないとなにやってるかわからない、ということだった。
たまたま僕がなにかで聴いて面白いというと、女房は「今さら何言ってるの？」と言って手持ちのCDなんかを貸してくれた。それからずっと聴いてる．．．．
去年トリオで来日したとき（もちろん僕は知らなかった）女房は聴きに行こうとしたんだけど、僕が興味を示さなかったのと、サントリーホールの大ホールでのコンサートだったので、結局やめたという。ジャズのトリオなんかもっとデッドな環境で聴かないとなにやってるかわからない、ということだった。
たまたま僕がなにかで聴いて面白いというと、女房は「今さら何言ってるの？」と言って手持ちのCDなんかを貸してくれた。それからずっと聴いてる．．．．
Apple Siliconで動作するエミュレータの常設化? [日常のあれやこれや]
先日M1のFirestormコアはマイコロコードを使っていないと考えた。そしておそらく32ビット命令は実行できない。しかしARM版のWindows10は動く（ただしQEMU上）そうなので、M1ではarm64命令をいちおう全部実行できるようになっているんだろう（QEMUをXcode12ですべてコンパイルしなおしたらわからんか。そうしたんだろうか）。
しかしそのとき考えたように、AppleはコンパイラからCPUからOSから全部取り仕切っているので、ARMの互換性にこだわる必要はない。ARMのライセンスはレベルがいくつかあってその詳細を理解してないんだけど、CPUとしてARMライセンスに依存しないといけない部分が残ってなければ、Appleは自分たちに都合の良いようにするだろう。これまでも後方互換性をあっさり捨ててきた。おかげで何度も泣かされたわけだけど。
昔のPowerPC上の68LC040（浮動小数点ユニットなしの68040）エミュレータから、Rosetta（x86_64上のPowerPC）と、今回のRosetta2（ARM64上のx86_64）でCPU命令のエミュレーションはAppleの十八番（オハコ）になってる。マイクロコードを実装するのに比べたらソフトウェアエミュレータのほうが自由度が高くて複雑さや規模の問題も少ない。マイクロコードで互換性を取るのではなく、エミュレータで吸収する方があとあといいはずである。
エミュレータの実行コードの一番厳しい部分がL1キャッシュに収まってしまえば、もとはバスを隔てたソフトウェアだけど、マイクロコードにせまる効率が出るだろうし、一番内側のループがディスパッチャのバッファに収まれば、実質的に書き換え可能なマイクロコードと言ってもいいくらい（VAX11/780を思い出すな。ブートはまずマイクロコードをロードするところから始まった）。ずっとまえ68020の256バイトしかないキャッシュにFFTのループを僕が詰め込むことができたくらいだから、630エントリ（実行コードで2520バイト分）もあればけっこういろんなことができるはず。
エミュレータのオーバーヘッドを上回る高速化がCPUで可能なら命令セットを変更しても、すなわちARM64のさらなるRISC化か、あるいは逆にAppleが有用と考える命令の追加や置き換えになるけど、Appleなら迷惑のかかる範囲は少ないし、ユーザはむしろ歓迎するだろう。
まあ、もともとARM64はARM32とビットパターンレベルでは互換性がないしARM32にあった条件実行なんかも捨てていて（捨てないと32ビット固定長におさまらなかったらしい）、ARM64だけだと十分筋肉質だと言えるので、x86と違ってサポートする命令を減らしたからと言って面積が減るようなものでもなさそうである。でもエミュレータを単にアーキテクチャの橋渡しとして使い捨てるのではなくて、ハードウェアをサポートするもっとも低レベルのソフトウェア要素にする、というのは十分ありそうな気がする。iMacに32コアなんて話もあるぐらいなので、Firestormコアのパフォーマンスを落とさずにその面積を減らす、というのはばきばきに検討してるはずだと思う（32コアを使い倒せるプログラミングも並大抵じゃない気がするけど）。
なんかこないだから僕はM1のことばかり気にしてるな。酸っぱいはずじゃなかったっけ。
しかしそのとき考えたように、AppleはコンパイラからCPUからOSから全部取り仕切っているので、ARMの互換性にこだわる必要はない。ARMのライセンスはレベルがいくつかあってその詳細を理解してないんだけど、CPUとしてARMライセンスに依存しないといけない部分が残ってなければ、Appleは自分たちに都合の良いようにするだろう。これまでも後方互換性をあっさり捨ててきた。おかげで何度も泣かされたわけだけど。
昔のPowerPC上の68LC040（浮動小数点ユニットなしの68040）エミュレータから、Rosetta（x86_64上のPowerPC）と、今回のRosetta2（ARM64上のx86_64）でCPU命令のエミュレーションはAppleの十八番（オハコ）になってる。マイクロコードを実装するのに比べたらソフトウェアエミュレータのほうが自由度が高くて複雑さや規模の問題も少ない。マイクロコードで互換性を取るのではなく、エミュレータで吸収する方があとあといいはずである。
エミュレータの実行コードの一番厳しい部分がL1キャッシュに収まってしまえば、もとはバスを隔てたソフトウェアだけど、マイクロコードにせまる効率が出るだろうし、一番内側のループがディスパッチャのバッファに収まれば、実質的に書き換え可能なマイクロコードと言ってもいいくらい（VAX11/780を思い出すな。ブートはまずマイクロコードをロードするところから始まった）。ずっとまえ68020の256バイトしかないキャッシュにFFTのループを僕が詰め込むことができたくらいだから、630エントリ（実行コードで2520バイト分）もあればけっこういろんなことができるはず。
エミュレータのオーバーヘッドを上回る高速化がCPUで可能なら命令セットを変更しても、すなわちARM64のさらなるRISC化か、あるいは逆にAppleが有用と考える命令の追加や置き換えになるけど、Appleなら迷惑のかかる範囲は少ないし、ユーザはむしろ歓迎するだろう。
まあ、もともとARM64はARM32とビットパターンレベルでは互換性がないしARM32にあった条件実行なんかも捨てていて（捨てないと32ビット固定長におさまらなかったらしい）、ARM64だけだと十分筋肉質だと言えるので、x86と違ってサポートする命令を減らしたからと言って面積が減るようなものでもなさそうである。でもエミュレータを単にアーキテクチャの橋渡しとして使い捨てるのではなくて、ハードウェアをサポートするもっとも低レベルのソフトウェア要素にする、というのは十分ありそうな気がする。iMacに32コアなんて話もあるぐらいなので、Firestormコアのパフォーマンスを落とさずにその面積を減らす、というのはばきばきに検討してるはずだと思う（32コアを使い倒せるプログラミングも並大抵じゃない気がするけど）。
なんかこないだから僕はM1のことばかり気にしてるな。酸っぱいはずじゃなかったっけ。
肉眼で回転運動に対するストロボ効果はあるのか？ [日常のあれやこれや]
さっき「チコちゃんに叱られる」の再放送を見ていたら、「走行中のタイヤが止まったり逆回転に見えるのはなぜ？」の答えに「1秒間に4〜5枚の絵しか見てないから」というのがあった。これは普通は、いわゆるストロボ効果によるものがほとんどで、つまりカメラでの動画か、間欠照明があった場合にはっきり見える。物理的には折り返しノイズの具体例である。
番組ではそれを人間の目の特性だけで説明していた。それはおかしいと思う。
直線運動に対しては目のサッケード運動（衝動性眼球運動）と連動したとき、網膜上の画像が固定されて止まって見えることがある。これは直線運動している物体に注目してはっきり見ようと眼球や頭を意識的に動かすことで目のモーションブラー を止めるのや、鶏が歩くとき首を前後に振る動作と同じである。サッケード運動はすごく速くて像運動と連動したときは無意識的なので、止まって見えると印象に残りやすい。でもサッケードは意識的にはできないのでいつも見える、ということにはならない。
しかし眼球には光軸周りの回転の自由度はない。眼球運動用の筋肉は光軸に沿った方向にしかないし、もし回転したら太い視神経が捩れてしまう。視神経は脳までの距離が短いけど、やっぱり最終的には化学的な作用なので応答速度はせいぜい10msecぐらいのはずだし、また１つの視神経はフォトン1個に反応できるとは思えないので、ある程度の積分時間が必要なはずである。そして目にはCCDやC-MOSイメージャの電荷蓄積タイミング制御のような機能はない。したがってそれ以下の時間分解能は目にはない。つまり、回転している物体は、脳で処理される前に網膜上の画像としてボケる。
だから、カメラ越しではなく、間欠照明もない場所での肉眼で回転運動に対してストロボ効果が発生するとは思えない。肉眼で見えたというのはどこかに発光が電源（あるいはそのインバータ）に同期してしまうナトリウムランプや蛍光灯があることに気が付いてなかったのではないか、と思う。
もし、そうではない、という人がいたらコメントください。例えば「私の脳は網膜像のデコンボリューションができる」とか。
でも最近チコちゃんあまり面白くない。マンネリはしょうがないか。でも「逆連想ゲーム」は退屈で、どうせなら「とことん妄想ゲーム」とかのほうがいい。いやそれは、小さいおともだちに見せられなくなるか。
番組ではそれを人間の目の特性だけで説明していた。それはおかしいと思う。
直線運動に対しては目のサッケード運動（衝動性眼球運動）と連動したとき、網膜上の画像が固定されて止まって見えることがある。これは直線運動している物体に注目してはっきり見ようと眼球や頭を意識的に動かすことで目のモーションブラー を止めるのや、鶏が歩くとき首を前後に振る動作と同じである。サッケード運動はすごく速くて像運動と連動したときは無意識的なので、止まって見えると印象に残りやすい。でもサッケードは意識的にはできないのでいつも見える、ということにはならない。
しかし眼球には光軸周りの回転の自由度はない。眼球運動用の筋肉は光軸に沿った方向にしかないし、もし回転したら太い視神経が捩れてしまう。視神経は脳までの距離が短いけど、やっぱり最終的には化学的な作用なので応答速度はせいぜい10msecぐらいのはずだし、また１つの視神経はフォトン1個に反応できるとは思えないので、ある程度の積分時間が必要なはずである。そして目にはCCDやC-MOSイメージャの電荷蓄積タイミング制御のような機能はない。したがってそれ以下の時間分解能は目にはない。つまり、回転している物体は、脳で処理される前に網膜上の画像としてボケる。
だから、カメラ越しではなく、間欠照明もない場所での肉眼で回転運動に対してストロボ効果が発生するとは思えない。肉眼で見えたというのはどこかに発光が電源（あるいはそのインバータ）に同期してしまうナトリウムランプや蛍光灯があることに気が付いてなかったのではないか、と思う。
もし、そうではない、という人がいたらコメントください。例えば「私の脳は網膜像のデコンボリューションができる」とか。
でも最近チコちゃんあまり面白くない。マンネリはしょうがないか。でも「逆連想ゲーム」は退屈で、どうせなら「とことん妄想ゲーム」とかのほうがいい。いやそれは、小さいおともだちに見せられなくなるか。
Recursive enumerationを使った電卓プログラム（四則演算しかできないけど） [Swiftプログラミング]
仕事の合間にSwiftの勉強をしてるんだけど、ちんたらやってるとSwift本体の方がどんどん新しくなって追いかけるのに苦労する。最新のSwift 5の勉強をしようと思って、Appleのドキュメントをみていた。Opaque typeとか、＠で始まるAttributesとか、必要性はわかるんだけど自分で使うかどうかよくわからない機能が多い。SwiftUI関連の拡張（SwiftUIを理解せずに言語仕様だけ追っても何がやりたいんだか全然わからない）も多くてフォローしたいんだけどまだそんなところではない。
その中で、今日たまたまRecursive enumeration（再帰的列挙）を知った。これはSwift 5で新しく導入されたものではなくて、その前からあったらしいんだけど、僕は知らずにいた。
これまでSwiftではバイナリツリーみたいな構造はclassでないとできないと思ってたんだけど、これを使えばenumでできる。ちょっと手に馴染ませるために簡単なものを作ってみようと思った。とりあえずこのドキュメントの下の方の「Recursive Enumeration」にあるArithmeticExpressionを拡張して四則演算できるようにしてみた．．．．
その中で、今日たまたまRecursive enumeration（再帰的列挙）を知った。これはSwift 5で新しく導入されたものではなくて、その前からあったらしいんだけど、僕は知らずにいた。
これまでSwiftではバイナリツリーみたいな構造はclassでないとできないと思ってたんだけど、これを使えばenumでできる。ちょっと手に馴染ませるために簡単なものを作ってみようと思った。とりあえずこのドキュメントの下の方の「Recursive Enumeration」にあるArithmeticExpressionを拡張して四則演算できるようにしてみた．．．．
FirestormコアのALU [日常のあれやこれや]
Apple SiliconのM1のブロックダイアグラムの推測を見た先日の記事で「それ以外のALUはマイクロコードで実行か」と書いたけど、おそらくそれは間違いで、マイクロコードの必要はないな。FirestormコアにはALUが8個あるけど非対称で、整数の割り算や掛け算のできないユニットがある。つまりそのALUはフラグ操作とシフトと足し算しかできないので掛け算割り算はマイクロコードになってるのかと思った。
でもよく考えると（よく考えないでも）ディスパッチユニットに収まった時点で演算の中身はわかっている。その命令に関係するレジスタ名が割り当てられて実行可能になったとき、演算の内容によってALUを選べばいいだけだもんな。それが塞がってた場合も実行起動条件の判断と同じだもんな。マイクロコードで面積を増やしても掛け算の頻度から考えて7つのALU全部が掛け算を実行している場面はほとんどありえないから、演算種類の出現頻度の比で何を実装するかを決めればいい。したがってFirestorm側はマイクロコードは使ってないということだ。
低電力消費のIcestormはどうなってるんだろ。割り算までできるやつと掛け算までと足し算だけとブランチユニットの4つでSIMDがひとつだけとか。それだけでは消費電力はせいぜい半分で、すごく違う、とかいうとこまでいかなそうだよな。これもマイクロコードにしたからと言って面積は小さくなるけど遅くなって1命令あたりの消費電力は上がるもんな。それぞれ4つのFirestormとIcestormがチップ面積比で3：1ぐらいでキャッシュサイズも12MBと4MBなので、それに比例するぐらいもっと違うのかな。並列デコーダや大量のrenamingバッファに比べたら足し算ALUの面積なんて、シフトができる必要もないので、たいしたことないかもしれない。
そもそもFirestormとIcestormで性能比と消費電力比はどのくらいなんだろうか。性能比：消費電力比=1だとクロックを落としたり場合によっては止めたりすれば同じで、作り分ける意味ないもんな。
いやいや、もうどうでもいい。MBPは買ったばっかりだし、会社で使ってた6コアiMacもうちに運んだし、しばらくM1 Macを買うことはないもんな。
え〜ん、M1 Macなんかいらないやい。きっと酸っぱいに決まってる。
でもよく考えると（よく考えないでも）ディスパッチユニットに収まった時点で演算の中身はわかっている。その命令に関係するレジスタ名が割り当てられて実行可能になったとき、演算の内容によってALUを選べばいいだけだもんな。それが塞がってた場合も実行起動条件の判断と同じだもんな。マイクロコードで面積を増やしても掛け算の頻度から考えて7つのALU全部が掛け算を実行している場面はほとんどありえないから、演算種類の出現頻度の比で何を実装するかを決めればいい。したがってFirestorm側はマイクロコードは使ってないということだ。
低電力消費のIcestormはどうなってるんだろ。割り算までできるやつと掛け算までと足し算だけとブランチユニットの4つでSIMDがひとつだけとか。それだけでは消費電力はせいぜい半分で、すごく違う、とかいうとこまでいかなそうだよな。これもマイクロコードにしたからと言って面積は小さくなるけど遅くなって1命令あたりの消費電力は上がるもんな。それぞれ4つのFirestormとIcestormがチップ面積比で3：1ぐらいでキャッシュサイズも12MBと4MBなので、それに比例するぐらいもっと違うのかな。並列デコーダや大量のrenamingバッファに比べたら足し算ALUの面積なんて、シフトができる必要もないので、たいしたことないかもしれない。
そもそもFirestormとIcestormで性能比と消費電力比はどのくらいなんだろうか。性能比：消費電力比=1だとクロックを落としたり場合によっては止めたりすれば同じで、作り分ける意味ないもんな。
いやいや、もうどうでもいい。MBPは買ったばっかりだし、会社で使ってた6コアiMacもうちに運んだし、しばらくM1 Macを買うことはないもんな。
え〜ん、M1 Macなんかいらないやい。きっと酸っぱいに決まってる。
