無差別に技術をついばむ鳥

こんにちわ♪インドリです♪時間が経つのは早いもので、つい最近まで蝉が鳴いていて夏ムードだったのに、日が暮れるのが早くなり、夜になると秋の音が聞こえるようになってきました。鈴虫とかの鳴き声はムードがあっていいですよね♪夏に冷房をカけて涼しく読書するのも良いものですが、夜に鈴虫の声を聞きながら読書するのもまた良いものです♪
私は夏の情熱的な雰囲気が大好きなのですが、秋の物悲しい雰囲気もまた好きです。そろそろ秋の兆しが見られるようになってきましたので、皆様も出勤時や帰宅時にちょっと気を緩めて秋を探してみては如何でしょうか？きっといい気分になれると思います。
突然ですが、最近のマイブームは並列処理です♪並列処理って奥が深いですよね♪マルチスレッドプログラミングは業務で沢山してきましたが、それでも並列の真髄はまだまだ分かりません。これからはマルチコアCPUが当たり前の時代になりますので、マルチスレッドを慣れていない人はマルチスレッドプログラミングを、マルチスレッドをしてきた人はより抽象的な並列様技術（TBBなど）を学習すると良いかと思います。
並列処理って改めて考えると、我々人間が普通にしている事であり、世界で普通に起きている現象なんですよね・・・それにも関わらず案外並列処理は難しいです。ちょっとした事でバグが発生しますし、デバッグもこれまた難しいし、オブジェクト指向設計するのが難しいし・・・色々な困難がそこに待ち受けています。
でも上手に並列処理を行えばパフォーマンスが大幅にUPします♪この快感が癖になりますので、面倒くさがらずに挑戦する事をお勧めします♪みんなでパラレルをエンジョイしよう♪

初めて投稿する。
並列処理を推奨していますが、危険度を考慮してますが、
パラレル処理(マルチスレッド)が持つ難しさをキチンと明記しないと、文意が通じない。
業務ロジックは、同期処理が多く、手続き型処理が適している場面が多々ある。
それに対して、パラレル処理を施そうとすると、混乱を招く。
場面に適した道具を提唱できるのが技術者だと考えるのだが。
パラレルを楽しんでいるのだから、苦労する点は熟知していると思う。
特に、変数等が広域化するので、排他処理による遅延をどう克服しているかが知りたい。

コメント有難う。

>特に、変数等が広域化するので、排他処理による遅延をどう克服しているかが知りたい。

質問の件ですが、並列化に於けるオーバーヘッドは確かに存在します。
それ故、マルチコアであっても性能は2倍にならず、良くて1.8ぐらいの性能となり、最悪の場合は悪化します。
その件についてですが、それについてはどこを並列化するのかを見極める事が肝要です。
大量のデータを処理する部分か機能を並列化するのが大体のところです。
並列化プログラミングの記事を執筆する予定がありますので、詳しい情報は暫しお待ちください。
なにはともあれ、そういった設計部分を楽しむのも良いかと思います。
並列化を一緒に楽しもう♪

説明が足りないと思いましたので、先ほどのコメントを補足します。
先ほどのコメントは、並列化する事によるオーバーヘッドは絶対に生じますので、
パフォーマンスをUPさせる方法は、アルゴリズムを工夫しようという事です。
こういった問題は設計面からのアプローチが大事なのです。
あと、データの粒度の問題等のアルゴリズム以外（設計面以外）の問題もありますが、
こういった問題は今のところは実際に試すしかないと思います。
どれだけ技術が発達しても実践は大事だよね。

回答、ありがとう。
事務業務アプリ開発に、並列処理を持ち込む事に疑問を呈したのだが。

業務仕様上、並列処理が必要になる場面は殆どない。大量更新などはDB上の処理になるので尚更。
並列処理を駆使するには、スレッドに関する知識か必要になる。
事務業務アプリ開発者の多くは、テクニカルスキルは持ち合わせていないし、必要性がない。
事務業務アプリは新テクノロジーよりも確実テクノロジーで安定している方を望んでいる。
事務業務アプリ開発者にとっては不満があるかも知れないが、一時代遅れた技術で開発するのがビジネスでもある。
その事情を汲んで、Blogを書いて貰わないと、現状否定する開発者で出かねる。

