新年おめでとうございます。
イラスト描きたいところですが、とりあえずEntisGLS4sが完成した後に………。
なんか、→の扉絵も何年前だよって感じですしね。鳩耳さんからずいぶん首相変わりましたし。
システムを根底から置き換えると、上に乗っかっているものも旧来のものが動くようになっていても新しいものに置き換えようと思ってしまうせいで、予定よりずいぶん時間掛かってますorz
「中二病でも恋がしたい！」のアニメが面白いですｗ
声優被りで勇太から時々ルルーシュや神にーさま（※こっちは被ってないけど）が出てくるのがｗｗｗ
そして映像面で、アニメ化が上手く機能して…ｗ
声優ネタとしては、DTもいい感じだけどｗ
さて、新しい詞葉3.1 の Sakura2 仮想マシンのネイティブコード変換が完全では無いですがある程度動くようになったので、速度を検証してみました。
最もパフォーマンスの期待できる SIMD はこれからですが、通常の演算で、1.5 [Clock/命令] 程度の速度での動作を確認出来ました。（加減算を中心としたSSE2への変換）
因みに非SSEへの変換では 5 [Clock/命令] 程度、ネイティブに変換せず逐次実行する場合には 20 [Clock/命令] 程度です。（乗除算などの重たい命令は＋α）
もしかしたら SSE2 への変換での速度が遅いように感じるかもしれませんが、Sakura2 のレジスタが64ビットで、基本演算単位が（一部を除いて）64ビットなので整数演算が遅いこと、特に、何気ない処理に2〜3クロック要する場合があるのが原因です。
因みに、同じ単純なループのCコードを詞葉とMS-C++でコンパイルし実行した場合、MS-C++ の最適化を行わないコードとおおよそ同じ速度で動作する感じです。（処理の演算精度が64ビットと32ビットの違いがありますし、詞葉コンパイラの最適化
が MS-C++ の最適化ほどよろしくないということもあります）
但し、Sakura2 の方は、ループの中身（分岐のないコード）の長さが短いと余りパフォーマンスを見込めないことや（コンパイル時点と実行時のネイティブコード変換時の両方
で）、SIMD 命令はネイティブな命令とほぼ1対1に変換できるので（64ビット整数演算はそうはいかない）、速度の差は殆ど生じないと予測され、現時点ではかなり満足のいく結果が得られたかなと思っています。
近いうちに EntisGLS4s の発表したいです。
「近いうち」は年内ですかねぇ…、どうなんですかねぇ………どじょう内閣（違
えー、EntisGLS4s は EntisGLS の次のバージョンです。
多分、過去の EntisGLS の中で一番しょぼく（？）て、一番野心的だと思います（ぇ
因みに、EntisGLS4s の s は subset とか、Sakura2 とか、shirika とか、shinka とか、sanae とか、sayaka とかの s です（違
|
