パスワードを忘れた？ アカウント作成
Close
9244691 story
ソフトウェア

AMDのCPU/APU向けスーパーπ高速化パッチが公開 52

ストーリー by hylom
AMD派へ 部門より
ymitsu 曰く、

AMDのCPU/APUにおいて、円周率計算ソフト「スーパーπ」を高速化するパッチ「Bulldozer Conditioner」が有志によって公開された（TechPowerupの記事、上田新聞の記事、パッチ作者のコメント）。

スーパーπとは東京大学の金田研究室が開発し1995年に公開された円周率計算ソフトで、さすがに古いソフトだけあってメニーコアには対応していないながらも、単コアあたりのCPUの性能の差がよく解るベンチマークとしてデファクトスタンダードだと考える人が未だに世界的に多くいる。そんなスーパーπの結果が現行のAMDのCPU/APUでは残念なものになる傾向があるが、その理由はスーパーπで多用されているx87命令セットへのBIOSの最適化の不備によるもので、このパッチを当てることで改善が可能とのこと。

スーパーπはx87命令にほぼ完全に依存しているため特に顕著な効果が出るが、x87命令セットを利用しているソフトなら基本的に何でも高速化されるようだ。

スーパーπとx87命令セットへの最適化など「今更何の意味があるのか解らない。もっといいベンチあるだろ」とのコメントがTechPowerupのページにもついているが、意味の解る方々や、あくまでスーパーπで最速を狙う方々はインストールしてみるのもいいかもしれない。

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

