VAIO C1 VS Libretto L1

>>235
＞計算もできないんですか？しょうがないですね。
はい、私にはこの間違った計算はできませんでした

＞16MB=16byte * 1,000,000なので、16MBのネイティブバイナリを
16MBは16*1024*1024です、
CPUのアドレッシングの仕方を勉強してください
そうすればこんな間違いはしません

＞すべて実行するには1,000,000サイクル必要です。
1,000,000 を1048576に読み替えた上で
必ず、１クロックで１語実行できるのですか？

分岐命令のペナルティを考えてたりしないのですか？

CMSのキャッシュはCMSのコンバートから見ればX86をインプットとした場合のアウトプットです、
実行するX86のバイナリの大きさから計算するならわかりますが
なぜCMSのキャッシュの容量で計算しているのですか？

16MBだと先読みでキャッシュに充填しないとウェイトが発生すると思いますが
それを考慮していますか？

＞むしろ64ビット長の分だけ、ネイティブコードの実行速度は不利です。
＞16MB分のデータを実行するには倍かかる訳ですが、これもだいたい
＞同じオーダー（数十ms）ですね。
普通ネイティブコードの実行に要するCPUサイクルを外部バス幅で計算することはありません
通常は１次か２次キャッシュがCPUコアに接続されている幅で計算すると思いますが
それを踏まえた上で、何が64Bitなんですか？
ちなみにX86のバイナリコードの命令長は可変長です

＞アルゴリズムがどれだけ複雑かによりますが、VILWコンパイラほど
＞困難な処理は行っていない（というより、情報不足で出来ない）
VLIWプロセッサで速度を出すには前出のとおり、高度な最適化が必要ですから
少なくとも命令の前後の依存関係を見て最適化する必要があると考えます
また、>>235の様にあまり最適化をしない場合は、
VLIWのバイナリコードの実行速度が遅くなると考えることはできませんか？

＞わけですから、1命令の変換当たり多くて数百ステップだと
＞思います。それがどのくらいになるかくらいは計算できますよね？
上記の理由で、この変換に要する処理が１桁〜２桁大きいと考えています

また、CMSのコードはCPUに内臓している訳ではなくROMに持っているだけなので
クルーソー自身のキャッシュに乗っていない場合
CMS自体をROMからキャッシュに読み込む必要があり
これに要する時間も必要と考えます