X

C#, C♯, C＃相談室 Part95

■ このスレッドは過去ログ倉庫に格納されています
2017/10/17(火) 00:41:22.60ID:JxIRdCj70
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
2020/01/02(木) 20:25:41.97ID:HeIctSc70
>>560
ありがとう。いま帰省してて手元にコード書ける環境がないので、戻ったら再度やってみるよ
流石にアイフォーンでxaml書くのはしんどいす
567デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 20:32:51.61ID:cbHiY2pH0
プログラミングしてないから、Taskが必要なケースも知らないんじゃない？
2020/01/02(木) 20:58:20.51ID:FzsUW8F+0
>>563
そりゃお前のスタンスがおかしい。敵視とかそういう問題ではない。
俺はゴミをゴミだと言ってるだけ。いい仕様を制定出来てれば褒めてるよ。

逆にお前らはポジショントークしかしてないだろ。
つまりC#を使ってるから（どんな糞仕様であっても）C#は素晴らしい、でしかない。それを信者だと言ってるんだよ。
比較的C#はマシなのは事実だが、全部素晴らしいわけもない。



>>565
それもPromise擁護のお約束だが、
asyncで済む場合にほぼ全員がasyncを選択する時点でPromiseはゴミでしかないよ。
だからPromiseにはそれ以外の機能もあるもん！というわけだが、
実際Promiseが無くても書けるし、難しくもないし、必要な時もそうないだろ。
○と○をくっつけたらチョー便利！なんてのはよく初心者がやってるが、それと同レベルだよ。
2020/01/02(木) 20:58:47.18ID:FzsUW8F+0
>>564
その通りだ。だから俺の方がヘルスバーグより賢いなんて言う気もないし、実際言ってもないだろ。
ただ、だからといって、古い技術の方がよかった、なんて事にもならないんだよ。
ゴミはゴミだと正しく認識するべき。

> 並列処理
元々の問題はC#が即時関数（ラムダ）を軽視してたことだろう。
とはいえC#は対応も他言語(C++/Java)と比べて早かったのも事実だが。
確かに並列に関しては今後とも残るかもしれん。

ただC#がTaskを用意したのは「UIコンポーネントはUIスレッドで」という.NETフレームワークの思想の為であり、
俺はこれがそもそも疑問なんだがな。GUIはタスクランチャーだと割り切り、
・GUIからの呼び出しは「新規スレッド」か「UIスレッド」か選べるようにする。
・UIコンポーネントはどのスレッドからでもいじれるようにする。
・そこで競合するなら自前で同期化機構を書け
でよかったと思うし、実際これで当初「Task素晴らしい！」みたいなことを言われていたのは大体解決出来るだろ。
要は「重いジョブ」「そのGUI出力」を同じ関数内に記述したいけど、それは「.NETフレームワーク的には出来ない」だけであって、
自分でおかしな縛りを導入して、それに対する解を用意してって、マッチポンプでしかないだろ。

ただまあ、馬鹿が多いようなので無駄に噛みつかれないようにもう一度言っておくと、
確かに並列用途にはTaskは残るかもしれんね。
だからといってPromiseがいいって事にもならんが。
570デフォルトの名無しさん (ﾜｯﾁｮｲ e12d-XiJJ)
垢版 |
2020/01/02(木) 21:08:54.36ID:+muZM7K/0
高卒の天才みたいな人はいらないよ
2020/01/02(木) 21:28:42.78ID:eV/mpEQr0
C＃ならではのアプリよろしく。
2020/01/02(木) 21:31:55.72ID:qr+4fHWP0
もしかして「シンタックスシュガー」が理解できてないとか。
573デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 21:36:12.24ID:cbHiY2pH0
> ・UIコンポーネントはどのスレッドからでもいじれるようにする。
この時点でマルチスレッドプログラミングまともにしたことない感が…
2020/01/02(木) 21:47:43.46ID:VmmTWzwp0
>>569
＞・UIコンポーネントはどのスレッドからでもいじれるようにする。
それは土台無理というものですよ…
2020/01/02(木) 21:59:18.76ID:PZFQVuh5M
別にUIコンポーネントのためにTaskを用意したわけではないが
2020/01/02(木) 22:26:33.22ID:qsQZs66Y0
Task登場前に比べれば段違いで楽になったわけやしな

その後直ぐにasync出たのも時代的に仕方なかったわけで
2020/01/02(木) 23:06:36.82ID:ZgXvL7GY0
俺がasync/awaitを使うとだいたいハングアップするんだけど
みんなどういう場面で使ってるの？
2020/01/02(木) 23:07:01.36ID:FzsUW8F+0
>>573,574
だからそれが俺には謎なんだよ。やれば出来る範囲としか思えない。
実際、お前らが今バインディングしている先も、一々排他チェックなんてしてないだろ。
そもそもGUIではレーシング時には「前の値」でも「後の値」でもどっちでもいいケースでほぼ全部で、
問題のあるところだけmutex等の遅い同期化機構でも全く問題ないんだよ。

MSはGUIがプチフリするのが許せなくて、30秒以上（だったかな？）のジョブをUIスレッドでやったら警告を出し、
他スレに強制移転させたわけだが、その時に仕様的にはそのままGUI出力出来なかったというのが元の問題だろ。
しかし button_onClickに最初から他スレで問題ないし、
そもそもお前らみたいに「DIコンテナが正義」ならどうせStringBuilder/TextBox等に直書きなんてあり得ないのだから、
必要ならDIコンテナ先で排他/同期で全く問題ないし、これの方が実際生産性も高いだろ。

ただこれは俺にとってはかねてからの疑問で、これを5chで言うのも初めてではない。
他言語、例えばJavaScriptも形式は違うが一応「UIはシングルスレッド」になっているので、何かあったのだとは思う。
色々聞いた限り、Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
それ以降はシングルスレッドなのだ、との説を聞いたのだけど、これについて知っている奴はいるか？
ただそれにしても、その時はマルチスレッドにみんな慣れていなかったからであって、今なら普通にこなせるとも思うが。

>>575
ではなんだよ？
並列処理、というのは後付だと思うが。
2020/01/02(木) 23:48:39.72ID:PZFQVuh5M
>>578
マルチスレッドとマルチスレッド以外のあらゆる非同期、並列処理を統一的に扱うための抽象化だよ
歴史的な経緯で非同期、並列処理のやり方がマチマチでわかりにくかったからTaskにまとめた
これにより雑魚プログラマでも簡単に安全にイイカンジに最適化された非同期、並列処理を実装できるようになった
さらに統一的な抽象を得たことによって言語レベルでasync awaitを導入する基礎ができた
UIスレッドなんてのはオマケもいいとこだ
580デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/02(木) 23:59:29.88ID:cbHiY2pH0
>>578
mutexを緻密にやればrace conditionが発生するし、
雑にやればパフォーマンスの低下を引き起こすと思うけど
UIの実装なんてあんまり真剣に考えたくないところなんだから、
別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
逆に、「やれば出来る範囲」と言うけど、実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
581デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/03(金) 00:04:21.64ID:jYqYJjY40
すまん、race conditionではなくデッドロックだ
2020/01/03(金) 00:13:26.64ID:hATKQL5q0
マルチスレッドに分散処理させてた結果を最終的に本体スレッドで受け取る時に、queueで待機させて結局同期的にDBに書き込んでるんだけど、意味あるのかな？
2020/01/03(金) 00:17:52.23ID:O846x913a
>>582
その分散処理とやらがボトルネックになっているなら意味があるかもしれない
多くの場合はDBの方がボトルネックになるから、DBへの書き込みをバッチ化するとかの方が遥かに効果がある
2020/01/03(金) 00:48:08.71ID:fU3ErGER0
>>579
俺はそうは思わんね。

> あらゆる非同期、並列処理を統一的に扱うための抽象化
これは単なる「関数」で超大昔に終わってる。
つまり、非同期でも、並列でも、エントリポイントは「関数」であり、つまり渡す物も「関数」であり、
その上の階層で非同期か並列かを選べるのだから、「関数」で抽象化は完成してる。
実際、ちゃんと組んであれば、内部の関数はマルチスレッド/シングルスレッド/同期/非同期のどれで用いるにしても、
一字も変更する必要がなく、変更されるのは最上位での呼び出し方だけだろ。
これが「抽象化」が「関数」で完全に済んでいる証拠。
（というよりは、こうなる為のお作法として「グローバル禁止」等があるわけだが）

async/Taskがいいのは「その場に書ける」「戻り値を取れる」からであり、
抽象化してるとするなら、「同期」と「非同期」を抽象化してる。
（ただしキーワードが必要なので厳密には抽象化出来ているわけではないが）
だから、簡単で直感的な「同期」記述とほぼ同じ記述で「非同期」が出来るから美味しいだけであって、
それ以上でもそれ以下でもない。
そしてC#に非同期が必須みたいになったのはフレームワークの仕様の問題であり、これは回避出来たと思ってる。
585デフォルトの名無しさん (ﾜｯﾁｮｲ 06ad-IH4P)
垢版 |
2020/01/03(金) 00:57:27.50ID:jYqYJjY40
>>584
GUIなんて「グローバル変数」の典型例だと思うけど、
設計モチベーションの一つとして、GUIを便利に書く言語となってほしいってのがおそらく合ったと思うけおd、
それでも「回避できた」可能性はあるの？
2020/01/03(金) 01:06:44.31ID:fU3ErGER0
>>580
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。

> 別スレッドからUIスレッドへ実行すべきブロックをキューに追加するぐらいが丁度いいと思うが。
そしてこれがInvokeというわけか？
まあ.NET的にはそうなのかもしれん。

> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)
2020/01/03(金) 01:12:48.79ID:T8mFSGHc0
JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容（型）のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。
2020/01/03(金) 01:16:10.63ID:T8mFSGHc0
>>587
みなさん、これをすらすらと理解できますでしょうか？
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects
2020/01/03(金) 01:34:14.56ID:fU3ErGER0
>>585
回避出来たも何も、それ以前にする必要がないんだよ、割と。

例えば>>253,259、画面のGUIコンポーネントを直接参照して動作時は画面ロックの方がよかった、というわけだが、
実際これでも「自家用アプリに簡単にGUIを付けたいだけ」なら全く問題ない。
そして、演算実行中は放置だから、他スレッドとも競合なんてしないんだよ。

格好良くいえば、「運用で回避する」ということになる。
勿論プログラムとしては色々ヤバイが、必要なら真面目に同期取ればいいだけ。
手抜きなら「動作中は触るな」で十分、というわけだ。
クラッシュするのは例えばログ出力用TextBoxに複数から同時に書き込まれた時だが、
そもそもそれは複数出力元がある=複数の計算ルーチンが同時に起動する事が必要で、
全くのGUI初心者が最初に組むアプリではないんだよ。

それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
（もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが）
2020/01/03(金) 01:47:00.56ID:VBfxgT36M
>>584
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった
2020/01/03(金) 01:53:44.42ID:T8mFSGHc0
>>588
追記：
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。
2020/01/03(金) 02:26:10.78ID:cSDCrnP10
>>588
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Return_value
↑fetchの仕様を見れば戻り値は
「A Promise that resolves to a Response object」と明記されてるよ
MDNも日本語訳は内容が古いからまずは英語で見たほうがいい

const response = await fetch(…);
2020/01/03(金) 02:31:11.54ID:cSDCrnP10
>>591
>直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで
んんん？？

thenは2つコールバック関数を引数にとって
一つはresolveした場合、もう一つはrejectされた場合。
fetchが返すpromiseがresolveした場合は必ずResponseオブジェクトじゃないの？

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
2020/01/03(金) 03:19:39.56ID:RUwUdhzc0
>>578
＞Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI（基本は awt） ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます
2020/01/03(金) 10:59:52.40ID:3J/SmROP0
javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか？
2020/01/03(金) 11:03:04.63ID:VBfxgT36M
好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能
2020/01/03(金) 12:23:01.84ID:RUwUdhzc0
>>595
それはハンガリアン（の一種）といって悪い作法だと思います
2020/01/03(金) 14:09:52.04ID:T8mFSGHc0
>>592
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。
2020/01/03(金) 14:15:20.54ID:T8mFSGHc0
>>598
リンク先にあった、以下のコードを見ればどういうことなのかは大体理解はできそうですが。
「Xを解決するところの1つのPromise」
というものの正確な定義はどこにあるのでしょうか。

let myRequest = new Request('flowers.jpg');
fetch(myRequest)
.then(function(response) {
if (!response.ok) {
throw new Error('HTTP error, status = ' + response.status);
}
return response.blob();
})
2020/01/03(金) 15:32:49.36ID:fU3ErGER0
>>590
FrameworkOnFrameworkが日常的になっている時点で、
機能的に足りない＝そのFrameworkが糞、なのは明らかだろ。


>>594
AWS等について確認したが、どうやら
> スレッドとAWT/Swing
> https://www.ibm.com/developerworks/jp/java/library/j-thread/index.html
> https://www.ibm.com/developerworks/jp/java/library/j-king/
・AWSは多分何のプロテクションもない
・SwingはinvokeLater()とinvokeAndWait()(多分BeginInvokeとInvoke相当）が用意されている
・これらで手こずったので、.NETは最初から「UIスレッド縛り」を付けた
ように見える。結果的には妥当な判断なのかもしれん。
(AWSやSwingは俺が569で言った構成に《.NETよりは》近い）
2020/01/03(金) 15:33:08.37ID:fU3ErGER0
これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。

ただ、デッドロックは多分今の若者が教育されているほどには驚異にはならない。
あれはアホみたいに「一つ確保して、その場ですぐ返す」構造にすればそもそも回避出来る。
つまりロック周り自体ではなくて、その上位構造から単純化してしまって解決する方がいいのだけど、
それをしようとはしていない。
逆にそれをしたのが.NETで、言うなれば全部のUIコンポーネントで一つのmutex、
それをUIスレッドが握りつぶす（他に渡さない）から他が触れず、Invokeするしかなくなる。
OOP初心者が訳の分からないクラス構成にすることはよくあるが、同様に、
Javaでマルチスレッド初心者が訳の分からないロック機構（しかもバグってる）を作りまくったのかもしれん。
.NETはそれよりは、仕様的に回りくどい構造になるがアホでも組める方を選んだのだろう。
とはいえそれもFrameworkOnFrameworkしたくなってしまうほど糞で、実際それをやらかし、
Task/asyncで収まった、というのが現在か。(話を総合すると）

歴史の流れとしては極めて妥当なのかもしれん。
2020/01/03(金) 15:58:36.89ID:NacIP61HM
>>600
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ
2020/01/03(金) 17:14:48.26ID:fU3ErGER0
>>602
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては（非同期には）要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。

簡単に記述出来る「記法」が足りなかったのに、非同期強制部分が.NETにあった為に多くの糞を生んだ。
元々はラムダや匿名関数周りが弱かったからであり、これらが最初からあればもうだいぶましだった。
実際、JavaScriptのイベントモデルだと、Taskなんて無くてもC#程酷いことにはならない。
そう出来なかったのはC#の問題であり、（といっても既に解決済みだが）
逆にWeb系は馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。（簡単なこと自体は素晴らしいことだが）

君がこれらを認めないのは君の自由。
2020/01/03(金) 17:23:20.75ID:RiNqytdzM
多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった
2020/01/03(金) 17:35:57.54ID:VSKvK8ih0
並列処理はうまく書けないからasync/awaitは中途半端な糞！にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞！おまえらは信者！」から入るのに
ひたすら教えられてるだけなのが面白いね
2020/01/03(金) 17:56:04.43ID:cSDCrnP10
>>598
スレチな気もするが一応回答しとく

Promiseってのは処理が終わってるかもしれないし
まだ終わってないかもしれないという文脈付きで値を運ぶ入れ物
処理が終わってる場合は、成功してるケースもあれば失敗してるケースもある

つまり下記3つのうちいずれか1つの状態にある
1. Pending:まだ終わってない/結果待ち
2. Fulfilled: 成功で処理完了済み(=Resolved)
3. Rejected: 失敗で処理完了済み

「戻り値が A Promise that resolves to a Response object」というのは
戻り値はPromise(=文脈付きで値を運ぶ入れ物)で
成功で処理が完了済みの状態になった場合
入れ物の中身は「a Response object」になるPromiseですよって意味
2020/01/03(金) 18:03:40.42ID:cSDCrnP10
>>599
>.then(function(response) {

.thenの第一引数はresolveした場合のコールバック関数で
そのコールバック関数に渡される引数が
Promiseが成功で処理完了済み状態になった場合に入れ物の中に格納してる値

fetchの場合はそれが「a Response object」
function(response){…}というコールバック関数の引数(response)に
Promiseという入れ物に格納されたa Response objectが入る

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise/then
2020/01/03(金) 19:11:10.09ID:fU3ErGER0
>>605
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。

> 並列処理
そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
スパコンのこと何にも知らないようだし。（これ自体はC#的には問題ないが）
C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。
対して非同期は.NET的には日常的に必要な物になってしまってるだろ。

ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。（やったら別の意味で殺されるはずだが）
俺には第一級関数の有り難み自体はよく分からないのだけど。
2020/01/03(金) 19:31:35.35ID:rBRy8LznM
> C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。

やっぱり使ったことない人だったか
2020/01/03(金) 19:35:32.04ID:FQOC+LzKd
通信やファイル等々は並列化前提くらい当たり前に使う部分
そもそもまともに開発したことないんでしょ、彼は
2020/01/03(金) 19:40:22.89ID:VSKvK8ih0
>>608
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ？

> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」
2020/01/03(金) 20:21:02.89ID:jYqYJjY40
並列実行をHPC系の計算でしか使わないと思ってるのかなあ
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど
2020/01/03(金) 23:02:49.12ID:O+Z2CAJQ0
c#の並列処理ってコントロールが糞だから仕方なくって場面ばっかりだけどね

そもそも並列処理って実現方法に2つあって
並列で動く2つの処理を
処理Aと処理Bとしたときに

[方法1]
言語の並列機構に任せて
処理Aと処理Bをそれぞれ独立で実行する
もちろん処理過程や処理結果も表示通知する機能が存在する

[方法2]
処理Aと処理Bをブツ切りにした
処理A1~N、処理B1~Nをループで

処理A1
処理B1
表示
処理A2
処理B2
表示
・
・
・

という具合で実行

色々触ってきたけど[方法1]で
実行できた言語って一度もネーな（笑）
614デフォルトの名無しさん (ﾜｯﾁｮｲ e12d-XiJJ)
垢版 |
2020/01/03(金) 23:20:55.60ID:mMttcVtS0
そうだね、パソコンがなんでもやってくれると君みたいな頭でもプログラムが書けるね
2020/01/03(金) 23:21:49.89ID:cSDCrnP10
とりあえず並列処理と並行処理は区別しよう
2020/01/03(金) 23:46:23.43ID:fU3ErGER0
>>610
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を　async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ！簡単！楽チン！な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。

ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。
2020/01/03(金) 23:48:32.86ID:fU3ErGER0
×　平行
○　並行
2020/01/04(土) 00:04:34.11ID:kFIotbKU0
>>610
>>616
と思ったんだが訂正。
確かに今の仕様のasyncだとまだTaskは廃棄出来ないかも。
現在は明示的に発行と結果回収を別の行に書いてるんだな。それでawaitで引っかけてると。
俺はこれ、遅延評価で勝手に引っかかってるだけだと勘違いしてたわ。
すまんね。
2020/01/04(土) 00:09:37.91ID:OgXWl81Pa
やっぱり使ったことない人だったか
2020/01/04(土) 00:48:40.79ID:4F9nlIzrM
通信やファイル処理はCPUとは別のデバイスが同時に処理するから並列処理
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん
621デフォルトの名無しさん (ﾜｯﾁｮｲ e12d-XiJJ)
垢版 |
2020/01/04(土) 01:17:00.82ID:ebUznjxj0
誤った指摘をしている人がいますが、>>610は、相当ミスらない限り並列処理かつ非同期処理です
並行処理である保証は全くありません
2020/01/04(土) 02:02:38.56ID:X7t3Qsuc0
並列は、CPU に使う用語

並行は、処理に使う用語
623デフォルトの名無しさん (ﾜｯﾁｮｲ 426a-UAPS)
垢版 |
2020/01/04(土) 02:34:27.40ID:WRfbnwnP0
こんだけ暴れておいてこの結末ｗ
2020/01/04(土) 02:47:20.03ID:oEJCGEWJ0
>>620,621
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ

ファイルがパーティション分割されてて
100パーティション同時に書き込みを行うような処理なら並列処理

基礎的なことなのでもうちょい勉強してくれ
625デフォルトの名無しさん (ﾜｯﾁｮｲ e12d-XiJJ)
垢版 |
2020/01/04(土) 03:01:30.66ID:ebUznjxj0
>>624
>>621は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです
2020/01/04(土) 07:26:04.88ID:SQI5AQb9M
>>624
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な

例えばこうだ
var t1 = CalcSomething();
var t2 = DownloadFile();
var t3 = ReadFile();

1つの物理装置が、少しCPU処理→少しファイル処理→少しネットワーク処理、と繰り返して3つの処理を同時に処理してるように見せてるなら並行処理だ

でも実際には、別々の物理装置によって計算、ネットワークアクセス、ファイルアクセスを同時に処理するので、これは並行処理ではなく並列処理だ

基本的なことなので、勉強してくれまじで
2020/01/04(土) 07:33:09.39ID:wUfYsbyMd
C#で並列処理を勉強しようとしたら大抵初めに出てくるParallel.Forすら知らないんでしょ
だから英単語出してきてまでそれは平行だ！とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにｗ

もう以前からびっくりするくらい知識が浅い
2020/01/04(土) 07:49:31.73ID:wUfYsbyMd
あとマルチproccessとマルチthreadも同じやね
using System.Threadingも書いたことなんだろう

C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う
2020/01/04(土) 08:29:25.67ID:zoxkJgWd0
プログラム内の厳密な並列ってなくね？
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね？
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどｗ
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの？

ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな？
その切替タイミングはプログラム内のsleepやDoEventsだよね？
2020/01/04(土) 08:50:02.37ID:oslWCP6e0
変なの増えた
2020/01/04(土) 09:09:30.45ID:H9Ya7buR0
>>629
> その切替タイミングはプログラム内のsleepやDoEventsだよね？
いつの時代の老害だよ…
2020/01/04(土) 09:10:51.45ID:SF9EFyjm0
>>629
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい
2020/01/04(土) 09:16:33.71ID:zoxkJgWd0
>>631
え？じゃあどこ？
2020/01/04(土) 09:23:34.37ID:zoxkJgWd0
>>632
それを実際に言語の機能に適用してるかどうかは別だよね？

なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね？
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか？
こんなもん役に立たないのか？
該当する処理が本当に適用できるのかはチェックが必要だと思うな
2020/01/04(土) 09:34:32.95ID:ljwPgx+b0
スレッド切り替えと言うが、今日日マルチコアだぞ。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。
2020/01/04(土) 09:44:36.22ID:wUfYsbyMd
parallelにしてもちゃんと理解してないと遅くなることだってありうるよ
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある

コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない？
2020/01/04(土) 09:49:49.34ID:zoxkJgWd0
>>636
コードを見ないとわからない？
IDEが教えてくれる？
なんにせよ使えないよそんなの
2020/01/04(土) 09:54:48.34ID:zoxkJgWd0
>>635
それ並列でやった処理結果まとめられないじゃん
やりにくいし

結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね？
2020/01/04(土) 09:57:09.90ID:H9Ya7buR0
>>633
プリエンプティブ でググってこい
2020/01/04(土) 09:59:40.19ID:wUfYsbyMd
>>637
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのｗ
詳細な実装は開示しないけど俺が試したら遅くなった！parallelなんかまともに使えない！って主張なの？
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし
2020/01/04(土) 10:01:55.73ID:wUfYsbyMd
3分割したら3倍異常遅くなるって例えば各スレッドでファイルを読み込んでるだけじゃねーの？
そんなやり方したらそりゃ遅くなるよね
2020/01/04(土) 10:02:04.61ID:zoxkJgWd0
>>640
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ
2020/01/04(土) 10:14:00.73ID:WRfbnwnP0
GAIJI vs GAIJI
2020/01/04(土) 10:18:25.47ID:dtJSIh3jp
ヤベエ逸材多過ぎだろこのスレｗ
今までどこに潜んでたんだコイツら
2020/01/04(土) 10:31:54.67ID:ljwPgx+b0
>>638
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。
2020/01/04(土) 10:57:29.93ID:kFIotbKU0
まあとりあえず、「並列」「並行」については最近は混同されてるし、実際混同しても問題ない領域が多いし、
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。

> Parallel.For
これはちょっと筋が悪い。現在の主流はMap/Reduceなんだから、そっちに合わせた方がよかった。
お前らが速くなるならないでグダグダ言っているのも、結局はこれで、Map/Reduceが効く場合は速くなり、
そうでない場合は速くならず、場合によっては遅くなる、というだけ。別に不思議なことではない。

ただまあ、君らも分かっているとおり、レンダリングの場合は分割は効果があるから、
・書き方が悪い
・今はそこまでParallel.Forの出来がよくない
のどちらかで、まあそれを揉めているわけだが、今の状況はさておき、
最終的にはこのコードで簡単楽チンに数倍速を得よう、ってのは間違ってはいない。

問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。
2020/01/04(土) 11:03:02.06ID:DH3JGq6p0
とりまコード見ないとなんとも
なんかで排他制御でも効いてるんだろうけど
2020/01/04(土) 11:03:38.49ID:oEJCGEWJ0
>>625
そのリンク先に並行処理についての記述は一切無いぞ

>>626
並行処理をせまく理解しすぎ
並行処理と並列処理は観点の違う概念であって相互排他的なわけではない

並行処理はある瞬間を切り取ると”必ずしも”同時に複数の処理が実行されているわけではないだけで同時に実行されてる場合もある

君の例は1つの物理装置で処理されてようが別々の物理装置によって同時に処理されてようが関係なく並行処理(Concurrent Processing)の例
それを並列処理とは呼ばない
2020/01/04(土) 11:11:54.60ID:8gIJKMuI0
そもそもawait/asyncは、非同期処理を同期処理のようにかける仕組みであって
マルチタスクそのものじゃなくて周辺技術だよな
2020/01/04(土) 11:53:37.81ID:SQI5AQb9M
>>648
いや、そっちが理解間違ってるよ

並列処理は複数の装置で複数の処理を同時に実行すること

並行処理は単一の装置に複数の処理をスケジューリングして、順番に実行することによって巨視的に並列処理のように見せかけること

複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな
2020/01/04(土) 12:07:21.44ID:hpecUN4N0
>>650
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの？
2020/01/04(土) 12:08:56.85ID:ljwPgx+b0
>>646
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。
2020/01/04(土) 12:27:07.45ID:LH34clIMM
>>651
放置しときなよ
用語知ってる俺スゲー君同士の戦いなんてどうでもいいし
2020/01/04(土) 13:10:03.26ID:9r4/dVyW0
この年末からのつまんねえ言葉遊びの流れほんとクソ
2020/01/04(土) 15:56:23.34ID:zGBEMeLs0
装置どうこうで並列や並行いってるやつらは
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ
2020/01/04(土) 19:35:04.89ID:kFIotbKU0
>>652
実際効果が出ているのならそれでいいと思うよ。
MapかForについては、どっちから攻めるかの違いだけではあるから。

ただ、分割をC#側が担うのは明らかに間違ってるでしょ。
DBならSQL投げてその先はDB側で動的に何とかしろ、が正しく、
当たり前だがDBの構成なんてC#コーディング時に関知しようもないし。

といってもMSがこの辺を知らなかったはずもない。
何か作戦があるんだとは思うよ。

PLINQについては確かに「並列」だが、なかなかな事を書いている。
> 既定では、PLINQ はホスト コンピューター上のすべてのプロセッサを使用します。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/introduction-to-plinq
> 結果の順序は毎回異なることがあります。
> この動作は、オペレーティング システムによるスレッドのスケジュール方法に依存するため、アプリケーションでは制御できません。
> https://docs.microsoft.com/ja-jp/dotnet/standard/parallel-programming/order-preservation-in-plinq
これはMSが悪いわけではなくて、当然そうにしかならないのだけど、
当たり前だがPLINQに丸投げすれば全てよし、みたいなものではない。（ただ、そこを目指してはいるのは正しい）
まずは書けないと話にならないので、MSとしてはプログラミングモデルを提供してきた、というところか。
2020/01/04(土) 19:37:21.95ID:kFIotbKU0
asyncも、ググれば分かると思うが、実はasync/awaitの片方はキーワードとしては要らない。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。（つまり今ならawaitが要らない）
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化＋パイプライン(可変長レイテンシ）」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。

ただし、今の仕様が悪いか、と言われれば、必ずしもそうでもない。
俺がさんざん言っているとおり、MSは若干エレガントなところを狙いすぎていて、
ライト層がちょっと置いてきぼりになってる感がある。（Web系に比べて）
そしてさんざん君らがTaskマンセーしているとおり、ベタな仕様には分かりやすいという大きな利点がある。

ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。
2020/01/04(土) 19:51:30.64ID:dJY1KQxf0
別スレ立てたら?
2020/01/04(土) 19:54:05.88ID:kFIotbKU0
もしかしたら伝わらないか？とも思うので一応。
俺はawaitを廃止して、以下の
> 次に、ベーコンと卵の await ステートメントを、メソッドの最後の朝食提供前に移動します。
> https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/index
の下のコードを以下に出来る、といっている。

Coffee cup = PourCoffee();
Console.WriteLine("coffee is ready");
Egg eggs = FryEggs(2);
Bacon bacon = FryBacon(3);
Toast toast = ToastBread(2);
ApplyButter(toast); // ここでtoastが完了してないときだけは結果待ちで止まる
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");

Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

まあみりゃ分かるとおり、await文部分を前に持っていっただけではあるが。
今の仕様だと、この書き方では肝心の非同期部分が1つずつステップ実行されてしまう、という事になっている。
2020/01/04(土) 20:06:59.76ID:tMXF89W90
>>659
そのコードじゃ非同期処理が完了してなくても"〜 are ready"って表示されるだろ。
2020/01/04(土) 20:09:00.48ID:DH3JGq6p0
c++スレにいた長文マンかなこいつ
2020/01/04(土) 20:44:38.22ID:kFIotbKU0
>>660
まあそこはツッコミ来るかとは思っていたが…。

ぶっちゃけ、その通りだ。そしてそれで問題ないんだよ。
結果を確認しに行けば確かに出来ている（ようにしか見えない）からね。
時間軸上で遅延が発生するだけで、論理的な動作としては全く問題ない。

これは例えばJavaScriptでは大昔から実装済みで、getElementsByClassNameがそうなってる。
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementsByClassName
これで問題が発生しているケースなんてない。
馬鹿が「getElementsByClassNameは圧倒的に速い」みたいなブログを書いている、というのは結構あったが。

ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね？毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。
663デフォルトの名無しさん (ﾜｯﾁｮｲ 7197-IH4P)
垢版 |
2020/01/04(土) 20:59:50.92ID:W0mLC2oD0
>>657 >>662
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの？
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。
2020/01/04(土) 21:49:39.49ID:kexvLmFr0
await不要って園児並みに相当バカ
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw
2020/01/04(土) 21:59:07.73ID:xLbjEwkrM
そろそろ冬休み終わるから謎の長文更新も途切れるかね？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況