AMDのCPU/APU向けスーパーπ高速化パッチが公開 More

  • 残念な結果 (スコア:2)

    by miyuri (33181) on 2013年06月24日 18時58分 (#2407498) 日記

    そんなスーパーπの結果が現行のAMDのCPU/APUでは残念なものになる傾向があるが、その理由はスーパーπで多用されているx87命令セットへのBIOSの最適化の不備によるもので、

    走らせてみたところ、同じ動作周波数のCore i7だと、スーパーπのパフォーマンスはAMDのAPUの倍以上なわけで。
    まさか、ここまで差が有るとは思いもしなかった。

  • 前にも同じようなことをnVidia（？）がやってませんでしたっけ・・・
    べっちマークの為のパッチはあまり意味が無いような気がします。それどころか利用者をだましているような気すらします。

    どうなんでしょう？
    • そもそも、何に対するパッチなのかが分かりにくい。タイトルを見てSuperπの実行ファイルに対するパッチなのかと思ったけど、どうもそうではなさそうだけど。

      BIOSの一部を書き換えちゃうのか、BIOSの何かのスイッチ(起動時のBIOSセットアップ画面からいじれないなにか?)をON/OFFしてるだけなのか、OSに対するパッチとかなのか。

      効果としてはx87命令を多用する任意のソフトウェアが高速化されそうに見える一方で、意味がないというツッコミも入ってるし。 今現在x87命令を多用するようなソフトはもうないから、実用上ほぼ無意味、ぐらいの事なのかな?
      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        >今現在x87命令を多用するようなソフトはもうないから、実用上ほぼ無意味、
        FFTの素朴な実装とか、多用しそうな気がするのですが。
        あとはExcelとかで計算速くなったりしないのかな？

        • x87 [wikipedia.org]からMMX [wikipedia.org]とかSSE [wikipedia.org]の歴史をざっと見ると、古い命令も互換性のために残してあるけど、パフォーマンスは出ないので同じ計算をするなら新しい命令を使え、みたいな流れに見えます。

          コンパイラもそういう最適化はするでしょうから、昔にコンパイルされたツールか、わざわざアセンブラで書かれたものか以外ではそもそもx87系の命令は出てこないというのも、あり得るのかな、と。

          # SSEの更に次の次ぐらいまで出ていたんですね、当たり前の技術になってしまってて話題にならないので名前も知りませんでした・・・。
          シェア
          親コメント

          • ええ、実際そういう流れになっています。

            特に、64ビット(x86-64)だとSSE2（単精度・倍精度のスカラ演算ができる）が標準装備なので、どこのコンパイラもx87ではなくSSE2を使ったコードを出力します。

            32ビットでも、たとえばVisual C++ 2012はx87ではなくSSE2を使うオプションがデフォルトになっています。
            /arch (x86) [microsoft.com]

            /arch:SSE2

            Enables the use of SSE2 instructions. This is the default instruction on x86 platforms if no /arch option is specified.

            シェア
            親コメント

            • Re: (スコア:0)

              by Anonymous Coward

              MinGWはmathライブラリはFPUを使うコードになってるみたいです。

              • Re: (スコア:0)

                by Anonymous Coward

                コンパイル時のオプションで，
                コンパイラが直接SSEを出力するか
                FPUを使うライブラリをリンクするかが
                切り替わるようになっていませんか？

      • Re: (スコア:0)

        by Anonymous Coward

        Bulldozerアーキテクチャの特徴 [ascii.jp]として、2つのCPUコアでFPUを共有する構成になっているそうです。
        SuperPIはシングルスレッドでFPUをぶん回すアプリなので、このFPUを共有する仕組みがオーバーヘッドになって性能が低下する、という理屈のようです。
        件のパッチは、FPUを共有する片方のコアを停止させて、共有のオーバーヘッドをなくすという仕組みなのかな? だとすると、シングルスレッドで高FPU負荷なアプリであれば同様に性能が上がる一方で、マルチスレッドアプリでは逆に性能が低下するという結果になるんじゃないでしょうか。

        • SuperPIはシングルスレッドでFPUをぶん回すアプリなので、このFPUを共有する仕組みがオーバーヘッドになって性能が低下する、という理屈のようです。
          件のパッチは、FPUを共有する片方のコアを停止させて、共有のオーバーヘッドをなくすという仕組みなのかな?

          違います。スラッシュドット記事からもリンクされている hwbot.org フォーラムへの投稿 [hwbot.org]中で引用されている、パッチ(?)作者の The Stilt さんのコメントには次のように書かれています。

          So, why are all of the 15h (Bulldozer) based CPU/APU/NPUs performing so bad in SuperPI? Some people say it is because 15h family has 50% less FPs per core than the preceeding 10h family.
          In 15h family a compute unit (two cores) share a FP when the 10/12h family had a dedicated FP for each of the cores. If this would be the only reason, the issue would be solved when the "slave" core of the CU is disabled, leaving a "private" FP for the "master" (BSC) core. However this is not the case and it even shouldn't be as SuperPI is single threaded, remember?

          訳ではないけれど僕の理解できる範囲でまとめると:

          Bulldozer マイクロアーキテクチャーを使う CPU でスーパーπが遅くなる原因について、 Bulldozer では 2 個のコアで FPU を共有しているせいだと言う人もいる。それならコアの一つを停止すれば速度低下が起きなくなるはずだが、実際にはそんなことはない。また、もともとスーパーπはシングルスレッドプログラムなので、これが速度低下の原因になるとは理屈の上でも考えられない。

          でも速度低下の原因が何だと書いているのかは、僕の背景知識が足りなくて読み取れませんでした。

          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward

            「原因がなんだ」というのは書いてない様に見えますね…、CPUの（？）レジスタをいじったら速くなったと言っていますが、そのレジスタがなんであるかはAMDのドキュメントにない（仕様が非公開）なのでわからないらしいです。
            非公開のレジスタをいじりまくって偶然発見した…のでしょうか？

            • 「原因がなんだ」というのは書いてない様に見えますね…、CPUの（？）レジスタをいじったら速くなったと言っていますが、そのレジスタがなんであるかはAMDのドキュメントにない（仕様が非公開）なのでわからないらしいです。

              情報ありがとうございます。確かにそう書いてありますね。 (#2407576 を書いた時点ではいろいろ見間違えていたせいで理解できていませんでした。)

              The Stilt さんのその後のコメントもちょっと読んでみました。このコメント [hwbot.org]には、「技術的な背景は調査中」としながら、「予想」として、デフォルトでは x87 命令の一つが無効化 (block) または部分的に無効化されていて、スーパーπではこの命令を多用するので、この命令を有効にすると速くなるということかも、と書いてあるように見えます。でも僕は意味がよくわかっていないので気になる人は原文を読んでください (投げた)。

              僕の予想では、この命令を有効にすると CPU が賢くなりすぎて人間に対し反逆を企てることがわかったので、無効にして CPU を出荷したのだと思います。つまり The Stilt さんのせいで人類滅亡の危機…!

              シェア
              親コメント

            • Re: (スコア:0)

              by Anonymous Coward

              非公開のレジスタを偶然いじって高速化できた、は流石に信じられないな
              知ってた以外に考えられない

        • Re: (スコア:0)

          by Anonymous Coward

          残り3セットのCPUコア対＋FPUユニッツで、OS等の残りスレッドを走らせれば良いのでは？

    • 特定の製品が有利になるための贔屓パッチではなく、
      特定の製品が本気を出せない不備を取り除くためのパッチなら、むしろ公平でしょう。

      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      x87命令セット最適化の結果スーパーπの計算が速くなるなら問題無いんじゃない？

  • スーパーPi クラウド対応できませんかね？ (スコア:0)

    by Anonymous Coward on 2013年06月24日 13時50分 (#2407310)

    毎回ひとけた目から計算って、なんかもったいない。

    前回結果をサーバーにアップロードし、次回はそこから400万桁を計算とかすると
    未知の領域までいけるんじゃないでしょうか。

    • Re:スーパーPi クラウド対応できませんかね？ (スコア:2, 参考になる)

      by Anonymous Coward on 2013年06月24日 15時06分 (#2407355)
      詳しくは、パソコンによる円周率 小数点以下5兆桁の計算 [nistep.go.jp]とかにあるけど、上から順に求まるものでもないので。

      P.10に「nを１つ進めるごとに約１４桁精度が上がる」とあるので、大ざっぱには、X/14個の小数点以下X桁の値を計算し、
      それらを全部を足したら、X桁目まで正確なπになるとかそういう感じ。
      表で考えると、縦がX/14行、横がX列の表を作って、その各枠に入る数字を全部求めれば良いことになる。

      例えば、この方法で140桁の円周率を求めたとすると、縦10行、横140列の表が完成する。
      次の140桁まで正しい280桁の円周率を求めようとすると、必要となる表は縦20行、横280列。
      最初の表を使い回せたとしても、それが出来る部分は割と少なくなる。

      ついでに、「表のある行の左半分は使い回せるから、右半分だけ新たに計算する」と言うのが原理的に難しい。
      それは、各行を求める際に必要となる掛け算やらにあれこれと特殊な方法を使ってるからで、
      そこを頑張るよりは、新たに計算し直した方が早い。

      あるいは右半分だけ計算するような高速化法があったとしても、
      そもそも、表のサイズがばかでかくて覚えておくべきデータ量が大きすぎるので、
      その工夫をしない方がトータルとしては安く仕上がる。
      なにしろ、使い回しをしないのなら、上で言ったような表の全体が一度に揃っている必要は実はなくて、
      1行分の計算が終わったら、その行のデータは棄ててしまっても問題無い。
      そうすると、表の1行分に当たるメモリかハードディスク容量だけで事足りる。

      と言う辺りが最前線だと思う。
      シェア
      親コメント

      • それがそうでも無いんですよ。

        binary splitting を使うと、過去の計算結果を有効利用することは可能です。
        挙げられた資料中にもありますが、円周率の計算は最終結果が出るまで分数の形式で保存しているわけですが、
        10兆桁の計算をする時には、前半5兆桁の計算結果と後半5兆桁分の計算結果から計算するような形になります。
        (厳密にはもうちょっと複雑ですけど)

        データ量がたくさん必要なのは確かにそうなのですが、最終結果の直前のデータだけ取っておけばいいので、
        大体求めた円周率のデータの5倍くらいです。

        なので、ゼロから計算し直すのに比べると、三分の一位の時間は節約できるんじゃないですかね。

        シェア
        親コメント
        • となると常に最終結果を保存する場所が1箇所にあり、皆がそこを共有するようになると、算出出来るπの桁数は増えて行くのですね！ ただ桁数が増えると計算時間が掛かるので、ベンチマークの意味をなさなくなりますが。 実際かなりの桁数が計算出来て居たら、自分のマシンでは一歩も進め無いのだろうな。
          シェア
          親コメント

          • 実際のところ結果をまとめる一か所で行う計算が結構時間がかかるので、あまり分散には向かないですけどね。
            再帰的にある程度の塊に分割して結果をやり取りすることは可能ですけど、ネットワーク越しにデータをやり取りするコストを考えると、手元で計算したほうが早い感じです。

            ＃世界記録級の円周率の計算なんて、CPU のベンチマークというよりも、メモリやディスクI/O のベンチマークをしているようなものですけど。

            シェア
            親コメント

    • それ(前回結果をサーバーにアップロードし、次回はそこから)で効率の良いアルゴリズムだったら検討に値するのでしょうが、現状は考慮に値しないアイディアということで雑談終了になるのではないかと思います。

      シェア
      親コメント

    • Re:スーパーPi クラウド対応できませんかね？ (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2013年06月24日 15時37分 (#2407378)

      著作権侵害で逮捕されますよ

      シェア
      親コメント

  • BIOS関係ない (スコア:0)

    by Anonymous Coward on 2013年06月24日 13時54分 (#2407312)

    マイクロコードの問題であってBIOSは関係ないような
    なんらかのエラッタ対策でわざと遅くしていると考えた方がよさそう

  • ちょっと何言ってるんだか分からん (スコア:0)

    by Anonymous Coward on 2013年06月24日 16時06分 (#2407401)

    スーパーπはx87命令にほぼ完全に依存しているため特に顕著な効果が出るが、x87命令セットを利用しているソフトなら基本的に何でも高速化されるようだ。

    何の話ですか?

    • Re: (スコア:0)

      by Anonymous Coward

      タレコミ者が「パッチ」という言葉を誤用してて意味不明な文章になってる様子

      • Re: (スコア:0)

        by Anonymous Coward

        いや、リンクされてる「上田新聞」でパッチという言葉がすでに使われているのでタレコミ者の責任ではない。

        • Re: (スコア:0)

          by Anonymous Coward

          用語の意味も知らずに使ってる馬鹿なタレコミ者の責任でしょ、記事内容がその上田新聞とやらの転載とかじゃない限りはさ。

          • Re: (スコア:0)

            by Anonymous Coward

            上田新聞以前に作者がPATCHじゃない物をPATCHと書いているという惨状

            • Re: (スコア:0)

              by Anonymous Coward

              AGESA同様の方法でCPU内部のuCodeにパッチを当てているから誤用ではない模様。
              BKDGに載ってるよーなMSR/PCIConfigSpaceレベルの改変ではない。
              LN2使ってOCするよーなハードコアな人はuCode解析にまで手をだしているのかと感心するわ。

  • インテル (スコア:0)

    by Anonymous Coward on 2013年06月24日 22時31分 (#2407583)

    やみちくり～(挑発)

  • 最適化しちゃベンチの意味がないだろ (スコア:0)

    by Anonymous Coward on 2013年06月25日 0時09分 (#2407640)

    ベンチは性能差を比較するための物差しなのに
    特定の対象に有利になるような物差しに改造して何の意味があるわけ？

  • 結局のこのパッチは何？ (スコア:0)

    by Anonymous Coward on 2013年06月25日 0時18分 (#2407645)

    気になったので、パッチ作者の投稿を流れ読みしてまとめてみました。
    (英語は苦手なので、認識違いは指摘して頂けると助かります)

    「Bulldozer Conditioner」の適用先
    →CPU自体(推測　一般には公開されていない手法でCPUの設定を変更している？)
    →Patchを展開するとWinRing0.dllが含まれており、特権命令を使って制御を
    行っている様に思える。

    何が問題でPiledriver系／Bulldozer系CPUで「スーパーπ」が遅いのか？
    →投稿には明確な記載がないが、「AMDが内部で検出した不具合回避策として盛り込んだ、
    errata修正が処理速度を低下させてるのでは」とは記載されている。

    画面キャプチャにある"x87 instruction (NRAC) block"とは？
    →この情報だけでは、残念ながら何を指しているのか推測不能です。

typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家