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

Phenom II X3がX4になる裏技発覚」記事へのコメント

  • それ以前に (スコア:1, 興味深い)

    by Anonymous Coward

    X3とX4て(ベンチじゃなく)実際の動作速度でいかほど違うんでしょうか。
    アーキテクチャが複雑になりすぎて「結局どのくらい速いの」ということが
    把握できなくなってきてます<自分。

    • Re: (スコア:3, すばらしい洞察)

      by Anonymous Coward
      よく誤解されてるけど、マルチコアとかマルチプロセッサっていうのは、早くするための技術じゃなくて遅くならなくするための技術。
      よって普通に使っている分にはクロック分の速さしか体感できないですよ。
      • by Anonymous Coward

        早くするための技術じゃなくて遅くならなくするための技術。

        遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。
        マルチスレッドなアプリってまだそんなに特殊?

        • by Anonymous Coward on 2009年02月24日 12時57分 (#1519678)

          「そのための技術」ってのは今時どうなんですかね。

          今時だからこそ有効な技術ですよ。バックグラウンドで数十のプロセスが常に動いている今時のOSであればこそ、です。

          マルチスレッドなアプリってまだそんなに特殊?

          存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。

          親コメント
          • by firewheel (31280) on 2009年02月24日 13時50分 (#1519713)

            >マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。

            マルチスレッド化による速度向上に比べ、マルチスレッドアプリを作るための
            「労力が高く付きすぎる」というのが大きいんではないかと。そもそもマルチ
            スレッドでプログラムを書けないプログラマの方が断然多いし。よってPCだと複数
            アプリ同時起動(つまりマルチプロセス)がメインになるんでしょう。

            やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、
            ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと
            ディスプレイは多いに越したことはないと思います。

            親コメント
            • by albireo (7374) on 2009年02月24日 15時16分 (#1519755) 日記

              >「労力が高く付きすぎる」というのが大きいんではないかと。

              それもありますが、大きな理由はむしろ「たいして速くならない」からですよ。
              「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則があるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分がマルチスレッド化でスピードアップできるような処理でなければほとんど無意味ということです。

              スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で体感できるほど速くなるアプリケーションってけっこう限られてます。

              非同期処理を並列実行するコードを簡潔に書くためのマルチスレッド化する場合もありますが、この場合は単に待ち時間を減らしたりしているだけなのでマルチコアになってもそんなにスピードは変わりません。

              >マルチスレッドでプログラムを書けないプログラマの方が断然多いし。

              これも当然。
              マルチスレッドの恩恵を受けられない分野ならマルチスレッドでプログラムする需要がありません。
              マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。

              --
              うじゃうじゃ
              親コメント
              • by firewheel (31280) on 2009年02月24日 19時59分 (#1519897)

                >マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
                うーんと、本当にマルチスレッドの並列プログラムをやったことあります?

                >スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で
                >体感できるほど速くなるアプリケーションってけっこう限られてます。

                は事実だけど、たとえ早くなる処理でさえも並レベルの分かってないプログラマが
                書くと「スレッド間同期のオーバーヘッドでかえって遅くなる」だけでなく、
                アルゴリズムや設計が逐次処理とは異なるとか、デバッグが死ぬほど難しいとかに
                より、マルチスレッドのプログラミングは難易度がもの凄く高いんですよね。

                もしプログラミングが簡単だったら実測で2~3割早いだけでもマルチスレッド化する
                かもしれないけれど、実際には難易度がとてつもなく高いので、最低でも2~3倍速く
                なって体感速度ではっきり分かるくらいでないと、マルチスレッド化/並列化という
                選択は採算が合わないのです。

                そういう意味ではクワッドコアでもまだまだですね。最大でもたったの4倍
                (とちょっと)にしかならないのですから。並列処理が大きく意味を持つようになる
                には、コア数が16とか32とかくらいにならないと難しいのでは。

                あと
                >「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則が
                >あるように、手を入れることで目に見えて速度が向上する部分はごく一部です。
                この部分の9割とか1割は、この議論にはあんまり関係ないですね。
                「その9割を占める1割の部分は、並列化しにくいことが知られている」
                などという結論には繋がってないわけですから。

                それに実際には1割になってくれてる方が楽です。運が良ければ全体の1割を書き
                換えるだけで、全体を2倍~3倍に高速化することも不可能ではないのですから。
                「運が良くても悪くても、全部書き換えないと性能が上がらない」よりはずっと
                楽です。

                親コメント
              • by Anonymous Coward
                Xeonの最新版でも買ってください。
                6コア構成でハイパースレッティング使って12並列処理できますから。
              • by albireo (7374) on 2009年02月25日 4時21分 (#1520142) 日記

                >うーんと、本当にマルチスレッドの並列プログラムをやったことあります?

                「レスポンス向上などを目的とした非同期処理のためのマルチスレッド」ならけっこうやってますよ。
                「マルチコアを活用して処理速度を向上するための並列化」はかじった程度ですね。

                >この部分の9割とか1割は、この議論にはあんまり関係ないですね。
                >「その9割を占める1割の部分は、並列化しにくいことが知られている」
                >などという結論には繋がってないわけですから。

                そんなことはないと思いますよ。
                「処理速度向上のためにコストをかけてマルチスレッド化する価値があるかどうかは、その9割を占める1割の部分が並列化しやすいかどうかにかかっている」(ダメなこともよくある)
                という表現なら、firewheelさんもそんなに異論はないのでは?

                私は別にマルチスレッドプログラミングの難易度が高いことを否定したつもりはありません。
                それとは別に並列化によって速度向上を期待できるシチュエーションが限られていて、そのため並列化のスキルを身に着けても活かせる場面が限られていることも、並列化のプログラミングコストがなかなか下がらない要因として大きいということが言いたかったのです。
                もっと幅広く効果が期待できるものであれば、本質的に避けられない複雑さはあるにしてももうちょっとハードルは下がったんじゃないかなと思うわけです。

                --
                うじゃうじゃ
                親コメント
            • by dameneco (33758) on 2009年02月24日 17時31分 (#1519824) 日記

              >やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、
              >ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと
              >ディスプレイは多いに越したことはないと思います。

              複数台のコンピュータを利用した方が効率的です。
              HDDやメモリのスループットがボトルネックになりそう。

              親コメント
          • 既製のアルゴリズムを解析して並列化するのは大変だけどアルゴリズムにデータを投入する段階で
            マスター/ワーカー式粗粒度並列にするのは同期用のキューとかライブラリ・レベルのインフラがそろってればそんなに難しくないです。
            (前にも書いたような気がするけど)仕事で作ってるコンパイラはJavaの5.0(1.5)以降前提なのでインフラがそろっており、
            ある最適化をその手口で並列にしたらちゃんとコア数分早くなって結構幸せ。

            親コメント
          • by Anonymous Coward
            > 存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが
            > 意外に少ないというのがあるのではないかと。

            自分的には、Web+開発ツール位しか使わないので、うれしいアプリはあまり思い
            浮かばないですね
            #しいて言えば、エンコくらいかw

            体感ですが 2400+690G+Cnet君x64より9350e+790G+Cent君x32の方が
            NetBeansの起動は速い気がする
            • by Anonymous Coward
              そのWEBでは、フラッシュなんかで広告がバリバリ動くようなページで
              効果が見られますよ。
              以前だと、韓国の新聞系サイトなんかがそうです。

              シングルコアだと、ページを開いているだけで、かなりのパワーを
              持っていかれました。

              # 重くて不評だったらしく、すぐにフラッシュは使われなくなりましたが。

アレゲは一日にしてならず -- アレゲ研究家

処理中...