アカウント名:
パスワード:
AMD の狙いは、現状の 32ビットアーキテクチャと連続性を持たせ、しばらくは高性能な x86 として素早く普及を図りつつ、搭載し
それと、32bit-intは使うことが多いので1opで実行できる事がメリットとなりましたが、64bit-intってあんまり使う事が無
ん~ ENDマーク自己認識機能きDMAコントローラか… こんどのシステムボードのFPGAの隙間(^^;)におしこんでテストしてみるかな…(^^;)
ハード的にはただのメモリ間データ転送ですよね? であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと… で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…
ん? んん? 何の話? OpteronはメモリコントローラをCPUに内臓してるから、FSBがどうたらとか無関係ではないの
>んで、ここでの話題は物理的なメモリ速度なんか全然関係無くて、CPU内部での論理的なメモリ操作の話をしているのではないかなと。
少なくとも普通のプログラム(SSEやVISみたいなSIMD命令群がメインで動かないようなプログラム)では、 64bitアドレス空間で動かしたほうがポインタのサイズが大きくなったり、 ページテーブルのキャッシュミスが増えたりするため、実行速度は遅くなります。
参考程度ですが、メモリコピーを行うプログラムを同一マシン上で 32/64bitアドレス空間それぞれで動かしたので、 結果を張り付けておきます [srad.jp]。
まあいずれにしろ、inline化したところで変化するのは関数コールのオーバヘッドの分だけのような気がするので、元々のメモリ転送速度の話とは切り放して考える必要があると思います。
strcpyだと末尾の'\0'を判断して, その先は送り先側にはコピーしないようにするので, 何も工夫していないプログラムでは1バイト毎の転送となってしまい, 8バイト分の幅がある64bitバスの有効性が活かせない. 下手をすると1バイト単位という特殊なアクセスの為, 効率が極端に落ちるのではないか. ということだと思います.
ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.そのため, ほとんど全ての文字列の長さが8バイト未満というような場合を除き, 効率は上がると考えて良いと思います.
ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.
glibcなんかはi586以上はsysdependなコードがありますが、i386は無いので「おばかなインプリメント」がされています。 Linuxの多くのディストリビューション
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
一番乗りは誰だ (スコア:2, 参考になる)
AMD の狙いは、現状の 32ビットアーキテクチャと連続性を持たせ、しばらくは高性能な x86 として素早く普及を図りつつ、搭載し
の
Re:一番乗りは誰だ (スコア:1)
64ビット化すると、恩恵の出るアプリは除外してっ事ですけどね。
Re:一番乗りは誰だ (スコア:1)
身近なところで文字列のコピーなんかは普通に高速化できそう
体感できるかどうかは微妙だけど
恩恵のでないアプリはなさそうですよね
Re:一番乗りは誰だ (スコア:0)
もちろんアルゴリズムとかCPU内部でのcharの取り回しのアーキテクチャに拠るだろうし、体感できるほど差は無いだろうけど。
Re:一番乗りは誰だ (スコア:1)
memcpyは早くなるな。
元々言いたかったのは、16ビットから32ビットに以降したときの様な、必然性は感じられないって事。
でもmemcpyが早くなるなら、やっぱりわくわくするかも。
Re:一番乗りは誰だ (スコア:2, 参考になる)
やったことないので分かりませんが、SSEのレジスタを
ごそっと使ってmemcpyすると結構、速いかもです。
Re:一番乗りは誰だ (スコア:0)
プログラム起動時のメモリクリアに使用中。
Re:一番乗りは誰だ (スコア:1)
memcpyからmemmoveに乗り換えましょう:-)
Re:一番乗りは誰だ (スコア:0)
それと、32bit-intは使うことが多いので1opで実行できる事がメリットとなりましたが、64bit-intってあんまり使う事が無
Re:一番乗りは誰だ (スコア:0)
#CPUの話からは外れるけど
それはDMAかCPUか? (スコア:1)
ん~ ENDマーク自己認識機能きDMAコントローラか… こんどのシステムボードのFPGAの隙間(^^;)におしこんでテストしてみるかな…(^^;)
Re:それはDMAかCPUか? (スコア:0)
汎用のDMAC(DMACとして売られているLSI)だったら、転送終了のための
データを設定出来たりしますよ。
Re:それはDMAかCPUか? (スコア:1)
私がいままで使ったことのあるDMAは、そのような機能をもったものがないので、具体的なメーカー名と型番を教えていただければありがたいです。よろしくお願いいたします。
Re:一番乗りは誰だ (スコア:1)
実際のライブラリがどのような処理をしているかはわかりませんが…
ハード的にはただのメモリ間データ転送ですよね?
であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと…
で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…
Re:一番乗りは誰だ (スコア:0)
ん? んん?
何の話? OpteronはメモリコントローラをCPUに内臓してるから、FSBがどうたらとか無関係ではないの
Re:一番乗りは誰だ (スコア:1)
>んで、ここでの話題は物理的なメモリ速度なんか全然関係無くて、CPU内部での論理的なメモリ操作の話をしているのではないかなと。
少なくとも普通のプログラム(SSEやVISみたいなSIMD命令群がメインで動かないようなプログラム)では、 64bitアドレス空間で動かしたほうがポインタのサイズが大きくなったり、 ページテーブルのキャッシュミスが増えたりするため、実行速度は遅くなります。
参考程度ですが、メモリコピーを行うプログラムを同一マシン上で 32/64bitアドレス空間それぞれで動かしたので、 結果を張り付けておきます [srad.jp]。
Re:一番乗りは誰だ (スコア:1)
Re:一番乗りは誰だ (スコア:1)
最適化を掛けていないので、memcpyとmemmoveの差がでない様な気がするのですが、いかがですか?
gccで下手に最適化掛けると、確かmemcpyとかはインライン展開されてしまうので、inline抑制有/無で結果出していただけるとありがたいです。
#お前がやれって?
#ごもっとも
Re:一番乗りは誰だ (スコア:1)
まあいずれにしろ、inline化したところで変化するのは関数コールのオーバヘッドの分だけのような気がするので、元々のメモリ転送速度の話とは切り放して考える必要があると思います。
Re:一番乗りは誰だ (スコア:1)
有意な差は出ていないようですね。
ありがとうございました。
Re:一番乗りは誰だ (スコア:0)
#本当にわからないのでAC
Re:一番乗りは誰だ (スコア:1)
strcpyだと末尾の'\0'を判断して, その先は送り先側にはコピーしないようにするので, 何も工夫していないプログラムでは1バイト毎の転送となってしまい, 8バイト分の幅がある64bitバスの有効性が活かせない. 下手をすると1バイト単位という特殊なアクセスの為, 効率が極端に落ちるのではないか. ということだと思います.
ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.そのため, ほとんど全ての文字列の長さが8バイト未満というような場合を除き, 効率は上がると考えて良いと思います.
Re:一番乗りは誰だ (スコア:0)
glibcなんかはi586以上はsysdependなコードがありますが、i386は無いので「おばかなインプリメント」がされています。
Linuxの多くのディストリビューション
Re:一番乗りは誰だ (スコア:0)
誤:IA64用のコード
正:x86-64用のコード
大量のファイルの処理は速くなりそうだ (スコア:0)
リソース不足によるトラブルがなくなる事を期待したい。
大量のデレクトリとかファイルとかエクスプローラで扱おうとすると
リソース食って遅くなったり、不安定になったりするからね。
Re:大量のファイルの処理は速くなりそうだ (スコア:0)
ちなみに、Windowsでいうところのシステムリソースなら、NT系で
すでに3MBがデフォルトになっていますが、さらに増やすと
管理の手間が増えてパフォーマンスが落ちるらしいです。