AlphaBeta さん
現状まではそれも一理ありましたが、マルチコア時代にそういう発想は危険ですよ。
コメントを読むに他の方はマルチスレッドが苦手なようですが、
AlphaBeta さんは分かっておられるようなので、こっそり学習しちゃいましょう。
マルチコア時代にもう突入していますので、並列プログラミングは必須スキルになると思います。
その時、出来る人と出来ない人の差はかなり大きくなります。
その時に備えて一緒に学習しましょう♪

事務業務アプリで、マルチスレッドが有利になる局面が、想像できないのだが。
どの場面で有利なのか、教えて貰いたい。
但し、UI絡みのDataCheckは該当しない....これは、主処理ではないから。

> どの場面で有利なのか、教えて貰いたい。

うーん難しい質問ですね。
というのはOSもマルチスレッドで動いているぐらいですし、
逆に並列化しない局面の方を想像するのが難しいからです。
あらゆる物事は並列で動いています。
ですから積極的に並列処理できるものは何でもすればいいと思います。
それは業務アプリでも同様です。
並列的に動作できるタスクは沢山ありますし、データの並列処理化も普通に考えられます。
アムダールの法則で示されているように、全ての処理を並列化することは不可能ですが、
だからといって全てを直列処理するのはちょっと違うと思います。
我々開発者は、全てのリソースを有効活用せねばなりません。
CPUがマルチコア化するのですから、そのリソースを使う方向で物事を考えるのが自然ではないでしょうか？

そんな、OSのニュークリアスなCPUよりの処理分岐の話と違うでしょ。
今回のBlogのテーマは、「プログラムソースレベルで並列処理が重要になる」と解釈した。
つまり、普通の開発者が意識して「スレッド分けするプログラムを書くようにしましょう」だよね。
>並列的に動作できるタスクは沢山ありますし
そんな見えないことを言われると理解できない。
アプリコーディングのことを聞いているので、見える話をしてほしい。
File データ　A と入力データ Bをマッチングさせて　File Bを更新するような、普通の業務アプリのどこに、並行処理が有利かを知りたい。

言語で UI部分を書いて、処理はストアーﾄﾞに任せたら、並列云々は無意味になる。業務アプリはストアードで完結すべしとも言える。
そのあたりの、意見を聞きたい。

> そんな見えないことを言われると理解できない。
> アプリコーディングのことを聞いているので、見える話をしてほしい。
> File データ　A と入力データ Bをマッチングさせて　File Bを更新するような、普通の業務アプリのどこに、並行処理が有利かを知りたい。

業務アプリは現実世界で行っている業務をサポートするためのシステムですよね。
という事は、伝票を印刷しながら、営業先のデータをチェックして、関連する業務の処理を実行させるなんて事ありますよ。
その時直列処理プログラムならば、じっと待たねばならないわけです。
そういった事を考慮して並列的なシステムを設計するべきです。
また、エンドユーザーはユニプロセッサやマルチプロセッサなんてよくわかりません。
そんなお客様が最新のCPUを買えばスピードUPすると思ってCPUを交換する事を考慮すると、並列処理システムを作って期待にこたえなければならないわけです。
もし直接処理プログラムだとエンドユーザーから「何故最新のCPUに換えたのに処理スピードがUPしないのだ」とクレームが来るでしょう。
また例のようなシステムでもデータ量の増加が目に見えていますので、並列処理をすると効率がUPします。


> 言語で UI部分を書いて、処理はストアーﾄﾞに任せたら、並列云々は無意味になる。業務アプリはストアードで完結すべしとも言える。
> そのあたりの、意見を聞きたい。
エンドユーザーの業務が全てDBを使用したデータ操作だけで済む程単純だとは思えません。
これからどんどんビジネスは複雑化し、データ量も増大するでしょう。
それを考慮すると直列処理だけで対応できるとはとてもじゃないけど思えません。

・印刷しながら、テータチェックする
・データ更新しなが、他の作業をする
いずれも、マルチタスクの話だよね。
マルチスレッドにする必然性はない。
貴君の文からは、マルチスレッド == 並行処理と読み取ってしまった。
業務アプリては、マルチタスクは必要たが、マルチスレッドは必然性が見えないので、
マルチスレッﾄﾞの利用例を示して欲しい。

