まだ、同人ゲームの本格的な製作に入れていないと言う発表みたいなものですがｗ
EntisGLS4s の実行プラットフォームである
Sakura2VM（仮想マシン）の性能（の一面）を見てみるサンプルコードを書いたのでちょっと手持ちの環境で色々実行してみました。（サンプルコード
はEntisGLS4sに同梱するために作っているもので、リリースの段階での性能は異なっている可能性があります）
まず、表中の数字ですが単位はMFLOPSで、4x4の行列に4次元ベクトルを掛けて4次元ベクトルを得る演算を連続的に行って（シングルスレッド）、掛かった時間から実効的な処理能力を求めています。
各行は実行したCPUとバイナリを表していて、「JIT
SSE2」はSakura2仮想マシンのコードをSSE2コードに変換して実行した場合、同様に「JIT 486」は486互換コード、「no
JIT」は逐次実行した場合、「x86 binary」はC++でそのままコンパイルしたネイティブコードです。
各列はソースコードとコンパイルの違いを表していて、ccodeはC++のソースを詞葉コンパイラでコンパイルしたSakura2仮想マシンコード、
「x86 MS-C++」の「optimized」「no
optimized」は同じソースをMS-C++でコンパイルしたバイナリです。「simd32」と「simd64」はSakura2仮想マシン用に詞葉
インラインアセンブラでで記述したコードで、simd32はSakura2仮想マシンの128ビットSIMD命令を利用します。simd64はインライン
アセンブラを使用しますが、通常の64ビット浮動小数点命令を使用しています。但し、JITコンパイルする際にペアリングされ、SSE2ではmulpd、
addpd命令で実行されます。
色々違うCPUで実行するとCPUの傾向が違っていて面白いです。
まあ、それ以前に大量の頂点処理やピクセル処理をする場合には、JIT SSE2 じゃないと速度的に色々ヤバイなって感じはしますが。（初めからそのつもりで作ってはいるのですがｗ）
あと、SSE2でのsimd32は、この倍位の数値が出る予定だったのですが、こんなもんなのでしょうか？
x86 binary の方は x87 FPU コードなのですが、私の経験則としてこのような行列演算ではSSEでもFPUでも速度が違わないということがあったので、きっとこんなものなのでしょう。
一方で、ピクセルなどの飽和を伴うような整数演算ではかなり差が出ると思います。（Sakura2のインラインアセンブラで記述した方が速くなると思います、多分）
それにしても、Atom Z540 は一体何なのでしょうｗ
こんなに浮動小数点演算に癖のあるCPUだとは思っていませんでした。
特に、x86 binary
の最適化有り無しで速度が変わらないのが笑えます。もちろんその理由は簡単に推測出来るのですが…。つまり、Atomは古典的（486やP5アーキテク
チャ）な実行のされ方をするので、FPU命令は同時に複数実行されることがまずない。一方で、浮動小数点演算が終わるまでの間、その次にある整数命令はど
んどん実行できる。結果、最適化しなくてもFPU命令の間にある整数命令などが隠れて見えなくなるということでしょう。
あと、SSE2での倍精度浮動小数点演算の遅さは………Atomはやる気が無いのでしょうか？ｗ
目に見える更新が出来ないのが辛いです。
同人活動ですが、今年の冬コミには申し込む予定です。
夏コミや今度のコミティアには出ません orz
大体、何を出すかは決まっているのですが、まだ全く見せられる段階にありません。ただ、冬コミでは新作をリリース予定です。
当面は EntisGLS4s を早く形にすることが目標になります。
春に公開とか言っていたよう気がしますが、きっと来年の事ですよ（ぇ
EntisGLS4s はようやく上位層のコーディングが出来るような段階にさしかかりつつあって、気持ちが結構明るくなってきました。（今まで砂漠の中を走っているような感じで、欝気味でした）
当初は EntisGLS3 と詞葉の旧コードの遺産をそれなりに引き継ぐつもりだったのですが、結局、殆ど新規に書き起こすことになっていました。現状10万行ほどあります。（EntisGLS3 はおよそ30万行）
冬コミの出し物ですが、EntisGLS4s のサンプルゲームを作る予定です。（間に合わなかったら以降のコミティアや夏コミなど予定）
当初はかなり簡単なものにするつもりだったのですが、いつものごとく、色々アイデアやネタを練っていたらそれなりにちゃんとしたものになってきてしまいました（汗）。なんだかこの展開は隼STGを思い出します。
一体いつになったら次回作が本格始動するのでしょうか…（実際には隼STGの前からスタートしているのですが…）
タイトルは関係なくてｗ、とりあえず生存報告。
EntisGLS4s、ERISA 系独自コーデックを書きなおしてデバッグしていたら2週間？いや3週間？4週間？経っていました。低水準のバイナリは符号化／復号両方とも書きましたが、画像／サウンド／動画はデコードだけです…。
ついでに noa 書庫ファイルの暗号化方式を新しくして、EntisGLS4s の方では新しい暗号化だけの対応にしました。（圧縮は旧来通り）
画像／サウンドのデコーダは、コードとデータのバイナリ互換性の上で重要な部分ですが（実行プラットフォーム非依存）、動画の再生も出来れば
Sakura2 仮想マシン上での実行で現実的な速度で再生できればと考えています。実現できるかどうかは分かりませんが、一応、SIMD 命令の
JIT コンパイラが有効であるという前提で、そこそこ何とか成るのではないかと………希望的観測。一方で、普通に Intel386 互換用に
C++ でコンパイルしたコードだと、大きなサイズの動画の再生は重いので、出来れば Sakrua2 の SIMD で頑張りたい。
あとは、ARMv7 系向けの SIMD 命令の JIT コンパイラも作らないとなぁ〜
因みに、EntisGLS4s は Sakura2 仮想マシン向けの開発フレームワークですが、コードは C++ と共用するので（Sakura2
へは詞葉コンパイラの C++ 互換モードを利用して）、C++
でもライブラリとして利用出来るのが特徴です。まあ、フレームワークレベルでの動作の互換性は、C++ で作る場合には無理が出てきますが。
しかし、まだリリースには時間が掛かりそうです。
|
