VAIO C1 VS Libretto L1
253 ：214：
245
>>なぜCMSのキャッシュの容量で計算しているのですか？
>元の発言がCMS上にある命令の実行速度を問題にしていたからでは。
>P6はそれとの比較で引っ張り出してきたのでは。
よく読んでね、ここでいっているのはCMSのX86⇒VLIWの変換の話だから
また、仮に実行速度だとしてもキャッシュ容量の16Mを持ち出すのは不適切
>>通常は１次か２次キャッシュがCPUコアに接続されている幅で計算すると思いますが
>>それを踏まえた上で、何が64Bitなんですか？
>2次キャッシュが十分大きければそう言えるが、外部メモリからデータを
>読み込む必要があるから不当とも言えないんでは？
逆に、外部メモリからデータを読み込むのなら
DRAMのレイテンシーも考えないといけないのでは？
>>ちなみにX86のバイナリコードの命令長は可変長です
>命令出現頻度で命令長の重み付けを取ったら確実に最大命令長より短く
>なるよ？ それにx86はVLIWじゃないから1クロック実行もできないけど、
>パイプラインで理想的に流れたらそうなるっていう単純化なんじゃないの？
>ご存じの通りスーパースケーラでパイプラインに押し込んで並列実行して
>るわけで、ある意味クルーソーがやってることと同じ事を内部的にやってる。
>>>183で既出だけど。
何を言いたいのか良く判りませんが
64Bitだと言いたいのですか？
>>VLIWプロセッサで速度を出すには前出のとおり、高度な最適化が必要ですから
>>少なくとも命令の前後の依存関係を見て最適化する必要があると考えます
>完結したプログラムの実行バイナリの最適化にはプログラム構造の情報が
>利用できるけど、局所的にしか命令を参照できない場合に同様の最適化は
>できっこないんでないの？ ましてマルチタスクでOSやらアプリやらの
>バイナリがごっちゃで押し込まれてくるのに。
P3等のプロセッサでもやっていますよ
P3も内部の処理はX86命令をRISC的な命令に分割していますし
スーパースケーラのプロセッサなので
同時に同じレジスタを書き換えるような処理はできませんし、
パイプライン内でも値が確定するまで命令を発効できません
当然P3内でやっている最適化はデコードユニットに充填した命令に対してしか
できない事になりますが、これは局所的ではありませんか？
またCMSでの場合、パイプラインとスーパースケーラ(？)程度の最適化なら
局所的でも良いとは考えられませんか？
CMSの変換が軽いならなぜ一般的にエミュレーション処理は遅いのですか？
ここまで読んだ上でまだCMSの変換が軽いと思いますか？
>> また、>>235の様にあまり最適化をしない場合は、
>> VLIWのバイナリコードの実行速度が遅くなると考えることはできませんか？
>それで、どれだけ遅くなるの？ 最適化が不十分ならnopの混ざりが多くなると
>は思うけど、P5以降でストールするのとはペナルティの大きさが違うくない？
全く前後の命令を見ないで尚且つ安全に処理しようとすると
・レジスタなどのバッティング及び分岐命令を考えて１語に１命令まで
・パイプライン遅延を考えて１語毎にパイプラインが終わるまで待つ(理由は下記)
上記の条件だとシングルパイプラインで、動作クロック／パイプラインの深さ
で計算した値に遅くなるのでは？
>>なぜCMSのキャッシュの容量で計算しているのですか？
>元の発言がCMS上にある命令の実行速度を問題にしていたからでは。
>P6はそれとの比較で引っ張り出してきたのでは。
よく読んでね、ここでいっているのはCMSのX86⇒VLIWの変換の話だから
また、仮に実行速度だとしてもキャッシュ容量の16Mを持ち出すのは不適切
>>通常は１次か２次キャッシュがCPUコアに接続されている幅で計算すると思いますが
>>それを踏まえた上で、何が64Bitなんですか？
>2次キャッシュが十分大きければそう言えるが、外部メモリからデータを
>読み込む必要があるから不当とも言えないんでは？
逆に、外部メモリからデータを読み込むのなら
DRAMのレイテンシーも考えないといけないのでは？
>>ちなみにX86のバイナリコードの命令長は可変長です
>命令出現頻度で命令長の重み付けを取ったら確実に最大命令長より短く
>なるよ？ それにx86はVLIWじゃないから1クロック実行もできないけど、
>パイプラインで理想的に流れたらそうなるっていう単純化なんじゃないの？
>ご存じの通りスーパースケーラでパイプラインに押し込んで並列実行して
>るわけで、ある意味クルーソーがやってることと同じ事を内部的にやってる。
>>>183で既出だけど。
何を言いたいのか良く判りませんが
64Bitだと言いたいのですか？
>>VLIWプロセッサで速度を出すには前出のとおり、高度な最適化が必要ですから
>>少なくとも命令の前後の依存関係を見て最適化する必要があると考えます
>完結したプログラムの実行バイナリの最適化にはプログラム構造の情報が
>利用できるけど、局所的にしか命令を参照できない場合に同様の最適化は
>できっこないんでないの？ ましてマルチタスクでOSやらアプリやらの
>バイナリがごっちゃで押し込まれてくるのに。
P3等のプロセッサでもやっていますよ
P3も内部の処理はX86命令をRISC的な命令に分割していますし
スーパースケーラのプロセッサなので
同時に同じレジスタを書き換えるような処理はできませんし、
パイプライン内でも値が確定するまで命令を発効できません
当然P3内でやっている最適化はデコードユニットに充填した命令に対してしか
できない事になりますが、これは局所的ではありませんか？
またCMSでの場合、パイプラインとスーパースケーラ(？)程度の最適化なら
局所的でも良いとは考えられませんか？
CMSの変換が軽いならなぜ一般的にエミュレーション処理は遅いのですか？
ここまで読んだ上でまだCMSの変換が軽いと思いますか？
>> また、>>235の様にあまり最適化をしない場合は、
>> VLIWのバイナリコードの実行速度が遅くなると考えることはできませんか？
>それで、どれだけ遅くなるの？ 最適化が不十分ならnopの混ざりが多くなると
>は思うけど、P5以降でストールするのとはペナルティの大きさが違うくない？
全く前後の命令を見ないで尚且つ安全に処理しようとすると
・レジスタなどのバッティング及び分岐命令を考えて１語に１命令まで
・パイプライン遅延を考えて１語毎にパイプラインが終わるまで待つ(理由は下記)
上記の条件だとシングルパイプラインで、動作クロック／パイプラインの深さ
で計算した値に遅くなるのでは？
|
|
|
254 ：214：2001/07/19(木) 17:53 ID:5PS.Hizo
つづき
実行される前に命令を適切な配置にする必要があるのです、
またクルーソーはこれをHWで持たないので小さく省電力にできるのです
>>CMS自体をROMからキャッシュに読み込む必要があり
>>これに要する時間も必要と考えます
>CMSが常に動いていないとx86プログラムは動かないから、コードの
>ローディングは最初の1回だけでないの？
仮にCMSの部分のキャッシュをロックできるならそうだと思いますが
X86命令を実行している間はCMS自体は必要無いのでは？
キャッシュが16MBある事を考えると、
ロックできないとしたら破棄される可能性も否定でき無いと思います
(ここはL2にロックするべきだと思うのであまり自信ない)
>>252
＞これだけやれば、よっぽど精度の高い数値が出てくるんだろうな。
じゃ、その「よっぽど精度の高い数値」を計算してください
私は正確な数値は知らないし、
計算できるといった覚えもありません(あるなら番号を教えてください)
提示された条件に対してそれならどうこうどうだから１〜２桁大きくなるのではと言ったのです
実行される前に命令を適切な配置にする必要があるのです、
またクルーソーはこれをHWで持たないので小さく省電力にできるのです
>>CMS自体をROMからキャッシュに読み込む必要があり
>>これに要する時間も必要と考えます
>CMSが常に動いていないとx86プログラムは動かないから、コードの
>ローディングは最初の1回だけでないの？
仮にCMSの部分のキャッシュをロックできるならそうだと思いますが
X86命令を実行している間はCMS自体は必要無いのでは？
キャッシュが16MBある事を考えると、
ロックできないとしたら破棄される可能性も否定でき無いと思います
(ここはL2にロックするべきだと思うのであまり自信ない)
>>252
＞これだけやれば、よっぽど精度の高い数値が出てくるんだろうな。
じゃ、その「よっぽど精度の高い数値」を計算してください
私は正確な数値は知らないし、
計算できるといった覚えもありません(あるなら番号を教えてください)
提示された条件に対してそれならどうこうどうだから１〜２桁大きくなるのではと言ったのです