パスワードを忘れた? アカウント作成
332937 story
ハードウェア

マイクロプロセッサの未来、将来のコンピュータスタイルは ? 57

ストーリー by reo
create the future 部門より

Communications of the ACM にて米 Intel の Shekhar Borkar 氏と Andrew A. Chien 氏による "The Future of Microprocessors" という記事が掲載されている (Publickey の記事より) 。

クロック数の向上は数年前から頭打ちとなり、その代わりにマルチコア CPU が台頭してきたのだが、コア数の増大は電力消費量の増大にもつながり、現実的な消費電力を規定するならばコア数と周波数は制限される。この制限の下でどのように性能向上を図っていくかが論じられており、コアに与える役割の模索や、ハードウェアカスタマイゼーションが挙げられている。また効率的な並列化を実現する言語、フレームワーク、ソフトウェアアーキテクチャの必要性についても触れられている。

かつては個人が所有するコンピュータの余剰資源を集約して様々な分散計算を行わせる取り組みが推進されてきたが、十分に高速な伝送を実現できるネットワークが整備されるならば、よく言われることではあるけれども再び集中の時代へと戻っていくのかもしれない。果たして 10 年後、20 年後のコンピュータ利用スタイルはどのような形になっているのだろう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2011年06月06日 12時56分 (#1965458)
    せっかく個人がコンピュータを手にしたのに、また取り上げられるなんてまっぴらごめんだ。 俺はこのまま自分による自分のための自分のサービスを自宅サーバ内に作り続ける道を選ぶぜ。
  • 十分高速なNW (スコア:2, 参考になる)

    by bochi-bochi (4490) on 2011年06月06日 11時58分 (#1965386) ホームページ 日記
    実効速度で安定して2桁M欲しい。
    社内イントラですら10Mでないことはザラ。
    それもサーバネックならともかくケーブルが腐ってたり…orz

    シンクライアントはそれからにしてくれ。
    --
    〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
  • by jsi (25633) on 2011年06月07日 8時56分 (#1965938)

    GRAPE-DRのような斬新的なアーキテクチャが発表されていますが、
    当分x86/x64にとって代わられることはなさそうですねえ。Itaniumでさえ..

    http://grape-dr.adm.s.u-tokyo.ac.jp/system.html [u-tokyo.ac.jp]

  • 並列化 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年06月06日 11時42分 (#1965371)
    >効率的な並列化を実現する言語
    効率的なのはもちろんだけど、あえて「ここは並列で!」なんて指示しなくても良きに計らってくれるくらいでないと、なかなか厳しいと思う。
    #pragma omp parallelうねうね。
    • by Kuritsukasa (41955) on 2011年06月06日 11時47分 (#1965374)
      やっぱりFORTRANですか.
      #Fortranじゃないよ
      親コメント
    • 単純に繰り返しの代わりにスレッドを起こすだけで、結構な問題をカバーできる。
      # ループ間の依存関係があるとちょっと工夫しなければならないが。

      そのためにはスレッドを簡単に起こす必要があって、スタックやTCBを割り当てたりなんてのでは困る。ではどうするかってーと、昔なつかしのスタックコンピュータならレジスタセットの代わりにスタックを積んでいるので命令一つでスレッドを起動できる。内蔵スタックが溢れたら例外起こしてメモリを割り当てればいい。

      スタックコンピュータは連続した命令が非常に強い依存関係にあるというパイプラインによるスーパースケーラとしては致命的な欠点から廃れたのだが、SMTなりSMPなりが前提になるとスレッド間の依存関係がないのでスレッドから順繰りに命令を投入するだけで済む。ゆえにその欠点はまったく問題にならない。それどころか分岐予測やアウトオブオーダ、投機実行などのでかい回路が完全に不要になり、元々回路規模が小さいスタックコンピュータの小ささが際立つようになる。

      親コメント
    • by Anonymous Coward

      C/C++は抽象度が低すぎるから勝手に並列化するのはかえって難しいんですよ。
      プログラマの「人間様である俺様がもっとも高速なプログラムを書けるんだ」信仰と、それを支えるC/C++にover optimizeされたハードウェアアーキテクチャのせいでいつまでたってもC/C++支配は終わりそうにありませんが。

      • by uchida-t (14803) on 2011年06月06日 12時40分 (#1965437)
        並列なら純粋関数型言語バンザーイってことで、みんなでHaskell使いましょう。
        親コメント
      • by greentea (17971) on 2011年06月06日 12時20分 (#1965407) 日記

        手続き型言語は順次実行されるという概念が、並列化を妨げてる気がする。

        例えば、C/C++っぽいものを使うにしても。
        ・並列可能なブロックを二重波カッコで区切る
        ・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつける
        とでもしたら、マシになったりしないかなぁ?

        例えば
        int main(){
         foo();
         bar();
         {{
          hoge1();;
          hoge2();;
          hoge3();
         }}
         ;;
         baz();
        }
        としたら、foo()とbar()と、{{hoge1(), hoge2(), hoge3()の順次実行}}を並列にして、その全てが終わるのを待ってからbaz()を実行する、といったように。

        # スレッド分割、順序入れ替えを行うか行わないかはコンパイラ判断で。

        --
        1を聞いて0を知れ!
        親コメント
        • by wirehead (37047) on 2011年06月06日 13時22分 (#1965497)

          Objective-C + Cocoaだと、ブロック(いわゆるクロージャ)で並列部分を記述してNSOperationQueueに好きなだけ突っ込み、
          waitUntilAllOperationsAreFinishedメソッドで待機すればお望みのことが可能ですよ。(Grand Central Dispatch)
          フレームワーク側でCPUコア数などを勘案し、スレッドを準備してくれます。

          参考リンク
          http://decafish.blog.so-net.ne.jp/2008-04-23-1 [so-net.ne.jp]

          親コメント
          • by greentea (17971) on 2011年06月06日 14時08分 (#1965536) 日記

            私の書いたコメントで、最も大切な部分は、ブロックではなく、
            明示していない限り、すべての文の実行順序が不定になることです。

            何かのライブラリやら組み込みクラスやらを使って、
            ユーザが明示的にマルチスレッドにする部分を書くようじゃ、
            pthread使うよりは簡単だねってだけの話です。

            --
            1を聞いて0を知れ!
            親コメント
            • by passer-by (13494) on 2011年06月07日 0時12分 (#1965853) 日記

              Makefile?

              親コメント
            • by Anonymous Coward

              同意。
              method/function callは原則として非同期実行に置き換えていいと思う。
              同期が必要な部分だけ宣言すればいい。volatileやcritical sectionがすでにあるんだし。

            • by Anonymous Coward

              実行順序不定ってものすごく大きいパラダイム変化でしょ,言語にとっては.

              その時点ですでに手続き型言語とは別物だと思うし
              このコメント [srad.jp]でも言われているけど,
              そんなことを後付けで中途半端にやるくらいなら
              関数型言語マンセーでいいじゃん

              • by greentea (17971) on 2011年06月06日 16時17分 (#1965605) 日記

                そうかな?
                もともと、引数の評価順序みたいに、ごく自然に実行順序不定となるところはC/C++にあったのだから、大きな違いはないと思うよ。

                実際にそれを利用して、マルチスレッド化された実行ファイルを出力するコンパイラの実装は、大きく変わるかもしれないけど、
                OpenMPみたいなのが作れてるし、それに言語仕様としては実行順序が上から順でも問題ないのだから、段階的に並列度を高めていく方法もとれる。

                関数型言語は魅力的だし、ついこないだCはオワコン的なストーリーも出たばっかりだけど、
                それでも、C/C++系言語が今のコンピュータ動かす上で、LispやらHaskellやらの関数型言語よりも、大体の場合において効率がいいし、
                その状況を変えるほどに革新的な関数型言語の実装が現れない限りは、この状況は続くんじゃないかなぁ。

                --
                1を聞いて0を知れ!
                親コメント
        • by taka2 (14791) on 2011年06月06日 17時13分 (#1965629) ホームページ 日記

          手続き系言語で並列実行できるようにする場合のキモは「いかに確実かつ高パフォーマンスに処理をスレッドセーフにできるか」といった所じゃないかな。

          簡単な記述で並列実行を指定できるようになっても、それだけじゃ美味しくないというか、
          その個々の処理間で並列処理のためのロックだとかそのあたりの問題の方がよっぽど大変というか。

          スレッドセーフの自動化といっても安直にデータアクセス全部にロックが入るようではパフォーマンスの低下がひどいことになりそうだし。
          そのあたりをちゃんと解析して必要最小限なロックだけで済ませてくれるような処理をコンパイラがやってくれるならうれしいんですけどねぇ…

          親コメント
          • by greentea (17971) on 2011年06月06日 17時48分 (#1965652) 日記

            並列化をするかしないかはユーザに任せないつもりで書きましたが、自動ロックは考えていません。
            i++; i++; って書いたとき、iがどうなるかは未定義でいいと思います。

            --
            1を聞いて0を知れ!
            親コメント
        • by Anonymous Coward

          C言語で副作用完了点をまたがず順序に依存した処理を書くと未定義になったり、C++0xのsequenced-before関係が半順序だったりするのはできるだけ並列化を妨げないためなんですよ。

        • by Anonymous Coward

          .NET Framework 4.0 の Task とかで似たようなことができるんじゃなかったっけ

        • by Anonymous Coward

          OpenMPのようなもの?

        • by Anonymous Coward

          ・並列可能なブロックを二重波カッコで区切る
          ・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつける

          なんだそのOccam擬きは!
          Transputerって登場が早すぎたんじゃないだろうか?と思うんだな

          ちなみにIntelがどんなにがんばってたくさんのCPUコアをオンチップにしてもメモリの帯域が狭くなる一方だとおもうのだ。
          バスの多重化でメモリへのアクセス速度が上がらないとどんなにプロセッサを増やしても頭打ちになるからこの方向で技術の華が開くならメモリとバス関係のブレークスルーが絶対必要だと思う。

          #CSPってなんではやらないだよう >_<
          #OccamらぶりーなAC

        • by Anonymous Coward
          記法こそ違いますがOpenMPでできますよ。並括弧に前に #pragma omp parallel/sections/section で注釈を付ければ並列実行されます。
          スレッド分割や順序入れ替えはコンパイラというか実行時判断になりますが。
    • by Anonymous Coward
      もうメンドクサイから言語なんか関係なく、OSが実行形式から自動で並列化してくれないかな?
      逆アセンブリしてループを見つけて、並列化できそうなら自動で命令文書き換えて・・・もちろん俺にはできませんよ( ̄ー ̄)
      • by greentea (17971) on 2011年06月06日 12時38分 (#1965432) 日記

        むしろ、Intelにがんばってもらって。x86命令デコーダがμオペレーションレベルで自動並列化してくれるのを期待しましょう。

        --
        1を聞いて0を知れ!
        親コメント
      • by Anonymous Coward

        CPUとプログラマブルDSPが統合されて、演算処理内容に応じてCPUとDSPが協調動作してくれると嬉しいかも。

      • by Anonymous Coward
        OSが自動並列化してくれると、エミュレータを使って古いOSも高速化出来そうですよね。
  • by kikki (30639) on 2011年06月06日 12時15分 (#1965402)
    ・メモリ階層を無くす
    記憶装置の階層が単一で不揮発で速度と容量が十分、となって欲しいです。

    ・記憶と演算の融合
    演算装置が大容量メモリを内包するか、個々のメモリ素子が演算機能を持つか、イメージとしては後者で。

    と書いてみて思いましたが、この2つ、片方だけ実現する感じでは無いですね・・・
    どうプログラミングするか?・・・さぁ(笑)
    • by d5 (42418) on 2011年06月06日 12時23分 (#1965410)

      >記憶装置の階層が単一で不揮発で速度と容量が十分、となって欲しいです。

      データがとっちらかって揮発性でど忘れ思い出し時間がかかるし、容量が哀しい脳細胞。

      >演算装置が大容量メモリを内包するか、個々のメモリ素子が演算機能を持つか、イメージとしては後者で。

      協調性がなく独立して矛盾することを考えるというのが哀しい脳細胞。

      >どうプログラミングするか?・・・さぁ(笑)

      アプリオリにプログラミングされているらしい。

      親コメント
    • by the.ACount (31144) on 2011年06月07日 11時56分 (#1966026)

      脳だって短期記憶と長期記憶がある。
      そもそも階層がないと組み合わせ爆発で思考すらできない。
      容量が大きくなるとn個情報の関係はn乗で増えるから、階層を増やさないと逆に機能が低下する。
      記憶容量の増大はそれ以上のアクセス困難を招くから、記憶と演算の融合どころか更に高機能な記憶システムを必要とする。(ウェブ検索システムみたいな)

      --
      the.ACount
      親コメント
  • 分散したり集約したりしながら、徐々に「空間における計算機密度」的なものが増えている気がする。1m3当たりに存在する計算機の量というか…

    きっとそのうち、「ここからここまでが1台」的な感じが利用者側には見えなくなるんじゃないかと期待しているのだが…

    --
    fjの教祖様
  •  分散と集中、というのは概念的にちょっと微妙な表現ですね。

     クラウドは、ものすごく簡単に言えば分散したリソースを統括管理することで高性能で可用性の高いホストマシンとして利用するというシステムです。仮想的とはいえホストが一つのサーバとして見えているのでクライアント側から見ればホスト集中管理に見えますが、サーバ側は分散リソースを統合管理しているというシステムがクラウドなわけです。
     クライアントから見て、どのリソースを利用しているのがが雲のようにもやっとしていて見えにくいからクラウドと呼ばれているわけで、ホスト側の本質は分散コンピューティングと変わりません。

     まあ、ここで言われてる内容は端末のコア数が消費電力の関係で頭打ちになるからネットワーク越しにCPUリソースを利用することでその制限を回避しようというのが主眼であって、ネットワークの向こう側でリソースを管理する仕組みはどっちでもいい話ですが。

    --
    しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
  • たぶん、ユーザーフレンドリーなインターフェースになるような軽い処理のできるプロセッサと、

    高速に処理をするプロセッサの2極化すると思われます。

    まあ、今もその傾向は見えますが。
  • 発電が分散するから処理も分散する。

    タダの箱、電気があってもタダの箱。
    --
    Aaron Rashid
  • レゴブロックの安易さで自作できるヤツを期待します。
    M/Bは、CPUブロック、メモリブロック(主記憶とデータは別ね)、
    I/Fブロック、バッテリーブロック、を適当にさしても動くように
    (それぞれ、ブロックIDで通信してください)。グラボブロックは、
    多ければ多いほど(パワーGブロックとか、エコノミGとか)
    M/B同士も通信できて... 繋がる繋がる♪

    配置の仕方で高速化できたりして、コンテストとかあったり。
    そして、やっぱりスネオ見たいなやつもいて...

    # 現実的には、1箱に複数のmini-ITXがブレードみたいにささると...
  • データロストの可能性を個人レベルで心配しなくていいシステムができて欲しい。
    ローカルPCのストレージはキャッシュとして機能して、どこのPCからでも
    自分の環境およびデータにアクセスできること。

    OSやアプリケーションのインストールしたり、アップデートするのは面倒なので、
    情報漏洩の危険性を考えなければこれが理想。

    • これに一票。

      とはいえやはり「手元に置いといて他所には置いておきたくないデータ」もあるとは思うので、
      「いつでもどこでもオンラインストレージ高速UP/DOWNLOADステーション」(ビコビコーン)が欲しいな。
      ステーションと言いつつ、無線でつながればいいんで物理的実態が必要なわけではないんですが。

      どっかと契約してWiMAXで繋いで、とか今でも似たようなことはできるんでしょうけど、もうちょい意識せず”ゆびきたす”にできればなぁ、と。

      親コメント
      • by Anonymous Coward

        Chromebook + Pogoplugですな
        ChromeOSはPogoplugサポートがないようですが実現して欲しいものです

  • by Anonymous Coward on 2011年06月06日 13時19分 (#1965494)

    長く使うことを考えて、最近Core i7 2600を買った。4コア8スレッド、3.4Ghz。

    周波数を上げることは難しい、コア数増やすことも難しい。
    とすると、5年後くらいにやっと、8コア16スレッド、5ghz程度になって、買い替えると性能アップが分かると言うわけだ。
    1つのCPUを5年使えるってのは、良いな。今までなかった。

    • by Anonymous Coward

      もうすでに5年以上使い続けてる。

    • by Anonymous Coward
      Ivy Bridge出ますよ。
  • by Anonymous Coward on 2011年06月06日 14時07分 (#1965534)
    現状でも光いれてれば外から自宅鯖でクラウド作れるし、
    Clarkdaleレベルで仮想OSの2・3個回せるし。

    ボトルネックは回線の金額くらいじゃないかな?
    自宅鯖クラウドするには、
    最低月1万以上はネット代にしなきゃならん。

    ケータイもスマホもPCもMacも鯖も
    どこでもつなげられる対価に年間12万って高すぎでしょ。

    1/10位にコスト下げて、
    ようやく本来の性能限界を使い倒せる時代が来る
    ってのが現状な気がします。

    並列化の機能追求は、
    XeonやOpteronやGPUに任せて、
    そろそろコンシューマー向けは、
    使い道の適正化へ注力していただきたいもんだ。
    • > 現状でも光いれてれば外から自宅鯖でクラウド作れるし、

      「クラウド」の定義次第だとは思うけど、それは一般的にはクラウドじゃないでしょ。
      親コメント
    • by Anonymous Coward

      10年使って12万の茶碗や10年使って30万の腕時計や
      10年使って50万の財布はなかなか売れないのに

      年間12万の電話代なら払ってもらえるという事実を考慮すれば
      商売人が簡単に値下げ方向に向かうようなビジネスをやるとは思えない。

    • by Anonymous Coward

      > ボトルネックは回線の金額くらいじゃないかな?
      > 自宅鯖クラウドするには、
      > 最低月1万以上はネット代にしなきゃならん。

      同意だけど、電気代忘れてません?
      計画停電のおかげで、自宅サーバを全部VPSに移行したら、
      過去実績から、回線と電気代で年間50万以上安くなったけど。
      # 最低と言ってるんで、判ってるとは思いますが。

      • by Anonymous Coward
        >自宅サーバを全部VPSに移行したら、 >...回線と電気代で年間50万 Hmmm...いったい何をしているのでしょうか。自宅で。
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...