何となく Blog by Jitta
Microsoft .NET 考

目次

Blog 利用状況
  • 投稿数 - 761
  • 記事 - 18
  • コメント - 37042
  • トラックバック - 222
ニュース
  • IE7以前では、表示がおかしい。div の解釈に問題があるようだ。
    IE8の場合は、「互換」表示を OFF にしてください。
  • 検索エンジンで来られた方へ:
    お望みの情報は見つかりましたか? よろしければ、コメント欄にどのような情報を探していたのか、ご記入ください。
It's ME!
  • はなおか じった
  • 世界遺産の近くに住んでます。
  • Microsoft MVP for Visual Developer ASP/ASP.NET 10, 2004 - 9, 2011
広告

記事カテゴリ

書庫

日記カテゴリ

ギャラリ

その他

わんくま同盟

同郷

 

インテル Parallel Studioを使って並列化プログラミングを試してみた(codeZine)より。

ん。。。また、違和感のある記事。。。

 しかしここ数年の間に大きな変化がありました。それはCPUのマルチコア化です。2006年にPentium 4シングルコアの製造が中止され、Intel Core 2が発売され始めた時、筆者は非常に衝撃を受けました。なぜならば、それは従来の開発技法が通用しないことを意味するからです。

記事を通して、従来のどのような開発技法が通用しなくなるのか、説明がない。まぁ、それは、次の説明から、推し量ることは出来る。

もう単一CPUの時代は終わり、CPUのマルチコア化が進んで行きますので、開発者もそれに伴って並列プログラミングをする必要性が生じました。

 今までシングルコアのCPUが主流だったからといって、並列プログラミングがまったくなかったわけではありません。今までもマルチスレッドプログラミングを行っていた人も多いと思います。この手法でもコア数が2ならば十分に対応可能でしょう。

 しかし、コア数が4・8・16・32・64・……と増えるにつれてこの方法では対処できなくなります。また、コア数を固定したプログラミング方法では、エンドユーザーがCPUを買い換えた時パフォーマンスがアップしません。エンドユーザーは新しいCPUを買えばシステムの性能がよくなると考えていますので、これではシステム不備だと看做されてしまうでしょう。今後コア数が増加することは目に見えていますので、新しい技術が必要なのは明白です。

なんだか違和感。

マルチ コア化が進んできたから、並列プログラミングをする必要が生じるのだろうか。そんなことはない。シングル コアであっても、並列プログラミングをする必要はあったし、そのメリットもあった。業務システムを作る上で、一番スピードを出しにくいところは、ユーザーが入力を行うところです。人が操作するスピードは、機械がどんなに速くなろうと、そうそう変わりません。その為、ユーザーが入力している間に何か処理をする、ということは、スピードアップについてとても有効です。はい、ここに並列プログラミングをする理由があります。

同じように、ネットワーク アクセス、ディスク アクセスなどの I/O が絡むところは、他の処理を並列に行う事でスピードを上げることが出来ます。CPU のスピードに比べて、メモリやディスク、人が処理をするスピードは、十分に遅いからです。


次、コア数。コア数が3以上と3未満とで、マルチ スレッド プログラミングに違いがあるのか?無いと思います。英語のウィキペディアから引用します。

Sun Microsystems(Wikipedia)より:

In the early 1990s the company began to extend its product line to include large-scale symmetric multiprocessing servers, starting with the four-processor SPARCserver 600MP. This was followed by the 8-processor SPARCserver 1000 and 20-processor SPARCcenter 2000, which were based on work done in conjunction with Xerox PARC. In the late 1990s this transformation was accelerated by the acquisition of Cray Business Systems Division from Silicon Graphics.[35] Their 32-bit, 64-processor Cray Superserver 6400, related to the SPARCcenter, led to the 64-bit Sun Enterprise 10000 high-end server (otherwise known as Starfire). More recently, Sun has also ventured into the blade server (high density rack-mounted systems) market.

Windows NT 4.0 の頃、マザーボードに2つの CPU を付けることが出来るものがありました。それと、ひとつの CPU でコアがふたつある状態。OS にとっては違うかもしれませんが、OS の上で動くアプリケーションにとって、何が違うのでしょう。

インテルの CPU は2つしか積むことが出来ませんでしたが、サン マイクロシステムズの CPU は、1990年代の初めでも4つのプロセッサーを同時に搭載可能でした。その後、8プロセッサー、20プロセッサーに対応したハードウェアが発表されています。私も、1997年頃に4プロセッサーの製品を使用したことがあります。(8プロセッサーの予定が、予算の都合で4に減った。その後、現地での最終試験中に「パフォーマンスが目標に達しない」事が判明。急遽“もう1台”追加することに。ハードウェアを納める筐体に収まりきらないというおまけ付き。)それまでの開発手法と、その時の開発手法、今の開発手法。特に意識して変えてはいません。「通用しなくなる」というのは、納得できない。

