東方算程譚

コメントを追加

# re: TBBで遊んでみたよ(10) 2010/06/09 23:07 Ｓｏｄａ

記事に対してどうこうではないので、こちらでー
CodeZineの記事みて、概要は理解できたんだけど、利点というか使い道が思い浮かばなかった。

最初のページに「皿に盛る」ってのも同時複数実行不可になっていたけど・・・
「刺身を切る」部分は実験して、１つづつ実行しているのを確認した。
サンプルでは、「皿に盛る」は複数実行されるんじゃないかと疑っているｗ
実際の動作は、なんでもできるオバちゃん何人かいて、仕事が発生した順にその仕事に就くだけですよね？
最初だけが例外で、同時発生しない・・・のかな？

最初が同時複数実行不可ってことは、I/Oがらみで順番に取り出すものが想像できたけど・・・
そこから先を流れ作業にするメリットがピンと来なかった。
一連の動作を１つのスレッドで処理してしまったとしても、あまり変わらないような気がして・・・
いや、変わらないならこんなもの用意する必要がないのだから、なにかメリットがあると思うんだけど、それがなにか頭が固くてでてこないｗ
あっ、全ての工程が同時複数実行不可ならこのほうが早いのかな？
・・・って、もしかしてそういう動きだったのか？ｗ
そこまで調べなかったーｗ

# re: TBBで遊んでみたよ(10) 2010/06/10 5:55 επιστημη

パイプラインは厳密には「流れ作業」とはちょと違うですね。
途中にモタつくオバちゃんがいると後段のオバちゃん連中が遊んでしまう。
パイプラインでは「手すきのスレッドが処理待ち仕事を片っ端から片づける」はず。
なので各工程の所要時間にバラつきがあるとき、遊んだコアが少なくなるはずっす。
んでもって同時複数動作不可な処理が混じっていても同期云々を意識せずに済むってメリットもありそ。

# re: TBBで遊んでみたよ(10) 2010/06/10 8:47 Chiharu

記事の中のパイプライン的な動作をイメージのデコード処理で自作したことがありますが、その際、同時実行不可能なディスク I/O がボトルネックになって、全体の処理速度はあまり向上しませんでした。

しかし、I/O とデコード処理が並列で動作することから、その後、I/O を減らすために圧縮効率の高い (デコード負荷の高い) アルゴリズムを採用して、I/O を削る方向で調整すると、全体の処理速度はかなり向上しました。
シーケンシャルに処理すると、I/O 負荷とデコード負荷は 1:1 の比重で検討する必要がありますが、デコード工程が並列化されていたので、1:n (n はコア数、I/O に対して n 倍の負荷をかけられるの意) の比率で検討&対応できたという例です。

パイプラインも多分、「同時複数動作不可な処理が工程全体の所要時間のほとんどを占める」状態だと、速度向上があまり期待できない、ということになりますね。多分。
パイプライン自体は高速化のための枠組みだと思いますが、さらに推し進めて、上記状態の解消がパイプラインの高速化、という話になるような気がします。

何事もバランスですね。

# re: TBBで遊んでみたよ(10) 2010/06/10 11:30 とっちゃん

並列処理におけるパイプラインは、ボトルネックがどのパイプにあるのか？をあらかじめ考慮して作っておく必要がありますよ。＞ちゅきさん

「ディスクアクセス(直列処理)が改善されなければ、他を並列化して改善する労力は無駄になる。。。」
おいらが生まれる前から言われてることです。＜アムダールの法則

パイプライン処理は、並列処理じゃなきゃできないものじゃありませんよ。
複数のそれぞれ独立した処理をつなげて一連の流れにすることをパイプライン処理と呼びます。

画像のエフェクト、圧縮・展開などでよく使われる技法のひとつです。当然ですが大半がシーケンシャルな直列実装です。
今でこそ、GPGPUとかも使ってがつがつ処理できるようになったので、並列化も少しずつ進んでますが、ZIPやLZHの実装、PNG,JPEG,JPEG2000,GIFのエンコード・デコード、これらすべてパイプライン処理を内部実装に持っていますががいずれもシーケンシャルに処理されていて、並列化されてません。
画像のデコードもまだまだ並列化されていないライブラリのほうが圧倒的多数です(安価に並列処理を行えるランタイムサポートがないので)。

# re: TBBで遊んでみたよ(10) 2010/06/10 11:31 とっちゃん

あ、名前間違った。。。Chiharu さんじゃないか！
ごめんなさい。

# re: TBBで遊んでみたよ(10) 2010/06/10 15:16 Chiharu

はい。Chiharu さんです。そして、パイプライン関連のご指摘の事項はおおむね存じていますよ。＞とっちゃんさん

I/O のボトルネックの話は極端でした。あと、話を I/O とデコードの 2 段に限定するなら、parallel_while で十分という話も。んー。デコーダの開発当時は I/O を過ぎてデコード処理から先の並列化こそが複雑で、最終形がパイプラインぽくなっていたなとか思ってたので提示したんですが。

何だか、かえって分かりづらい話をふくらませてしまって、申し訳ないです。

あとアムダールの法則の方も存じてますよ。（知ったのはここ 1-2 年のことですが）アムダールの法則で言われる直列処理のボトルネックを少しでも改善するための TBB であると感じています。単純に機能並列やデータ並列にできないものについて、特に処理フローの中に 1 カ所でも直列必須の処理があると、（私だけかな？）処理フロー全体を直列処理しないといけないと錯覚しがちだと思うのですが、その誤解をフレームワークの提示という形で解いてしまったのが、TBB の凄さと感じています。
（手軽にデータ並列できることも売りだと思っています

# re: TBBで遊んでみたよ(10) 2010/06/10 21:25 とっちゃん

いえいえ。こちらも勘違いしていたとはいえ、話題が拡散してるわけじゃないので、気にしないでください。＜コメントが大変ならトラックバックでｗ

パイプライン処理も単純に２つ程度なら、parallel_invoke(ioFunc,decodeFunc); とかでもいいんじゃないかな？と思います。
プロデューサー・コンシューマーパターンも作りやすいし。

＞直列処理のボトルネック
単純な直列処理の並列化(for -> parallel_forなど)は、OpenMP のころからいろいろありますよ。
とはいえ、TBB がそれまでと違ってすごいのは template 使いまくりとはいえ言語拡張を行うことなく、ライブラリレベルで実現したところでしょうね。

OpenMP は、コンパイラの拡張なので、どうしても尻込みしてしまうのと...
#pragrma がいっぱいありすぎて読みにくいｗ

# re: TBBで遊んでみたよ(10) 2010/06/10 22:31 Ｓｏｄａ

えぇっと、イロイロ実験してみた結果、同じ工程は同時実行されないということがわかりました。

作業場と、そこでできる作業の内容が決められていて、同じ作業ができるのは一人だけ。
スレッド数は、作業者の数ですね。
オバちゃんは仕事ができた作業場に走っていって仕事をし、仕事が終わったら待機場所に戻って、仕事ができるのを待つようなイメージかな？
個々の作業場には一人のオバちゃんしか入れないので、そのオバちゃんは、そこにある作業道具を自由に使えると。
作業場の数と同じ数のオバちゃんを用意したときがフル稼働状態であり、それ以上オバちゃんを用意しても、待機場所でだべってるだけになるわけですな。

スレッド数を工程数の倍指定すれば、２ライン同時実行されると思っていたら、違った(^^;

各工程でバラバラなI/Oを制御するときには使えるかなぁ。
各工程にスレッドを割りふって、ポーリングして仕事を待つような場合は、検討できる・・・かな？

同じ工程が同時実行されない、工程ごとの順番が保障されているってのが、特徴ですね。
ファイルからデータを読み込んで、画面に表示みたいな場合に、I/Oの排他処理を考えなくてもよくなると。

# re: TBBで遊んでみたよ(10) 2010/06/11 4:32 επιστημη

作業場が複数あったときに同じ工程を同時にやっていいか否かを指定するmake_filterの第一引数:
tbb::filter::serial_in_order/serial_out_of_order/parallel
をとっかえるとおもろい結果が得られそうです。

僕のマシン、ショボいdual-core(Athlon 64 X2)では目立った効果が観察できずにｼｮﾎﾞｰﾝですけど orz

# re: TBBで遊んでみたよ(10) 2010/06/11 20:21 Ｓｏｄａ

>επιστημηさん
さっそく、試してみましたー。
serial_in_orderってお決まりの書式ぐらいな認識しかしてませんでしたｗ
試した結果、parallelで並列動作することを確認しました。
あまり考えずに、firstにparallel指定したもんだからー排他処理しないと駄目ってわかりましたが(^^;

ただ、serial_out_of_orderで動作がどうかわるのか、いくらやってもわからなかった。
serial_in_orderとの違いがわからない(^^;
説明みたけど、serial_in_orderと同じで、作業場に一人しか入れないんだけど、parallelのように処理順番が不定？
parallel_pipelineならかわるんかな？

>僕のマシン、ショボいdual-core(Athlon 64 X2)では目立った効果が観察できずにｼｮﾎﾞｰﾝですけど orz

あっ、私が試してるのはSleep使って並列に動作できるゆとりを作っただけです。
task_scheduler_init init(試したいスレッド数)を先頭に付け足して、イロイロと試してました。
run()の値は、動作させたいスレッド数だと思っていたんだけど、違うのね(^^;
動作するスレッドの最大数を制限するためにあったようですねぇ、凄い勘違いしてた。
task_scheduler_initを使わない場合、コア数が最大スレッド数みたいで、それよりも大きな値をrun()に入れても意味がなかった(^^;

Sleepの時間を変化させることで、工程が詰まっているときにどんな流れになるかみてたんです。
parallel指定で、スレッド数が多いと、後から入ったものが先のものを追い抜きますねぇ。

ＰＳ．
なんだろう、Sleep使うって書いてると、なんだか笑えるのはｗ
決して負荷をかけているわけではないと、説明したくなるのも謎だｗ

# あー、やっと眠れるｗ　TBBでx64で動いたよ 2010/06/12 20:59 すいません、VB４しかやってないんです、VBAはやったけど（ぼそ）

あー、やっと眠れるｗ　TBBでx64で動いたよ

タイトル		タイトルを入力してください
名前		名前を入力してください
URL
コメント   コメントを入力してください
名前をブラウザに記憶する