パスワードを忘れた？ アカウント作成
Close
3872 story

Pentium4 も Hyper-Threading 対応 60

ストーリー by wakatono
是非マルチプロセッサ対応も… 部門より

SHNSK 曰く、 "IDF2002 Fall で Intel の発表したところによると3GHz 版から Pentium4 も 一つの CPU を複数の CPU に見せる Hyper Threading に対応するようです(ZDNNの記事)。

従来は Hyper Threading で Xeon と Pentium4 の差別化を計って来た Intel ですが、ここに来て Penitum4 にも Hyper Threading 対応にして来たということは cache の量やマルチプロセッサへの対応など、違う尺度でも Xeon と Pentium4 を差別化できる自信がついてきた見て良いでしょう。"

Hyper-Threading対応のPentium4対応ロゴは、ロゴの右上にHTと小さく入っている。このロゴが貼り付けられたPCが出てくる日も遠くなさそうだ…

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

Pentium4 も Hyper-Threading 対応 More

  • 久々に遊べそうなCPUかな？ (スコア:2, 興味深い)

    by gg_pic (10157) on 2002年09月11日 15時59分 (#163962)
    Xeonでですが、Hyper-ThreadingをONにすることによりTMPGencでのエンコード速度が60%高速化 [ascii24.com]したそうです。(ページの中ほど参照)

    INTELの言う25%高速化というのもあながち嘘ではないでしょうね。もちろんHyper-Threadingにも得て不得手があると思いますが型にはまると60%も高速化すると。AMDのモデルナンバーもこうなってくるとこのまま使用していくのも難しくなりそうですね。

    重たい処理を要求するようなソフトは大抵マルチプロセッサに対応していますし、"新規格"の割には即効戦力になるでしょうね。
    今までにこれほど即効性、効力に優れた新規格があったでしょうか。毎度の事ながら相性問題もちょっと増えるかもしれませんが私は素直に楽しみですね。

    ＃これだけH-Tを持ち上げておきながらとりあえず人柱の報告を待つであろう事は言わずもがな。

  • やっと来たかー。 (スコア:1)

    by ryo_aotuki (10773) on 2002年09月11日 11時04分 (#163805)
    ってな感じです。Willametteの頃から実装されてたけど
    ママン側で無効にされてるとかは結構有名な話ですな。
    Alphaプロセッサの特許に抵触するとか何とか [impress.co.jp]。
    本気を出したPentium4を早く見てみたいところです。

    # やっぱNorthwoodになってもCeleronじゃ無効なのかなぁ。(￣∇￣

  • これって (スコア:1)

    by take0m (4948) on 2002年09月11日 11時11分 (#163807) 日記
    HTありとなしが並売されるってことなのかな？
    それとも3G以上はHTありのみなのかな？
  • Hyper-Threadingの機能を有効にすると、OSやアプリからは複数のプロセッサが存在するように見えるそうですが、Windows XP Homeだと使用可能なプロセッサ数って1に制限されていませんでしたっけ。

    ホームユースPCであろうとも、最新のCPUを乗せていきたいPCメーカーは、XP Pro.(以上)を搭載しないといけなくなるのかな。
  • 「マルチプロセッサシステムには対応しません」と明記されたドライバや、そうでなくともマルチプロセッサなシステムで動かすとヘボヘボになるドライバって少なくはない気がするのですが。

    ソフトウェア側からはSMPシステムと同様に見えるんですよね＞HT
    HTだときちんとサポートされるのかしらん。

    ＃個人的にはDVD-RAMのドライバを何とかして欲しい＞松下。
    • SMPに対応してないデバイスドライバはHTをイネーブルにした環境でもダメでしょうね。

      正直ATアーキテクチャは割込処理がカナーリしょぼいので
      SMP環境で、割込サービスルーチンをもうひとつのCPUに
      やってもらうだけでかなりシステムパフォーマンスがよくなります。

      そろそろ spinlockを知らないデバイスドライバには退場してもらう時期でしょう。
      シェア
      親コメント
      • SMPでおかしくなるのってサウンドカード、オーディオカードに多いですね。
        そう言う意味では、Dual G4のMacにはがんばって欲しいです。
        OSはちがえど、ドライバ書きにSMP当たり前の環境を刷り込むために、ね(笑)
        個人的にはSMP不可=ドライバ(とその書き手)の品質が悪いと自白　という印象が…
        --
        # rm -rf ./.
        シェア
        親コメント

        • Re:ドライバサポートはどうなる？ (スコア:2, 興味深い)

          by SteppingWind (2654) on 2002年09月11日 18時01分 (#164013)

          > 個人的にはSMP不可=ドライバ(とその書き手)の品質が悪いと自白　という印象が…

          私もFreeBSDのSMP環境でサウンドドライバを書いていますが, 資源管理と排他制御をOSの流儀に従って実装すれば, そんなに難しい物ではないように思えます. とは言ってもENVY24の4枚ざし, 32チャンネル96kHz同時録音なんてことをやったらどうなるか分からないので大きなことは言えないのですが.

          シェア
          親コメント

          • Re:ドライバサポートはどうなる？ (スコア:2, 興味深い)

            by brake-handle (5065) on 2002年09月11日 18時42分 (#164030)

            SMPng(machine-independentな方)に関わっている身として。それはSMPもさることながら、応答時間を保証する努力もしないといけませんね(一応p4のbranchにはpreemptable kernelもあるけど)。

            Giantがのさばっている現状では、preemptできる部分が長くなればこちらもある程度は解決できそうです。ただし、interrupt threadまでもがpreemptされる状況が生じると受信livelockに似た現象に陥る恐れがあるので、万能ではないでしょう。音声や動画向けに等時的なschedulingをするのが正しい姿なんでしょうね(どっかのOSでやってた、Uresh Vahaliaの本には書いてある)。

            シェア
            親コメント

      • Re:ドライバサポートはどうなる？ (スコア:2, 興味深い)

        by brake-handle (5065) on 2002年09月11日 18時54分 (#164036)

        それには一つ条件があります。割込のcode pathが、ほかに実行されているthreadと衝突するようなlockを使わないことです。lock獲得待ちによる遅延の見積もりはなかなか難しく、realtimeを実現する上でやっかいな障害となっています。

        決定打はまだ見つかっていませんが、例えばlock ceilingをやるとか、per-processor lockを使うなどの工夫である程度押さえこめることは分かっています。lockをバリバリにかけるんじゃなくて、必要最小限にさせるという注意も必要ですね。

        ところで、例えばWindows用にドライバを書いてる人たちって、OSの知識はどれくらい持っているもんなんでしょう?

        シェア
        親コメント
      • …HTじゃ割り込み周りは改善しないとおもうぞ
        インテル曰く
        「キャッシュ、実行ユニット、分岐予測器、コントロール・ロジック、バスなど、物理プロセッサ上のその他のリソースについては2つの論理プロセッサ間でほとんどすべてを共有します」
        ってなってるし
        参考文献 [intel.com]

        • ぁ やばっ (スコア:2, 参考になる)

          by Y.. (7829) on 2002年09月11日 13時46分 (#163907) 日記
          すぐしたに
          「各論理プロセッサには専用の割り込みコントローラ (APIC) が用意されます。これに よって、各論理プロセッサは、自分に送られた割り込みのみを処理できるようになっています。」
          って書いてあるよ 改善するじゃん…
          #前のコメントマイナスモデレートしてやってください…
          シェア
          親コメント

        • CPU内での競合による遅延の恐れ (スコア:2, 興味深い)

          by brake-handle (5065) on 2002年09月12日 0時29分 (#164190)

          論理プロセッサ間でキャッシュを共有と読んで、i386が苦手としているmemory accessが気になったので調べてみたのですが...

          2つの論理プロセッサがキャッシュ内のデータを共有するため、キャッシュ内で競合が起こるとパフォーマンスが大きく低下する可能性もあります。

          予想通りの答でした。平均的に見てcacheは半減と見るべきでしょうね。さらに、page coloringをやった場合、狙ったcache lineを相方がことごとくつぶしていたという目に遭う可能性もあります。これはkernel memory allocatorの性能に影響するので、alloc-freeを繰り返す(I/O intensiveだとこうなることが多い)場合に足を引っ張る恐れがあります。

          そして、何よりも恐いのが論理プロセッサ間でのリソース奪い合いですね。ものが1つしかない以上interlockでも使うしかないでしょう。となると、interlockをとれるまでの待ち時間が新たな遅延としてかかってきます。ただでさえcache miss(しかもi386ではまず制御不可能)で遅れがあるのにさらに遅れの要因を持ち込むとは... 一番きれいな答えはきちんとプロセッサ内のブロックを二重化することですが、そんなことをするんだったらRISCでmultiprocessorをやった方がずっと外乱が少なくて楽そうな。

          シェア
          親コメント
  • > cache の量やマルチプロセッサへの対応など、違う尺度でも Xeon と
    > Pentium4 を差別化できる自信がついてきた見て良いでしょう。"

    動作クロックをあげることで性能向上を計る戦略に
    限界が見えてきたからかも。

    むしろ他社との差別化を計りたいんじゃないかなぁ？？

  • 裏側で動いてるアプリケーションのおかげで、フォアグラウンドアプリケーションがモタついたりするのが少なくなれば、十分にありがたいですね。

    メーカー製マシンの場合は初期出荷状態からウイルススキャン等のアプリケーションが大量に動いてる事が多いですから、それらに対して Hyper Threading が機能するだけでも十分に有用なのではないかと。

    余談ですが、これからはスレッド化しないと「CPU能力フルにぶん回す」アプリケーションが本当に作れなくなるのですね。フリーソフトウェアなどでもスレッド対応が当たり前な時代がくるのでしょうか。 個人的には「いちいち小物アプリケーションでマルチスレッド化なんてやってられるかよ！」と思ってるのですが…（ょゎ

    Takeshi HASEGAWA

    • 裏側で動いてるアプリケーションのおかげで、フォアグラウンドアプリケーションがモタついたりするのが少なくなれば、十分にありがたいですね。
      GUIゴリゴリなOSが流行りなので、画面表示とドライバ周りでひとつ、フォアグラウンドアプリケーションでひとつ、合計2つ使えさえすれば充分美味しい...

      ってことはないかなぁ。アプリケーションが画面表示する時って、同じスレッドのまんまカーネルとかドライバとかまで行ってしまうのかな？

      --
      =^..^=
      Enjoy Computing, Skiing, as much as Horse Racing.
      シェア
      親コメント
    • そう考えると、HTの場合、
      シングルスレッドでもこれまでとほぼ同等の性能は出る
      （これまでと比べて遊んでしまう部分が増えるわけではない）、
      というのがポイントなんでしょうね。
      より低いクロックのマルチプロセッサと比べた場合、ですが。
      シェア
      親コメント
    • メーカー製マシンの場合は初期出荷状態からウイルススキャン等のアプリケーションが大量に動いてる事が多いですから、それらに対して Hyper Threading が機能するだけでも十分に有用なのではないかと。


      Hyper Threading は内部の実行ユニットの利用を並列化するものなので、キャッシュなどの I/O まわりは従来のままですね。
      ということはウィルススキャンのように CPU 内部の処理よりは I/O アクセスの比重が大きい処理ではあまり恩恵が受けられないでしょう。
      といっても、並列動作しているもうひとつのスレッドが比較的 I/O アクセスが少ないものであれば期待できますが。

      うれしくない例:大量のファイルをコピー中にウィルススキャンとか。

      それでも、HTなしよりも遅くなる可能性といえばlock関係とキャッシュのミスヒットぐらいですから、ある程度長い時間で見れば確実に効果があると考えてもいいでしょうね。
      他にもHTなしよりも遅くなると考えられる状況があれば教えてください。
      --
      うじゃうじゃ
      シェア
      親コメント

      • CPU内部でもユニットの共有をしているとなると、OSが決めたpriorityをきちんと各ユニットのlock管理に反映させなければ結果としてpriority inversionが起きて不必要な遅延を生じる恐れはないでしょうか? どうもIntelの解説 [intel.com]を見ても、この問題に触れているところが見つかりません。

        一体どうして、こうも外から状況が掴めないものを作りたがるんだか...

        シェア
        親コメント
  • HTがもさることながら、同時に発表されたBaniasにはびっくりしました。
    これは今まで言われてたような、Crusoe対抗どころかCrusoeを無効化してしまうような気がする。
    なんせIBMに「バッテリー・ライフに大きな差を認められるほどではなく [ibm.com]」と言わせた超低電圧版PentiumIII と同程度の消費電力で、現役のPentium4-Mと互角かそれ以上のパフォーマンスを出しちゃう(とIntelは言っている)わけですから。

    ZDNETの記事 [zdnet.co.jp]
    PC Watchの記事 [impress.co.jp]

    # なんかすっとぼけたことを言ってるような気もする。

    • しかし (スコア:1)

      by take0m (4948) on 2002年09月12日 9時51分 (#164302) 日記
      モバイル用途の場合には、ご存じのようにCPUの電力消費量よりも
      液晶やバックライトや各種デバイスがかなり大きな割合を
      占めつつありますから、そちらが削減されないと、バッテリーが
      2倍長持ちとかはありえない訳で。

      そんな訳でBanias程度だと、やっばり2時間しか使えないわけですね・・・

      Intelも当初はブレード用途も考えていたのかも知れませんが、
      こう景気が悪いとね・・・あんな高価なサーバ使うところは
      少ないんだろうなぁ。
      シェア
      親コメント

  • Linuxの派生物の話だが (スコア:0)

    by Anonymous Coward on 2002年09月11日 11時37分 (#163817)
    マルチプロセッサに対応していない（と作者が公言する）OSの場合
    HTの恩恵にはあずかれないの？
typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者