投稿日時 : 2009年9月18日 23:35
コメント
  • # re: 並列ナントカ
    えムナウ
    Posted @ 2009/09/19 1:03
    マルチコアの並列プログラミングとシングルコアの並列プログラミングの決定的に違うところは、マルチコアの場合はそれ専用のCPU命令(バスをホールドする)が必要でそれを使わないといけないところです。
    シングルコアの並列プログラミング(リアルタイムOSやWindowsのスレッド)の場合はそうでなくても可能です。

    私のくだんの記事の違和感は並列プログラミングが簡単に利用できる環境が整いつつあるという時代に前近代的なグローバル変数による例を提示しているところでなおかつ文面中に正しい解決策の提示がないところです。
  • # re: 並列ナントカ
    ognac
    Posted @ 2009/09/19 1:19
    グローバル変数の使用方法もさることながら、「製造でincrementし、消費でDecrementする」のはシングル処理でも、推奨されませんよね。生産量と消費量は別に保持して差で判断する。
    Ole2の参照数カウント問題は、それを暗示していそう....はともかく、グローバル変数を排他制御なしに増減するのが、とても違和感。
    複数スレッドから更新するのは極力避ける...などの基本こそ明記すべきだと感じたのですが.....
  • # re: 並列ナントカ
    かたぎり
    Posted @ 2009/09/19 13:37
    VBだって、マルチスレッドするんだよ<おい

    って、ヤマタノオロチに例えて記事書いてますけど、
    私の脳内ではすごく簡単で、CPUコアが増えるってことは
    仕事をする親スレッド=ヤマタノオロチ本体
    がいる山(CPU)がたくさんに増えて、
    クローンみたいな実体の影がその山にも増殖できて、
    かつそれぞれの本体の首(スレッド)がわさわさと酒をのむ、
    というイメージです。

    この時に、飲みに行きたい酒壺がひとつ
    (グローバル変数であり、位置が特定されたアドレスにあるもの)の場合、
    どの首も喧嘩しないように飲んで(競合制御)
    どれだけの酒が残ってて(その首から見ても単一の結果となるように排他制御)
    を考えて作るのは基本だし、CPUが増えようと減ろうと変わらない部分だとも思っています。

    プログラムソースや解説はともかく、
    「なんか良いデバッガでたよ」ということだけ
    言いたいのではないかなぁと読み取りました。
  • # re: 並列ナントカ
    Jitta
    Posted @ 2009/09/19 21:07
    コメントありがとうございます。

    記事だけなら黙ってるつもりでしたが、コメントへの返答が、なんとも(-_-;
    コンパイラによる出力を、プログラマが考えながらコードを書かなきゃいけないですか?んー、OpenMP の、pragma 使った書き方は、そういうものかなぁ。

    ちょこっと書きましたが、ロックする時間を長いままで放置しているのが、なんというか、コードの前の問題だろ、と。で、トーシロが書いたコードというシナリオだと。コード レビューしねぇのか?

    ヤマタのオロチはね、それぞれ自分が一番だと思っているから、他のやつらに譲ったりしないですよ(ナンカチゲー


    ってかさー。なんで「ありがとうございます」と「ありがとう」なの?見下してるの?
  • # re: 並列ナントカ
    Jitta
    Posted @ 2009/09/20 10:43
    > マルチコアの場合はそれ専用のCPU命令(バスをホールドする)が必要でそれを使わないといけないところです。
    これ、なんとなくわかるのですが、でも、CPU 命令を使い分けるのは、コンパイラ(or リンカ)の仕事ですよね?
    エピさんのコードでは、シングル コアでは必ず結果が 0 に固定しています。これは、X+=Y の計算式の間でスレッドが切り替わらないからだと思います。しかし、デュアル コアで実行すると、結果が一定しません。これは、X+=Y の計算式が、同時に複数実行中だからだと思っています。このとき、Win32 コンソール アプリケーションでプロジェクトを作成し、デュアル コア上でビルドした実行ファイルを、シングル コア上に持って行って実行しています。CPU の命令が違うのであれば、このような可搬性はなくなるのではないでしょうか。
    それとも、コア数によって、実行時にリンクするライブラリを切り替えている、ということでしょうか。
  • # re: 並列ナントカ
    なぜ?
    Posted @ 2010/06/30 7:55
    10万回程度じゃ、スレッドのタイムスライス使い果たさないか、使い果たしたとしても回数が非常に少ないでしょ。
    つまりスレッドの切り替え自体がほとんど起こらないので競合が発生する確率がはるかに小さくなります。
    競合が発生しないわけじゃありませんよ。

    マルチでもシングルでも、競合の発生する同じコードを実行してます。
  • # re: 並列ナントカ
    なぜ?
    Posted @ 2010/06/30 8:03
    Interllocked~を使った場合は、シングルではバスのロックなどは必要ないですが、マルチコアではそういう仕組みが必要になります。
    つまり実行環境での違いの話でしょう。
  • # re: 並列ナントカ
    なぜ?
    Posted @ 2010/07/09 19:43
    人間の操作や、IOの遅さあるいはリソースの独立性を意識しての、
    つまり非同期処理的ことを念頭においたマルチスレッド処理と、
    サーバーなどの処理の独立性と大量リクエストを多数のコアで捌くためのマルチスレッド処理、
    ひとつの処理を多数のコアでパラレル処理することによるパフォーマンス向上を目的としたマルチスレッド処理では、
    基盤となる技術要素は同じであっても、意識するレベルはかなり違いますよ。

    下に行くほど難易度も大幅にアップする事も多いですしね。
    パラレルは条件によってはかなり簡単な場合もありますが。

    基本的にスケーラビリティを追及する必要がある場合とない場合では
    意識する事も難易度も全然違います。
タイトル
名前
Url
コメント