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

G5とOpteron、どっちが速い?」記事へのコメント

  • 残りの32bit (スコア:3, すばらしい洞察)

    by Anonymous Coward
    このベンチマークで注目(?)すべき点と言えば、どちらも32bit環境での比較であるという事に尽きるのではないでしょうか。
    Opteron側に使用されたOSはXPの32bit版のようですし、Mac側のPantherにしても、まだ64bitに最適化されていない筈です。比較に使用されたソフトウェアも、Mac用PhotoshopのG5プラグイン以外は64bitに最適化された物はなさそうです。これ
    • by gk-hyn (7889) on 2003年12月31日 22時49分 (#464187)
      どーでもいいような変数やポインタが64bitになると、32bitだったときに比べてメモリの読み書きに約2倍時間がかかるようになるわけで。
      そもそも今のアプリで64bit整数演算を使ってたかと。4GB越えメモリアクセスについても、そりゃ、36bitセグメントとか、ディスクにスワップしてたのがオンメモリでとなると速くなるわけだけど、そんなにメモリを食うソフトって何って事になってくるし。
      ところで、SSEとか3DNow!とか使うと、128bitに最適化って言っても好いんですかネ?
      親コメント
      • Re:残りの32bit (スコア:2, 興味深い)

        by wlint (18720) on 2004年01月01日 17時46分 (#464499)
        > どーでもいいような変数やポインタが64bitになると、32bitだったときに比べてメモリの読み書きに約2倍時間がかかるようになるわけで。

            バイトアライメントが取れている前提であれば、今は物理的なデータバスが64bit以上
        あるのが普通なので、8/16/32/64のどれでも実質的にはほとんど変わらないと思います。
        (厳密にいうと、巨視的には主記憶とキャッシュの間の転送量が増える分だけ性能に影響
        するかもしれませんが、どちらのCPUもキャッシュがかなり大きいので、これも誤差範囲の
        ような気がします。)

        > ところで、SSEとか3DNow!とか使うと、128bitに最適化って言っても好いんですかネ?

        PC等では、SSE/3DNow!命令対応、とかって言っているような気がしますが、
        DreamCast(SH4)なんかはそういっているような気がしますね(^_^;;
         ちなみに、一般的なグラフィック処理の性能改善には、むしろ
        メモリのレイテンシーに最適化、の方が影響あるんじゃないかと思いますが(^_^;;

        # G5の性能って、FSBクロックの高さに由来するところも多いと思います。
        親コメント
        • by gk-hyn (7889) on 2004年01月01日 23時22分 (#464570)
          「メモリ=キャッシュ間で転送量が増えても誤差に埋もれるくらいしか変わらない」
          「G5はメモリ=キャッシュ間を高速化したから高性能」
          えー。これって両方いっぺんに主張してもらっても困るなぁ。

          http://pcweb.mycom.co.jp/benchmarklab/2002/09/page2.html
          それに、現状でメモリだけ高速化してもそれなりに効果がある、ってことは、キャッシュが大きくても隠蔽しきれず、誤差範囲以上に性能は低下するって事でしょ。
          標準変数が32bitから64bitになると、メモリ=キャッシュ間の速度が幾らか低下したのと同じ事になるわけだから、まあ20%~30%膨らむとして、さっきのグラフを見れば、200:200と266:266のときで、5%程度低下することになりますよね(キャッシュ効率が低下するのは含まないとして)
          親コメント
          • by wlint (18720) on 2004年01月02日 7時25分 (#464648)
            > 「メモリ=キャッシュ間で転送量が増えても誤差に埋もれるくらいしか変わらない」
            > 「G5はメモリ=キャッシュ間を高速化したから高性能」
            > えー。これって両方いっぺんに主張してもらっても困るなぁ。

             セットで主張しているわけでもないし、上記2点についてはアプリケーションに
            依存する所が大きいから断定せずに書いているのですが。
            そもそも、ここで問題にしているのは、「どーでもいいような変数やポインタ」への
            アクセス速度の問題ですよね。
            元々の、「32bitアプリと64bitアプリの性能比」の話と「メモリ速度が実行速度全体に
            与える影響」は、少しレベルの違う話だと思いますが。
            親コメント
      • > ところで、SSEとか3DNow!とか使うと、128bitに最適化って言っても好いんですかネ?

        AltiVec(Velocity Engine)も加えてやってください。
        親コメント
      • by knn (11810) on 2004年01月04日 10時08分 (#465199) 日記
        >そもそも今のアプリで64bit整数演算を使ってたかと。

        Javaのlong型は64bit整数なので、JVMがちゃんと対応すればlongを多用するJavaアプリには恩恵があるかも。
        親コメント

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...