「中二病でも恋がしたい！」のアニメが面白いですｗ
声優被りで勇太から時々ルルーシュや神にーさま（※こっちは被ってないけど）が出てくるのがｗｗｗ
そして映像面で、アニメ化が上手く機能して…ｗ
声優ネタとしては、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 です（違
イラスト描きたいのですが、忙しすぎて流石に無理です…orz
最近は、俺言語のコンパイラの強化ばかりやっていて、同人ゲームの開発まで到達出来ていなかったりします。
ちょっと、余りにコンパイラを強化して、普段のC++のコードをそのままコンパイルできるレベルまで来てしまったのと（もちろん従来の俺言語もコンパイルできる）、実行する仮想マシンでコードをネイティブに変換して実行する準備が着々と進んでいるので、もう、それを完全に作ってしまってから同人ゲームの開発に移行しようかと。
俺言語にソースを移行してしまえば、32ビットWindowsだけでなく、色々移植性が高いですし（64ビット版や Android、その他など）、SIMD 命令のネイティブ変換を実装してしまえば、x86 か ARM かも考えなくても良くなりますし、そもそも、SSE や NEON
が使えるかどうかを気にしなくてもいいので（実行速度は遅くなるものの、ネイティブに変換することろで同等の代替コードを出力するだけなので）、コードの使いまわしと言うか、汎用性が飛躍的に向上しそうな気がしてきています。
まあ、ネイティブコードへの変換は当面は x86/SSE2 のみですが。
なんと言っても、俺言語「詞葉3.0」の新しい仮想マシンは、実装が凄く簡単で、かつ実行速度が速いと言う利点があるので、将来仮に別のプラットホームへ移行するとなったときにも、俺言語で書いておけば、新しいプラットホーム用の仮想マシンを作るだけで即移行できるということがあるんですよねぇ〜。
欠点があるとすれば、デバッグ環境がやや貧弱、というところでしょうかねぇ〜。
|
