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

2017/10/17(火) 00:41:22.60

■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/03(金) 01:06:44.31

>>580
> UIの実装なんてあんまり真剣に考えたくないところなんだから、
これはその通りだ。

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

> 実際にUIスレッドをスレッドセーフにしてまともなGUIフレームワークになっているものってあるの？
知らん。だから聞いている。
無いのは、無い理由があるとは思うのだけど。(そしてそれが、昔Javaで…だと聞いているだけ)

2020/01/03(金) 01:12:48.79

JavaScriptのPromiseが難しいのは、then のブロック内の最後の行で実行した関数の戻り値が勝手に次のプロミスにチェーンしていくみたいなところ。
ここが難しいのは、JavaScriptには明確な型が無いので公式サイトのサンプルを見ても、関数の戻り値がどんな内容（型）のデータを返しているのか分かりにくいところ。
それぞれの関数のドキュメントを調べてもそれが結局分からない。
同じ関数でも時と場合によって返すデータの型(?)が変わってしまうようなケースすらあるかも知れないし。
いまのところまだ理解できないのは、fetch でResponseオブジェクトを返すような処理。
ドキュメントの説明で、関数のプロトタイプ宣言の様な部分でも型がちゃんと書いてないので理解が難しい。

2020/01/03(金) 01:16:10.63

>>587
みなさん、これをすらすらと理解できますでしょうか？
自分はなかなか理解できません。
https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#Response_objects

2020/01/03(金) 01:34:14.56

>>585
回避出来たも何も、それ以前にする必要がないんだよ、割と。

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

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

それを非同期で別スレ起動してInvokeしろとか、かなり敷居を上げてしまってるだろ。
（もっとも、警告を無視してUIスレッドで計算して、当然GUIはフリーズ、みたいなことも出来たが）

2020/01/03(金) 01:47:00.56

>>584
超大昔に終わってないから出来損ないのインターフェイスや実装がポンポン出てきて混乱したんだよ
でマイクロソフトが主導してC#における標準的な抽象としてTaskを導入した
プログラマはみんなそれを受け入れてTaskを使うようになった

2020/01/03(金) 01:53:44.42

>>588
追記：
thenブロック内部の関数の戻り値が Response「型」の場合でも、
直後のthenブロック内部の関数の引数が必ずしもResponse「型」ではないこともあるようで、その場合は、型の「自動変換」が行われているのではないかと思えるんです。
C++の場合だとプロトタイプ宣言などの関数宣言があるのでそれが分かり易いのですが、JavaScriptだと本当に型変換が行われているかどうかも不明確で理解が難しくなっています。
仮引数の型に可能性の幅が出てくる可能性があり、結局どのような「型」になっているか分からないので、どのクラス(?)のドキュメントを読んでいいのかも分からないので理解に時間が掛かります。
候補となりそうなクラスや関数の解説文を手当たり次第に読んでみて辻褄の合うようなものを自分なりに見つけてこないといけないようです。
C/C++ではなかった苦労がそこにあります。

2020/01/03(金) 02:26:10.78

>>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.54

>>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

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/03(金) 03:19:39.56

>>578
＞Javaで昔マルチスレッドなGUIがあって、盛大にそこでやらかしたから、
Java ライブラリの GUI（基本は awt）ってそんなんだったかな…近々 awt を頭から見直そうと思っていますのでそのときに考えて見ます

2020/01/03(金) 10:59:52.40

javaのフィールドに倣ってプロパティの接頭語にアンダースコアを付けるべきか悩んでいるのですがベテランの皆様はどう思われますか？

2020/01/03(金) 11:03:04.63

好きにすればいいよ
どっちでも文法的に正しいし、どっちがより良いかは証明不可能

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/03(金) 12:23:01.84

>>595
それはハンガリアン（の一種）といって悪い作法だと思います

2020/01/03(金) 14:09:52.04

>>592
A Promise that resolves to a Response object.
この言い回しが分かりにくて
「Responseオブジェクトを解決するところの1つのPromise」
とはコードで書くとどういうPromiseの事を言っているのか分かりません。

2020/01/03(金) 14:15:20.54

>>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.36

>>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.37