並列処理を少し誤解されている気がします。
並列化はそもそもタスクとデータを「並列的」に処理する概念です。
スレッドはあくまでもプログラミング上の一概念です。
スレッドに拘り過ぎるとTBBなどによる並列化を理解できませんよ。
もともとプログラミングは直列的にしか処理できなかったので、
現実を無理やり直列処理に変えて実装しておりました。
しかし、CPUのマルチコア化の加速によって並列的に起こる現実に対して、
並列的に対処する事が可能となってきました。
それが並列化の概念です。
すなわち並列化の要点は、本来並列的に起こっていた現実を歪めて、無理やり直列化することにより処理していた事を本来あるべき姿に戻すところにあります。
より自然に設計し、自然に処理されるのが並列化の利点です。
スレッドはあくまでも実装の一概念に過ぎません。
スレッドでどうするのかではなくて、どの様に並列指向的に設計し、それをどの様に実装するのかという事なのです。
業務システムに於いての利点は、ユーザーがシステムにあわして仕事をするのではなく、ユーザーの仕事にシステムがフィットする様になる事だと言えるでしょう。

なるほど。でも、マルチタスクはWindowsの初期から実装されている。
印刷中に他の処理が止まることもない。
貴君の言っている使用例では、すでに完成されている使用例だ。
　この記事の、並列プログラムを勉強しようという内容とずれている。
俺が知りたかったのは、業務アプリでのマルチスレッドが意味を持つか否かだった。質問の意味が理解して貰えないようだ。
回答文を読むと、貴君は、用語は知っているようだが、用語の意味と活用方法を知らないようだ、
受け売りで「これからは xxxの時代だ」と言っているように見える。
どうだろうか。

私の言っている事がよく理解されていないような気がします。
業務システムにユーザーがあわせるのがよいでしょうか？
それともユーザーに業務システムを合わせるのが良いでしょうか？
という問題です。
もし従来の様に、システムがユーザーに不便を押し付けるのを望むのであれば並列処理は何の意味もないでしょう。
しかし、ユーザーに合わせる業務システムを作ろうとすれば、当然並列的に設計して実装する必要がありますので自ずと答えが出ています。
貴方はどうも実装から物事を見ているような気がします。
本来それは逆で、設計理由があって実装法を選ぶものです。
並列的に起こる物事を実装しようとすれば、自ずと並列プログラミングになるという事です。
これは次の問いを考えると分かるかと思います。
「業務システムの直列部分はどこですか？」
並列的に稼動する部分があるのであれば、その部分を並列プログラミングで実装して、パフォーマンスを向上させるのは至極当然です。
強いてパフォーマンスを上げない理由はありますか？
ただそれだけの話しだと思います。

分かりやすいようにもっとざっくばらんに言います。
マルチコアCPUを有効利用せず、エンドユーザーからクレームが来るシステムが作りたいですか？
それとも、マルチコアCPUを有効利用し、少なくともエンドユーザーからクレームが来ないシステムを作りたいですか？
エンドユーザーからクレームが来るシステムを作りたいのであれば、今までどおり直列的に作ると良いでしょう。
マルチスレッドも何も要りません。
そうでないならば、自然と並列プログラミングする事になります。
それだけの話しです。

業務を行うのは人だ。
人は並列行動をする。
しかし、業務の流れは、手続き型で直列なんだ。
注文を受けて、印刷して、印刷物で次の処理を行う。
コンピュータの前に座りっぱなしの業務は少ない。
貴君は現場を知らないのでは?
教務行動で並列部分は、少ない。
れば、示して貰いたい。

従来の直列指向で設計しているからそうなるのだと思います。
エンドユーザーの業務が直列的なものかどうかよく観察して下さい。
直列的に業務をしているエンドユーザーなんて居ませんよ。
それと、これからは並列指向的にプログラミング言語は進化していきます。
並列指向で考えないとおいていかれますよ。

>直列的に業務をしているエンドユーザーなんて居ませんよ。

だから、どの作業とどの作業が並列なのかを示してくれ

> >直列的に業務をしているエンドユーザーなんて居ませんよ。
>
> だから、どの作業とどの作業が並列なのかを示してくれ

人間の行動は常に並列的ですし、物事は何時も並列的に起こります。
ですから全ての業務が並列的に行われていると私は考えております。
システム化するときにそれをどう表現するのかが私たちの腕の見せ所です。
エンドユーザーにあわせるのが我々開発者のお仕事なのです。
開発者の都合でエンドユーザーに迷惑をかけてはなりません。
直列的な業務の方が私は分かりませんので、そちらのほうを教えてください。

マルチコアCPUが一般化が着々と進んでいる現実をよく考えて下さい。
これはクロック数がもう殆ど向上せず、誤魔化しが効かない事を意味しております。
エンドユーザーは常に、より早く、より快適に、より高性能なシステムを求めています。
ですから我々開発者がするべきことは、如何にしてマルチコアCPUを有効活用して、
エンドユーザーの希望にこたえるのかという事なのです。
今まではクロック数が上がっていましたので、マルチスレッドにしなくてもあまり目立ちませんでした。
しかし今後はその様な事はありません。
マルチコアに対応しているか否かは如実に現れます。
ですから、「時代に合わせて並列的に設計して実装するしかない」のです。
その利点については何度も言っていますが、パフォーマンスUPと利便性です。
この2つを捨て去り、クレームを呼ぶような事をする意義があるのでしょうか？
エンドユーザーの要望に答えるのが我々のお仕事だという事を忘れてはなりません。

横レス失礼します。
すでにAlphaBetaさんが指摘されていますが、

> マルチコアCPUを有効利用
という説明と、

> 伝票を印刷しながら、営業先のデータをチェックして、関連する業務の処理を実行させるなんて事ありますよ。

の説明の繋がりがわかりません。
同時に業務をこなすだけあれば「マルチタスク」のことであり、これはマルチコアCPUであるかどうかはあまり関係ありませんよね。

例えば、
「今まで1時間かかったデータの確定処理をマルチスレッドにしたら5分でできるようになった！」
ならば話はわかります。
# どうやって実装するかっていう議論は別にありますが

概念（設計フェーズ）での並列処理と実装（開発フェーズ）での並列処理を一緒に説明されているようなので、別に説明していただけるとわかりやすいかなと思います。

sakuさんへ
一番大事な事は、直列的なプログラミングを前提としたシステムは効果が薄いという点です。
ですから私は設計を強調して言っております。
あと並列化する時の利点は既に述べていますが、パフォーマンスの向上です。
並列的にされている業務を並列化して実装するのですから、システム全体のパフォーマンスが向上することになります。
目でパフォーマンス向上を見たい場合はCodeZineで書いた私の記事を参考にして下さい。
なお、並列的に設計していない場合でも、大量のデータを計算する場合のループ処理などを並列化すればパフォーマンスがかなり向上します。
あと、並列化には利便性の向上という重要な側面があります。
並列的な業務を並列化するのですからより利便性が高くなるというわけです。

ちょっとイメージが違ったので訂正します。

訂正前：直列的なプログラミングを前提としたシステムは効果が薄いという点です。
訂正後：直列的なプログラミングを前提としたシステムは本来の効果を発揮しないという点です。

効果が薄いという事は無くて、ループを並列化すればかなりパフォーマンスがUPします。
ですから薄いというよりも設計を並列指向にしたらもっと凄いという事です。

すいません、自分のコメントを読み直してみて自分でも説明がまずかったなあと思いました。
ちょっと補足です。

並列化によってパフォーマンスが向上する、それによってエンドユーザが恩恵を受けるという意見は同意です。

気になったのは「並列化」とおっしゃっているところに

(1) 処理Aを処理A'と処理A''に分割して実行する並列化
(2) 処理Aと処理Bを同時に実行する並列化

の2種類が混ざっていてちょっとややこしいなと思っただけなのです。

(1)はループを並列化するなどの1つの処理を並列化して時間を短縮するという話です。「マルチスレッドプログラミング」と聞いて私はこちらだと思いました。

(2)は印刷処理とデータ入力を同時に実行するなどの複数の処理を並列化して時間を短縮するという話です。こちらは「マルチタスク」という表現が該当すると思います。

エントリでは「マルチスレッドプログラミング」とあったので(1)だけの話だと理解していたのですが、(2)の意味も含めた広い意味での並列化をインドリさんはおっしゃっているという認識でよろしいでしょうか。

> エントリでは「マルチスレッドプログラミング」とあったので(1)だけの話だと理解していたのですが、(2)の意味も含めた広い意味での並列化をインドリさんはおっしゃっているという認識でよろしいでしょうか。

そうです。
並列性（parallelism）とは、同時に進む平行なシーケンスを意味する言葉です。
今まではユニプロセッサだったので「並列性を模倣していただけ」でしたが、
今はマルチコアCPUにより「真の並列化」になっていますので幅広く考えなくてはなりません。
そうしないと、これから並列指向言語などの抽象化されたマルチコアプログラミングについていけません。
並列化＝マルチスレッドだけではありません。

AlphaBetaは並列処理云々より、人に教えてもらうときのものの聞き方を学んだ方がいい

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら