2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
KOBA789氏(以下、KOBA789):シミュレータができたので、次はCADを作っていきます。書いた回路図がそのまま動くCADがなかなかないので、私はCADに書いた回路図がそのまま動くことを一番求めていました。
大抵の場合、回路を書くCADとシミュレータが別々になっています。まじめな回路を組むのであればそのほうが楽なのですが、だいたいタイミングチャートのかたちで表示されるんですよね。
プローブをいろいろなところにくっつけて、そのプローブの値が時間経過でどうなったかというタイミングチャートがバーッと出るわけです。たくさんのピンの状態、配線の電位の状態を俯瞰するという意味では、時間方向でも見られるので非常にいい表示方法なのですが、私はリアルタイムにガチャガチャ動いている様子を画面上で見たい。動いて触れる回路図がほしかったので、そのように作ることにしました。
さらに、できればその動作は60fpsでヌルヌル動いてほしいんです。紙芝居みたいな画面が出てきて、ガッチャガッチャとなってるとやっぱり興醒めなわけです。実物は60fps以上で動くので、モニターが60fpsなのはしょうがないとして、そのモニターのハードウェア限界では動いてほしいんです。
これからCPU作ろうと言ってるので、小さい回路だけしか動きませんは話にならないのでね。回路規模が大きくなってもシミュレーションをなめらかにしたいと考えています。
いまどきGUI(Graphical User Interface)を作るといったらたぶんブラウザなんですよ。私は得意なのでよくブラウザで作るのですが、そうするとReactとTypeScriptでバーンみたいな感じになります。
回路図みたいに描画する要素がメチャメチャ増えるとDOMでは遅すぎるし、さっき60fpsで動かすとか言ったし、しかもシミュレーションしている最中は回路中のいろいろなものの状態が目まぐるしく変わるので、それを書き換えて回る必要もある。
TypeScriptやJavaScriptで座標計算をしまくるコードを実際に書いたのですが、あまりにキツいんですね。演算子のオーバーロードがないので、ベクトルとベクトルの足し算ですらメソッド呼び出しになってしまいます。カッコとメソッド呼び出しのドットがメチャメチャ大量に出てきて非常にキツいコードになります。
目に悪すぎて開発意欲をメチャメチャ削いでくるし、遅いのでこれはなしとなりました。
そんなわけでRustとWebAssemblyでWebGLだ! という結論になりました。メチャクチャな感じになってきたのですが、こういうアーキテクチャにします。
WebGLを一応説明しておくのですが、JavaScriptからOpenGLのようなものが叩けるAPIです。ウィンドウの中のOpenGLのコンテキストがごそっと取れて、それに向かってOpenGLのコマンドをJavaScriptから発行できるのが、WebGLです。
そんな設計なので、余計なものがぜんぜんなくて速いです。ほぼOpenGLが露出しているのはいいこともあるのですが、悪いこともあります。JSのようなスクリプトの言語との相性が最悪です。これをJSで使う人はかなり忍耐力があると思います。私は忍耐力がなかったのでRustで使うことにしました。
OpenGLに詳しい方はわかると思うのですが、速くて最高だと思われたWebGLは、三角形を塗りつぶすことしかできません。円とかが書けないし、線分も三角形を2枚使うし、なんなら文字も書けないし非常に不便極まりないです。
CADに使うにはちょっと機能が足りてなさすぎるんじゃないの? という感じですが、気合いで全部実装しました。
いわゆるGPUを直接叩くGUIの設計はいろいろな種類があるのですが、今回採用したのはImmediate mode GUIというタイプのアーキテクチャです。これはどういうものかというと、60fps、1秒間に60回全フレームを1から描き直します。
256×256のビットマップで画面を区切って、その領域が再描画されていなかったらそこのビットマップは使い回す、という賢いことは一切しません。
一切せずに、毎回毎回1秒間に60回やっているにもかかわらず1秒間に60回すべての画面を描き直しています。このアーキテクチャはゲームエンジンと非常に相性がいいことで知られています。なぜならゲームは60fpsで毎回描き直しているからです。
Dear ImGuiとかUnityのIMGUIとか、みんなImmediate mode GUIのライブラリにIMGUIと名前を付けちゃいがちですが、こういうライブラリが有名です。今回のCADでもこのアーキテクチャを採用していて、Dear ImGuiのコードをだいぶ参考にしました。
やっぱり気になるところは毎フレーム描いたら遅くないのかということなんですが、実は現代のGPU自体はメチャメチャ速いんですよ。メチャメチャ速いんですが、それでも動きがカクついたりすることがあるじゃないですか。
あれは何かというと、GPUはCPUからのRPCで操作しているのですが、そのRPCのコマンド発行で時間を食っているんですね。無駄にCPUが待たされていたり、GPUが遊んでいたりして、それで無駄に時間を食って遅くなっています。
なので、コマンド数自体を削ればアホほど速くなります。1フレーム描く時にドローコールという最後に画面を描画するコマンドがあるのですが、今回はこいつの回数を1フレームあたり1回に抑えることによってメチャメチャ高速化しています。
ここからデモします。これはシミュレータの動きをデモするためだけに作ったどうしようもない回路です。今何が起きているかというと、接点、コイル、接点、コイルと互い違いに全部並んでいます。
ここに再生ボタンがあるのですが、こいつをバチっと押すと、端から順番にスイッチが入っていって、この30番目までダラダラダラダラっとドミノ倒しみたいになります。
やってみます。ここのスイッチは人間が押さなきゃいけないので押します。カチッ。ダラダラダラダラ……丸が端から順番にダラダラダラダラってこんな感じになっています。
これおもしろいのが、ここのINと書いてあるやつをR30にして、こいつを逆向きにすると、振動するようになるんですね。R30がスイッチオンするとここの接点が切れるので、今度は端から切れ始める。
やってみますよ。ピッ。こういう動きをします。この動作の遅さと、接点がパチパチ動いているこの感じが電磁リレーの醍醐味です。
最後にもうちょっとコンピューターっぽいことをやって終わりにします。こちらは全加算器です。こちらに入力A、B、こちらにOutがあるのですが、このAを1個入れるとこれがOutなのですが、今はゼロなのでビットが立っていません。Aに1個入れるとビットが立って、Bにも入れるとOutは消えてCarryが上がります。同時に負論理も一緒に出ているのですが、Carryが上がりました。
ここにCarryを突っ込むと、Outも上がって2ビット立った状態で全加算器ができています。こういう回路になっています。
というわけで、私の発表は以上になります。ありがとうございました。
司会者:ありがとうございました。質問が何点かあるのでお伝えします。まずこの描画は、SVGではダメなんですか? というコメントがありました。
KOBA789:たぶんSVGでもある程度の規模まではいけるはずで、かつ、SVGのほうが絶対に実装は楽です。ただ、配線の本数が何十万になってくるとおそらく厳しいというのがあってやめています。
あとSVGにしてしまうと、回路CADの中で持っている内部の回路図のデータ構造と、SVGの表示のためのデータ構造をいちいち同期する丁寧なコードを書かなきゃいけなくなります。そのプログラミングがちょっと面倒なんですね。
今回Immediate mode GUIにした理由がもう1つあります。回路CADの内部状態を毎度毎度、描画命令にバカ正直に全部トランスレートしてあげれば、確実に整合性の取れた表示ができます。そこがやっぱり利点かなと思っています。
司会者:うんうん、コードもシンプルにやるということですね。あと技術的な質問ではないのですが、なぜ小学生の時にリレー300個も買ったんですか? という質問もありました。
KOBA789:当時から電磁リレーで計算機を作りたかったんです。なので実は夢がまだ20年弱ほど叶っていないということですね。
司会者:意外と長年だった(笑)。あともう1つ、やっぱりみんなこのパチパチのCADを見て、「リレーの音が聞こえてくる」「音が鳴ってほしい」と。サウンド再生してほしいというコメントが大量に来ていたので、見事に意図が伝わっているんじゃないかなと思いました。
KOBA789:本当はWeb Audio APIで音が鳴るところまで仕込みたかったのですが、ちょっと実装が間に合わなかったので、そこは近いうちに実装しておもしろ動画を投稿しようと思います(笑)。
司会者:WebGLはWebAssemblyから直接触れるという理解で合っていますか? というコメントがありました。
KOBA789:直接ではなくて、OpenGLのようなAPIにもかかわらず1回JavaScriptの世界を通すことにはなります。JavaScriptの世界を通る部分は、さっき言ったGPUへのコマンド呼び出しの部分だけです。そのコマンド呼び出しも、そもそも重い処理なので、あまりオーバーヘッドにはならない感じになっています。
司会者:HDLみたいなものは作らないのですか? というちょっとふわっとした質問がきています。
KOBA789:HDLは、効率良く設計するにはいいんですが、楽しくないんですね。動きを見る場合には、やっぱりこうやって整列された回路図があったほうがパーツの位置関係がわかるので、見て楽しいんです。視覚的に。
HDLで書いてしまうと、HDL自体には2次元や3次元でのレイアウトの情報はありません。書きやすいんですが、やっぱり楽しくないので(笑)。趣味でやっている以上楽しくないといけないので、こういうふうにしています。
司会者:ありがとうございます。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには