パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Microsoftがやっとx86-64への対応を発表、Sunは可能性を示唆」記事へのコメント

  • 本家のBSD セクションには FreeBSD はブートに成功 [slashdot.org]なんてものあって、x86-64 への対応は急速に進んでるみたいですね。

    AMD の狙いは、現状の 32ビットアーキテクチャと連続性を持たせ、しばらくは高性能な x86 として素早く普及を図りつつ、搭載し

    --
    • 個人的には64ビットという響きを聞くと、わくわくしてしまいますが。実際のパフォーマンスでは、32ビットも64ビットも差がない気がするのですが、どうでしょう。

      64ビット化すると、恩恵の出るアプリは除外してっ事ですけどね。
      • ん~
        身近なところで文字列のコピーなんかは普通に高速化できそう
        体感できるかどうかは微妙だけど
        恩恵のでないアプリはなさそうですよね
        • by Anonymous Coward on 2003年04月10日 18時48分 (#296208)
          memcpyは速くなるだろうけど、strcpyは変わらない(orより遅くなる)んじゃないかな?
          もちろんアルゴリズムとかCPU内部でのcharの取り回しのアーキテクチャに拠るだろうし、体感できるほど差は無いだろうけど。
          親コメント
          • by chi (11062) on 2003年04月10日 19時12分 (#296218) 日記
            そうですね。
            memcpyは早くなるな。

            元々言いたかったのは、16ビットから32ビットに以降したときの様な、必然性は感じられないって事。
            でもmemcpyが早くなるなら、やっぱりわくわくするかも。
            親コメント
            • by ed-beta (4425) on 2003年04月10日 19時48分 (#296234)
              SSE2なら128ビット長長整数レジスタが使えます。
              やったことないので分かりませんが、SSEのレジスタを
              ごそっと使ってmemcpyすると結構、速いかもです。
              親コメント
              • by Anonymous Coward
                それと同じことをやって高速化を図っているのがWinXPですね。

                プログラム起動時のメモリクリアに使用中。
            • by babie (6656) on 2003年04月10日 20時05分 (#296245)
              せっかく速くなるんだから
              memcpyからmemmoveに乗り換えましょう:-)
              親コメント
            • by Anonymous Coward
              16→32の時は、プロテクトモードが付いたとか16ビット時代に既にアドレッシング可能なメモリの限界いっぱいまで使っていて、アドレスバス幅も増えたとか、そういう単なるデータバス幅の倍加以外のメリットがありましたからね。

              それと、32bit-intは使うことが多いので1opで実行できる事がメリットとなりましたが、64bit-intってあんまり使う事が無

            • by Anonymous Coward
              メモリの複写・初期化くらい、DMAとかでガーッとやれるアーキテクチャになってくれないのだろうかと思うんだけど、どうなんだろう?
              #CPUの話からは外れるけど
              • by 505 (12538) on 2003年04月11日 16時48分 (#296805)
                上でもかかれてますが、NULL文字を判定してそこまで転送…といったような、転送データの内容によって転送条件があったりすると、一般的なDMA(転送元/転送先/転送ワード数程度の設定しかできない)だと対応できないっすよね。

                ん~ ENDマーク自己認識機能きDMAコントローラか… こんどのシステムボードのFPGAの隙間(^^;)におしこんでテストしてみるかな…(^^;)

                親コメント
              • へ?

                汎用のDMAC(DMACとして売られているLSI)だったら、転送終了のための
                データを設定出来たりしますよ。
              • by 505 (12538) on 2003年04月16日 18時50分 (#299638)
                不勉強でもうしわけありません。
                私がいままで使ったことのあるDMAは、そのような機能をもったものがないので、具体的なメーカー名と型番を教えていただければありがたいです。よろしくお願いいたします。
                親コメント
          • by 505 (12538) on 2003年04月10日 22時02分 (#296307)
            >memcpyは速くなるだろうけど、strcpyは変わらない(orより遅くなる)んじゃないかな?
            実際のライブラリがどのような処理をしているかはわかりませんが…
            ハード的にはただのメモリ間データ転送ですよね?
            であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと…
            で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…
            親コメント
            • by Anonymous Coward

              ハード的にはただのメモリ間データ転送ですよね?
              であればCPUのレジスタのビット長やコアの内部バスのバス幅はあまり関係なくて、CPUの外部メモリバスのバス幅や速度で決まってくるのではないかと…
              で、すでにPentium以降のCPUは、外部バス幅は64ビットになってますので、あとはFSBの差しかないかと…

              ん? んん?
              何の話? OpteronはメモリコントローラをCPUに内臓してるから、FSBがどうたらとか無関係ではないの

              • すでに現在でも、20万円も出せば64bit CPUを積んだ新品のワークステーションが買えますよ。ご自身で確かめられては?(ニヤリ)

                >んで、ここでの話題は物理的なメモリ速度なんか全然関係無くて、CPU内部での論理的なメモリ操作の話をしているのではないかなと。

                少なくとも普通のプログラム(SSEやVISみたいなSIMD命令群がメインで動かないようなプログラム)では、 64bitアドレス空間で動かしたほうがポインタのサイズが大きくなったり、 ページテーブルのキャッシュミスが増えたりするため、実行速度は遅くなります。

                参考程度ですが、メモリコピーを行うプログラムを同一マシン上で 32/64bitアドレス空間それぞれで動かしたので、 結果を張り付けておきます [srad.jp]。

                親コメント
              • by 505 (12538) on 2003年04月11日 16時54分 (#296809)
                あぁ~そうか、NULL文字とかを判定しながら転送とかしてるから、単なるDMAとはちがいますもんね。
                親コメント
              • by chi (11062) on 2003年04月11日 21時12分 (#296963) 日記
                結果拝見しました。
                最適化を掛けていないので、memcpyとmemmoveの差がでない様な気がするのですが、いかがですか?

                gccで下手に最適化掛けると、確かmemcpyとかはインライン展開されてしまうので、inline抑制有/無で結果出していただけるとありがたいです。

                #お前がやれって?
                #ごもっとも
                親コメント
              • 最適化・inline化を切り替えて やってみましたが [srad.jp]、特に変化なしです。 コード見ても律儀にライブラリを呼び出しているだけで、 inline化するための条件を満たしていないみたいです。

                まあいずれにしろ、inline化したところで変化するのは関数コールのオーバヘッドの分だけのような気がするので、元々のメモリ転送速度の話とは切り放して考える必要があると思います。

                親コメント
              • by chi (11062) on 2003年04月12日 12時56分 (#297314) 日記
                結果拝見しました。
                有意な差は出ていないようですね。

                ありがとうございました。
                親コメント
          • by Anonymous Coward
            え、なんで?
            #本当にわからないのでAC
            • by SteppingWind (2654) on 2003年04月11日 1時36分 (#296436)

              strcpyだと末尾の'\0'を判断して, その先は送り先側にはコピーしないようにするので, 何も工夫していないプログラムでは1バイト毎の転送となってしまい, 8バイト分の幅がある64bitバスの有効性が活かせない. 下手をすると1バイト単位という特殊なアクセスの為, 効率が極端に落ちるのではないか. ということだと思います.

              ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.そのため, ほとんど全ての文字列の長さが8バイト未満というような場合を除き, 効率は上がると考えて良いと思います.

              親コメント
              • by Anonymous Coward

                ただstrcpyみたいな非常によく使われる関数でそんなおばかなインプリメントがされるわけは無く, 例えば基本的には64bit単位での転送を使い, 文字列末尾の8バイトブロックだけ特殊な処理を行う様になっているはずです.

                glibcなんかはi586以上はsysdependなコードがありますが、i386は無いので「おばかなインプリメント」がされています。
                Linuxの多くのディストリビューション

              • by Anonymous Coward
                訂正:
                誤:IA64用のコード
                正:x86-64用のコード

Stableって古いって意味だっけ? -- Debian初級

処理中...