これらやその他の記事を読む限り、
Javaはどうもマルチスレッド周りの問題をまともに解決しに行ったように見える。
時代的に「最先端言語」としての矜持があったのかもしれん。
結果、爆死して今に至るのかも。
例によってデッドロック周りがやたら記述されているが、これに関しては、
折角ポインタを廃止して消し去った、「悪いプログラム片が少し混入しただけでアプリ全体がアウト」
になるCの問題点がそのまま復活してしまうから、Javaとしては絶対に許せない。
かといって、上手い解決策も見つけられてない。

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

歴史の流れとしては極めて妥当なのかもしれん。

2020/01/03(金) 15:58:36.89

>>600
君いわく超大昔にとっくに解決したはずのものが現実には多くの糞を生んだ
しかし新たに設けた抽象化であるTaskがそれれらの大部分を解決したということだな
君の言う関数という抽象化は非同期処理の現実には大して役に立たなかった
事実は事実として受け止めたほうがいいよ

2020/01/03(金) 17:14:48.26

>>602
まあ俺のスタンスは変わらんけどな。一応纏めておくと、以下。
・Taskはゴミ。今となっては（非同期には）要らない。
・asyncは「抽象化」ではなく非同期の「記法」。
・asyncにより非同期の煩雑さは解決された。

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

君がこれらを認めないのは君の自由。

2020/01/03(金) 17:23:20.75

多くのケースでasyncawaitでコーディングしたほうが簡単だがTaskが要らないわけではない
並列処理では相変わらずTaskが活躍している
またasyncawaitを実装するためにはTaskという抽象が必要だった
関数で抽象は完結してるなどとトンチンカンなことを主張して思考停止していたらasyncawaitの発明には到達できなかった

2020/01/03(金) 17:35:57.54

並列処理はうまく書けないからasync/awaitは中途半端な糞！にならないのが不思議だなあ
てかこのひと年末からずっと何かにつけて「ほにゃららは糞！おまえらは信者！」から入るのに
ひたすら教えられてるだけなのが面白いね

2020/01/03(金) 17:56:04.43

>>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.42

>>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.09

>>605
そうとしか取れないのはお前が馬鹿な信者だからだ。
俺はそもそもasyncが悪いなんて言う気もない。いい物はいいと認めるだけ。
お前みたいな馬鹿信者は俺という『人』を全否定したいから、全部否定するとか、
お前みたいな馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。

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

ただまあ、お前らがTaskにこだわるのなら、第一級関数ってのも意味があるのかもね。
Task自体はラムダをオブジェクト化したようなものであり、関数型で言う第一級関数的なものだ。
JavaScriptならFunctionにメソッド生やして全部Task的にすることも可能だ。（やったら別の意味で殺されるはずだが）
俺には第一級関数の有り難み自体はよく分からないのだけど。

2020/01/03(金) 19:31:35.35

> C#/.NETが扱うのは、そもそも並列が効くような案件でもないし。

やっぱり使ったことない人だったか

2020/01/03(金) 19:35:32.04

通信やファイル等々は並列化前提くらい当たり前に使う部分
そもそもまともに開発したことないんでしょ、彼は

2020/01/03(金) 19:40:22.89

>>608
> 馬鹿でも明らかに分かるほど間違った態度を取ってくれないと困るようだが。
馬鹿がasyncマンセーTaskは糞なんて明らかに分かるほど間違った態度を取ってるから別に困って無いよ？

> そりゃ重要度が違うからな。実際、お前ら並列処理なんて書いてないだろ。
まあ日常的に並列処理を書いて無いならasync信者になるのも止む無しだね
粒度の粗いAPIを呼び出しているだけで済むプログラマ人生なのが良くわかる
まさに「馬鹿でも出来るようになっているからこそ馬鹿が調子こいてる。」

2020/01/03(金) 20:21:02.89

並列実行をHPC系の計算でしか使わないと思ってるのかなあ
スマホゲームにだって使われている、カジュアルに使えなくちゃ今時大変な機能だと思うけど

2020/01/03(金) 23:02:49.12

c#の並列処理ってコントロールが糞だから仕方なくって場面ばっかりだけどね

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

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

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

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

という具合で実行

色々触ってきたけど[方法1]で
実行できた言語って一度もネーな（笑）

2020/01/03(金) 23:20:55.60

そうだね、パソコンがなんでもやってくれると君みたいな頭でもプログラムが書けるね

2020/01/03(金) 23:21:49.89

とりあえず並列処理と並行処理は区別しよう

2020/01/03(金) 23:46:23.43

>>610
既に突っ込まれてはいるが、それは一応「並列(Parallelism)」ではなく、「平行(Concurrency)」という。
が、まあ、これはさておき、君の使い方はやはり平行でなく非同期(Asynchronous)だと思うよ。
実際、例えば、「asyncブロック」というのが次に来たとして、仕様は、
・これまでの記述の複数のasync文を　async { } で囲うことが出来ます。
・asyncブロック内のasync文は同時にディスパッチされます。
・全てのasync文が完了次第、asyncブロックを抜けます。
という、async { } で囲うだけ！簡単！楽チン！な物が提供されたら、
今お前らが使っているであろうTask<TResult>は不要になるだろ。

ディスパッチャを自前で書く気がなければTaskは基本的に要らないと思うけど。
本来「平行」の場合は表ジョブと裏ジョブの同期は割と厳密に取る。
手が空き次第捌け、順番はどうでもいい、は非同期の使い方で、大概はほぼこれだろ。

2020/01/03(金) 23:48:32.86

×　平行
○　並行

2020/01/04(土) 00:04:34.11

>>610
>>616
と思ったんだが訂正。
確かに今の仕様のasyncだとまだTaskは廃棄出来ないかも。
現在は明示的に発行と結果回収を別の行に書いてるんだな。それでawaitで引っかけてると。
俺はこれ、遅延評価で勝手に引っかかってるだけだと勘違いしてたわ。
すまんね。

2020/01/04(土) 00:09:37.91

やっぱり使ったことない人だったか

2020/01/04(土) 00:48:40.79

通信やファイル処理はCPUとは別のデバイスが同時に処理するから並列処理
ネットワークやディスクにアクセス中にスレッド消費されたら使い物にならん

2020/01/04(土) 01:17:00.82

誤った指摘をしている人がいますが、>>610は、相当ミスらない限り並列処理かつ非同期処理です
並行処理である保証は全くありません

2020/01/04(土) 02:02:38.56

並列は、CPU に使う用語

並行は、処理に使う用語

2020/01/04(土) 02:34:27.40

こんだけ暴れておいてこの結末ｗ

2020/01/04(土) 02:47:20.03

>>620,621
ファイルや通信のI/O処理中にCPUでは別の処理をするってのは
典型的な並行処理の例で一般的には並列処理とは呼ばないぞ

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

基礎的なことなのでもうちょい勉強してくれ

2020/01/04(土) 03:01:30.66

>>624
>>621は冗談で言ってるんだとは思いますし、何が一般的かは知りませんが、私はこの並行処理の記述に従って理解しています
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
なお、私の知る限りでは他分野でも同じです

2020/01/04(土) 07:26:04.88

>>624
並行処理ってのは、単一の主体が短いタイムスパンで複数の処理を切り替えて処理することによって、まるで並列処理をしているように見せかける技術のことな
言うまでもないが、並列処理は複数の主体が、見せかけじゃなく同時に別の処理をしてる場合な

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

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

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

基本的なことなので、勉強してくれまじで

2020/01/04(土) 07:33:09.39

C#で並列処理を勉強しようとしたら大抵初めに出てくるParallel.Forすら知らないんでしょ
だから英単語出してきてまでそれは平行だ！とか指摘しちゃう
英単語わかってるなら並列だってわかるはずのにｗ

もう以前からびっくりするくらい知識が浅い

2020/01/04(土) 07:49:31.73

あとマルチproccessとマルチthreadも同じやね
using System.Threadingも書いたことなんだろう

C#に無知でこれらを知らないは別に良いけど一般的なソフトウェア開発で並列処理なんて書かないとかいう指摘も的外れ
C#に関することに無知なのは触ってなけりゃ普通のことだろうけど今や当たり前に行われる並列処理をスパコンのものでお前らにはわからんだろうな、とか言っちゃうのは技術者としてどうかと思う

2020/01/04(土) 08:29:25.67

プログラム内の厳密な並列ってなくね？
おそらく無理じゃね
同じメモリ空間をCPUが同時にアクセスできないよね？
paralle.forとか俺はこんないい加減な前準備でできると思ってないけどね
どういう仕組みか知らんけどｗ
多分なんちゃってだろ
やった感じ直列で処理したほうが早い感じになってうんこだったよ
ちなみにフルHDの画像処理を上から三等分にしてparalle.forでやってみたがクソ遅い上に並列にやってない気がしたけど
みんなはこんなもん使えてるの？

ところでスレッドってスレッドスイッチするし積まれたタスクを順番に処理してるだけだよな？
その切替タイミングはプログラム内のsleepやDoEventsだよね？

2020/01/04(土) 08:50:02.37

変なの増えた

2020/01/04(土) 09:09:30.45

>>629
> その切替タイミングはプログラム内のsleepやDoEventsだよね？
いつの時代の老害だよ…

2020/01/04(土) 09:10:51.45

>>629
パイプラインとかキャッシュとかレジスタとかマルチスレッドとか、CPUの技術を少しは勉強したほうがいい

2020/01/04(土) 09:16:33.71

>>631
え？じゃあどこ？

2020/01/04(土) 09:23:34.37

>>632
それを実際に言語の機能に適用してるかどうかは別だよね？

なんか超遅かったよ
もし並列に動いてるなら画像処理は単純に三分の一で終わったはずだよね？
ところがむしろ3倍以上かかってるんだな
なんか前準備に色々条件があるのか？
こんなもん役に立たないのか？
該当する処理が本当に適用できるのかはチェックが必要だと思うな

2020/01/04(土) 09:34:32.95

スレッド切り替えと言うが、今日日マルチコアだぞ。
Parallel.Forも一つだけど、PLINQなんかも実は色々効いてくる。
まあ、Taskは便利よ。
スレッドプールを有効利用するのは手でやると事故るので、Taskに任せるほうがよかろう。
その上でUIスレッドに返したければUIスレッドに返すコード書けば良いだけなんだし。
逆に言うと、UIスレッドからTaskをawaitしたときに元のスレッドに戻って来てる事自体が例外的な処理に近い。

2020/01/04(土) 09:44:36.22

parallelにしてもちゃんと理解してないと遅くなることだってありうるよ
並列化できない処理をparallelしたって切り替え処理とかが無駄に働いて逆に遅くなることもある

コードでも上げてみりゃどこが間違ってるか指摘できる人もいるんじゃない？

2020/01/04(土) 09:49:49.34

>>636
コードを見ないとわからない？
IDEが教えてくれる？
なんにせよ使えないよそんなの

2020/01/04(土) 09:54:48.34

>>635
それ並列でやった処理結果まとめられないじゃん
やりにくいし

結局処理単位は自分でブツ切りにしないと途中経過出力できないし
実質この手の機能ってc++の頃から別に便利でもなんでもないゴミクズ機能で停滞してるよね？

2020/01/04(土) 09:57:09.90

>>633
プリエンプティブでググってこい

2020/01/04(土) 09:59:40.19

>>637
いや、あんたが何かを勘違いしてるかもしれないことをコードレビューしてあげようかって言ってあげてんのｗ
詳細な実装は開示しないけど俺が試したら遅くなった！parallelなんかまともに使えない！って主張なの？
世界中のプログラマが有益に利用してるんだから間違って利用しちゃってるなら正せばいいだけじゃん
ググりゃ腐るほど日本語でも記事はヒットするんだし

2020/01/04(土) 10:01:55.73

3分割したら3倍異常遅くなるって例えば各スレッドでファイルを読み込んでるだけじゃねーの？
そんなやり方したらそりゃ遅くなるよね

2020/01/04(土) 10:02:04.61

>>640
フルHD画像処理を上から三等分でparalle.forって言ってんだからやって動くサンプル出してこいよ
おそらくdobon辺りに貼るだけでparalle.forかけて画像処理ループさせるだけだ
10分だぞ
やりたきゃ頑張れ

2020/01/04(土) 10:14:00.73

GAIJI vs GAIJI

2020/01/04(土) 10:18:25.47

ヤベエ逸材多過ぎだろこのスレｗ
今までどこに潜んでたんだコイツら

2020/01/04(土) 10:31:54.67

>>638
纏められるよ。
PLINQ使ってみ。
途中経過が必要ってこと自体、多分並列化出来てないから考え方がおかしいよ。
並列にやってるんだから途中経過なんて足し込まないと出せない事はやるべきじゃないでしょ。
足しこみは並列にできないんだから、そこで足並み揃えちゃったらそりゃ並列に動かんよ。

2020/01/04(土) 10:57:29.93

まあとりあえず、「並列」「並行」については最近は混同されてるし、実際混同しても問題ない領域が多いし、
文系馬鹿C#erが主流なこのスレでその厳密性を求める意味はない。
ただまあ、ファイルとCPUでは速度差がありすぎるから、
まともなスケジューラーなら並列に書いてても並行になってしまうとも思うが。
しかしMSはそこも含めて隠蔽しようって事なんだろ。これ自体はいい。

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

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

問題はやはりMap/Reduceでないことで、結局、「関数」で処理を抽象化出来ているから
関数を直接扱う「関数型」の方がI/Fは綺麗に並んでしまう。
そこをForにこだわったのは間違いだと思うよ。

2020/01/04(土) 11:03:02.06

とりまコード見ないとなんとも
なんかで排他制御でも効いてるんだろうけど

2020/01/04(土) 11:03:38.49

>>625
そのリンク先に並行処理についての記述は一切無いぞ

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

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

君の例は1つの物理装置で処理されてようが別々の物理装置によって同時に処理されてようが関係なく並行処理(Concurrent Processing)の例
それを並列処理とは呼ばない

2020/01/04(土) 11:11:54.60

そもそもawait/asyncは、非同期処理を同期処理のようにかける仕組みであって
マルチタスクそのものじゃなくて周辺技術だよな

2020/01/04(土) 11:53:37.81

>>648
いや、そっちが理解間違ってるよ

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

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

複数の装置にスケジューリングすることを並行処理と呼んでる場合もあるが、それは正確には並列処理と並列処理のハイブリッドだな
君が言ってる同時に処理される場合もある、というのはこのことだろうな

2020/01/04(土) 12:07:21.44

>>650
どっちが正しいと断言するつもりはないけど、この並列処理と並行処理の定義はどこから持ってきたものなの？

2020/01/04(土) 12:08:56.85

>>646
自動的に適切な単位に分割されたMapとReduceがPLINQで実現できると思うんだが。

2020/01/04(土) 12:27:07.45

>>651
放置しときなよ
用語知ってる俺スゲー君同士の戦いなんてどうでもいいし

2020/01/04(土) 13:10:03.26

この年末からのつまんねえ言葉遊びの流れほんとクソ

2020/01/04(土) 15:56:23.34

装置どうこうで並列や並行いってるやつらは
まずマルチコアなCPUを装置としてどう見てるのか書け
話はそれからだ

2020/01/04(土) 19:35:04.89

>>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.95

asyncも、ググれば分かると思うが、実はasync/awaitの片方はキーワードとしては要らない。
その場合には実行/フェンスについて、実行は今まで通り記述した時点で開始、
フェンスは結果を使うところで暗黙的に、ということになる。（つまり今ならawaitが要らない）
これはこの界隈ではすごく一般的な考え方で、
例えばアセンブラでDIVやSQRT命令みたいにレイテンシが長い命令を配置したとき、
結果レジスタを使わない場合はどんどん流し、結果レジスタを使う場合だけそこで一旦停止して結果待ち、という事を30年前からやっている。
だから「非同期」というよりは「並列化＋パイプライン(可変長レイテンシ）」として考える方がいいのかもしれないけど、
いずれにしても今は「明示的にawaitを書く」というある意味MSらしくない、
どちらかというとWeb系的ドベタ仕様で、だからこそ君らもTaskマンセーな訳だが、
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。
そして「非同期」と「同期」は一文字も変わらない同じ関数で実行可能となり、完全な抽象化が実現出来ることになる。

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

ただそれにしても、繰り返すが、CPUのパイプライン構造を知っていれば、あ、確かに間抜けな仕様だな、とはすぐに分かるだろ。
俺が信者だと揶揄しているのはそこら辺であってさ。

2020/01/04(土) 19:51:30.64

別スレ立てたら?

2020/01/04(土) 19:54:05.88

もしかしたら伝わらないか？とも思うので一応。
俺は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.76

>>659
そのコードじゃ非同期処理が完了してなくても"～ are ready"って表示されるだろ。

2020/01/04(土) 20:09:00.48

c++スレにいた長文マンかなこいつ

2020/01/04(土) 20:44:38.22

>>660
まあそこはツッコミ来るかとは思っていたが…。

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

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

ただ、まあ、何らかのフェンス構文自体が必要なのは認める。
しかし、当然だがフェンス自体は不要なら書かないものだし、
普通に「返り値を使う」いわゆるお行儀のいいプログラミングをしている限り、実際に不要だ。
だからじきに、みんなが「await って実は要らなくね？毎回お約束的に書かされるだけだろ。」
と思いだした頃に、廃止されるんじゃないかな。
そしたらその階層を取り扱う必要もなくなり、Taskも廃止できる。

2020/01/04(土) 20:59:50.92

>>657 >>662
awaitの結果を必ずしも使うとは限らないのに、本気で言ってるの？
async Task<void>のメソッドなんていくらでも作ることあるだろ。
そりゃ、async Task<bool>にでもしてtrueでも返すようにして、if文で判定するとかはできるけど、そんなの正直言ってasync/awaitからの退化だよ。
C#では非同期実行の方が基本的にはあえてさせることなんだから、awaitなくしたとして
コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
なんでもかんでもどうやらある程度経験が豊富そうなJSを基準に考えちゃうみたいだけど、非同期が当たり前のJSとはとりまく環境が違うと思うよ。

2020/01/04(土) 21:49:39.49

await不要って園児並みに相当バカ
無くなったら何が困るかの簡単なことに気づかないとか、普通の人でもわかることだよw

2020/01/04(土) 21:59:07.73

そろそろ冬休み終わるから謎の長文更新も途切れるかね？

2020/01/04(土) 22:10:43.14

冬休み関係ない人かもしれない

2020/01/04(土) 22:16:18.30

前にも言ったがそんなに素晴らしいものなら、C#の言語チームに提案してこい
誰にも相手にされんだろうが、ここでグダグダと怪文書を書き込み続けるよりは生産的だろ

2020/01/04(土) 23:11:07.21

>>663
> コードを読んでてもわからないところが非同期になっていたら結構困ると思うけどなぁ。
これはその通り。だから俺の理想は以下のコードになるけど、
これはおそらくプログラミング理論的には>>659より汚いコードだとされる。(抽象度が落ちてる）

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

async_fence(); // これ以前のasync関数はこれ以降は完了していることが保証される
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

現行からの変更点としては、
・キーワードawaitをasyncに変更、書く場所は同じ、ただしwaitせず実行して貫通
・キーワードasyncは呼び出し側に明示的に付け、定義側には要らない
・必要ならasync_fence()でフェンス、無ければ実行結果が使われるときに自動的にフェンスされる
・Egg/Bacon/ToastはTaskではなく値、よってキャンセル等は面倒だがどうせしないからよし
ただこれだと async を async()として関数化してリッパーにすれば現行のC++等で実装出来そうな気がしてきた。
これは勝手にやってみるかも。

> 非同期が当たり前のJSとはとりまく環境が違うと思うよ。
コミュニティとしては君らの方が慣れてないだけで、プログラミングとしては大して変わらんよ。
JSもI/O以外は全部同期だし、非同期部分は限定されてる。(なおgetElementsByClassNameは非同期ではなく遅延評価)

2020/01/04(土) 23:27:22.94

仕様を劣化させてるだけじゃん…

2020/01/04(土) 23:40:07.01

>>668
暇だからリファクタリングしてあげた

var cup = PourCoffee();
Console.WriteLine("coffee is ready");
var eggs = FryEggsAsync(2);
var bacon = FryBaconAsync(3);
var toast = await ToastBreadAsync(2);
ApplyButter(toast);
ApplyJam(toast);
Console.WriteLine("toast is ready");
Juice oj = PourOJ();
Console.WriteLine("oj is ready");
await eggs;
await bacon;
Console.WriteLine("eggs are ready");
Console.WriteLine("bacon is ready");
Console.WriteLine("Breakfast is ready!");

コイツの管理者はコードレビュー大変そう

2020/01/04(土) 23:47:15.01

毎日毎日赤っ恥書きながらも上から目線を崩さない姿勢はだんだん可愛く見えてきたなｗ

2020/01/04(土) 23:59:24.33

>>670
それはawaitで書けばほぼ現行通りだろ、というわけか。
まあその通りだが、呼び出し側に async が付いているのがミソなんだよ。
今はそれが Task<TResult> だから明示的だが、var になると明示的でなくなる。これがよくない。

また現行の await は事実上フェンスとして使われているから、
君が書き直したその通りなのだけど、俺は既に言ったが、
「フェンスは出来るだけ使わない」（というよりこれは常識とされる）ので、ここが気に入らない。
書かずに済むのだから書かすなよ、だ。

そして現行の関数宣言部、 async を付けるわけだが、これは意味的に要らん。
(現行の仕様でも特に要らないはず）
ジョブの最上位関数はマルチスレッド/シングルスレッド./同期/非同期関係なく同一に書ける。
それをどう呼び出すかで同期/非同期等切り分けるべきであり、
定義側にわざわざ async と非同期専用みたいに書くのが気に入らない。
同期で呼び出したら同期で動作するだけの関数なのに、だ。

2020/01/05(日) 00:05:02.27

>>670
ああ、だから俺は、違いは

同期：
var eggs = FryEggsAsync(2);

非同期：
var eggs = async FryEggsAsync(2);

だけにして欲しいな、ということ。
現行のコードに async を挿入するだけでコアが余っていれば非同期でその関数が実行され、高速化する、ということ。

2020/01/05(日) 00:17:31.34

言語の感想文はブログで書け
薄っぺらい知識なのを宣伝してるだけだぞw

2020/01/05(日) 00:37:05.87

>>672
あなたの考える仕様はvarの比ではなく、暗黙的でわかりにくい
普通に変数にアクセスしているだけなのに、非同期処理と待ちが入るなんてはっきり言って迷惑

それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
・CPUバウンドなら同期的
・IOバウンドなら非同期的
大まかにこの基準で切り分けて、それをシグネチャで明示したほうがいい

2020/01/05(日) 02:47:09.06

C#の仕様策定プロセスはオープンなんだからこんなところでウダウダ言ってないでgithubで提案してみれば？
ツッコミ入って「C#コミュニティはクソ！」って言い出す未来しか見えないけどさ

2020/01/05(日) 04:32:02.28

まさかと思うけど、asyncなメソッドはawaitしないと呼び出せないとか思ってるんじゃないか

2020/01/05(日) 09:05:43.12

>>675
varがわかりにくいというのはお前の慣れの問題。

> 待ちが入る
待っているのは同期設計だ。
毎行で「前行の終了を待つ」からブロッキングと呼ばれる。

> それと呼び出し先を非同期/同期の両方に対応させる設計は良い習慣ではない
そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
例えば、MatrixMulという重たい計算があったとする。
すると、日常的にC#で並列をこなすお前らは、これを高速化する為に、Task<TResult>に分割するわけだろ。
その場合、MatrixMulは「同期関数」だが「非同期」で実行される。
「非同期」ってのは関数の性質ではなく、呼び出し方であって、逆に、「非同期関数」を「同期」で呼び出すことも当然出来る。
だから被呼び出し関数に async を付けること自体がナンセンスなんだよ。
付けるとしたら、呼び出し部分か型で、
var eggs = async FryEggs(2);
AsyncTask<Egg> = FryEggs(2);
であって、お前の流儀は
Task<Egg> = FryEggsAsync(2);
なんだろうけど、これはナンセンスなんだよ。ハンガリアンならぬ、アシンカリアンでしかない。

だから、今の仕様は
A. 非同期に慣れてないC#erへの補助輪
B. ヘルスバーグが中二病全開
C. 実はコンパイラの都合で、async付けてくれればパッチ当てがメチャ楽だったから適当こいて付けさせた
のどれかで、俺はBだと思うけど。

なお気持ち悪さではSQLをべた書きするLinqの方が上だと思う。
でも linq を使った関数に一々 linq を付けることもないし、
同様に parallel を使ったら parallel を付けて回る、ということもないんだろ。
await 使ったら async 付ける、ってのは全くナンセンスだよ。
非同期は、今後は、今のお前らが思っているほどは特別なものではなくなるんだよ。これはもう確定してるだろ。

2020/01/05(日) 09:35:53.95

>>678
async/await考えた人が元々asyncは必ずしも必要ないと言ってるのに、何をさも自分が考えたように言ってるんだ？

awaitいらねーとか真正アスペかよ

2020/01/05(日) 10:52:51.13

>>678
自分はvarがわかりにくいとは思ってない
>var になると明示的でなくなる。これがよくない。
あなたがvarをよく思ってなさそうなので、あなたの考えた謎仕様のほうがそれより遥かにわかりにくいですよ、と言っただけ

>そんなわけあるか。もう一度言うが、非同期ってのは呼び出し方法であって、ジョブそのもの（関数）の性質ではない。
これも間違い
例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
呼び出し先の性質によって非同期が確定する典型例

CPUバウンドの場合、呼び出し先で非同期をサポートすることも可能だが、基本的にそうする必要は無い
スレッディングのコストは無料じゃないのだから、呼び出し先はすべて同期的に実装して切り替えオーバーヘッドを減らしたほうが、全体的なパフォーマンスが向上する
UIと止めずに応答性を高めたいだとか、非同期にする明確な理由が出来たらそこで初めてTask.Runすればいい

上で基本的にと書いたのは、CPUを食い尽くしてでもいいから時間的に早く処理を終わらせたい、という理由で並列化する場合があるからだ
この場合は、プログラムを並列処理用に最適化して設計するのが定石だ
なので、この場合に関しては逆に非効率的な同期版をサポートする理由がなくなる

asyncが構文として不要なのはわかってるが、そんなつまらない話はあなた以外はだれもしてない

2020/01/05(日) 11:21:56.38

なんで比較にLINQが出てくるのかめちゃくちゃ謎
SQLっぽい書き方のLINQしか知らないのかな？
メソッド拡張の方のLINQはmap/filter/reduceと書き方がちょっと違うだけの単なるメソッドを呼び出し
してるだけなんだけど。

2020/01/05(日) 11:33:14.86

>>680
657 デフォルトの名無しさん (ﾜｯﾁｮｲ 797b-s4wZ) sage 2020/01/04(土) 19:37:21.95 ID:kFIotbKU0
こう説明されれば「あ、確かにawaitいらねえな」とはすぐに分かるだろ。
多分君らが非同期にだいぶ慣れた頃にawaitは廃止されると思うよ。

>>680
asyncが構文として不要なのはわかってるが、…

asyncもawaitも不要なんですね、真正アスペ君w
たったこれだけのシンプルな間違いさえわからない、自分で理解できてない
これが真正アスペでないと誰が言えようかw

2020/01/05(日) 12:17:09.89

awaitは必要だぞ

2020/01/05(日) 14:01:08.94

>>680
なるほどお前が全然分かって無いというのは分かった。

根本的に勘違いしていると思うのだけど、ジョブの中身を同期専用/非同期専用で設計することはない。(というか、できない？)
既に言ったが、MatrixMul、要は行列の掛け算が100ジョブあったら、4CPUならそれを4個ずつ積むだけだ。
このとき吐けた順にガンガン積んで処理していきたいなら、
「非同期」にして最初から全部キューイングしてディスパッチャに任せるだけ。
ジョブ自体が「非同期」ではなく、ジョブの処理の仕方が「非同期」なんだよ。
MatrixMulを非同期専用に書き換える、なんて事はない。というか、出来ない。

> 例えば、ネットワークやファイルなどIOバウンドな処理は、CPUとは異なるデバイスで処理されるので、原理的に非同期にするしかない
これもない。というか、C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
ここはJavaScriptのスレではないのだが、それを間違えたか？

これについては「JavaScript 10k （またはc10k)」でググってくれた方がいいと思う。
Sleepがない方がパフォーマンスが出る！というのがJavaScriptの宗教だから、蕩々と説明してあるはず。
ただしJavaScriptもメジャーになってしまったし、おそらく以前ほど叩かれなくもなっているので、最近はこの話題も聞かないが。

I/Oを非同期として分離する必要があるのは、JavaScriptがSleep無しのシングルスレッドアーキテクチャだからであって、
Sleepありのマルチスレッドアーキテクチャならその必要はないし、C#含めて通常の言語は全部これだよ。

2020/01/05(日) 14:56:44.29

なんか言い争ってる両者ともそもそも同期非同期の意味が分かってない予感w

2020/01/05(日) 14:57:08.99

>>684
>要は行列の掛け算が100ジョブあったら〜
これは呼び出し先を同期的に実装して、呼び出し元で非同期実行してるパターン
>>680で言うと
>CPUバウンドの場合〜
の段落のこと
このパターンでは呼び出し先は同期版だけサポートすればよく、非同期版までサポートする必要はない
無意味に同期/非同期の両方をサポートしなくていい

>C#にしても、他の言語にしても、ファイルオープンは通常は同期だ。
違う
ファイルIOは背後で非同期的に処理されているが、APIの中でブロックしているから同期的に見えているだけ
昔は言語側の非同期サポートが洗練されていなかったため、妥協してこういう書き方に落ち着いた
C#ではTaskとawaitが導入されて、非同期処理の記述が大きく改善されたため、
原理的に非同期なものは余計なことをしないで、非同期なものとして作れば良い、ということになった
このパターンでは呼び出し先は非同期版だけサポートすればよく、同期版までサポートする必要はない

処理の性質によって同期版か非同期版のどちらかだけを作ればよろしい