17/03/23 02:21:34.59 VjAjr2s9.net
>>565
async/awaitやIProgress<T>あるから、Taskの継続を直接使う事はあまり無いな。
間接的には使ってるわけだが。
592:デフォルトの名無しさん
17/03/23 02:21:39.46 9gkqdxMB.net
>>566
時代関係ないから
スレッドセーフにするとパフォーマンスが犠牲になるのはUIだけじゃない
BCLのクラスのインスタンスメソッドも大半はスレッドセーフじゃない
593:デフォルトの名無しさん
17/03/23 02:22:11.13 Un9Q+jtZ.net
Win32は、当時のオブジェクト指向の実現にむけての試行錯誤が見れるのは面白いかもしれない
メッセージ飛ばしたり、メール飛ばしたり、色々試行錯誤の末にC++の仮想テーブル方式にたどり着く訳だけれども
その前の段階のオブジェクト指向が見れるよw
594:デフォルトの名無しさん
17/03/23 02:23:39.71 Un9Q+jtZ.net
>>569
いつまでも凝り固まってますねwww
もうハイハイって感じですわ
595:デフォルトの名無しさん
17/03/23 02:28:42.19 Ei+8urX3.net
しかしGUIなんて所詮人間速度だし、パフォーマンスって要らないよな？
フォームに関しては最初からマルチスレッド対応でinvokeの必要無しの方が良かった気がするが。
596:デフォルトの名無しさん
17/03/23 02:30:27.90 9gkqdxMB.net
>>571
いるよね、こういう量的な進歩と質的な進歩の区別のつかない�
597:z 馬鹿な奴だ
598:デフォルトの名無しさん
17/03/23 02:31:53.25 VjAjr2s9.net
何でもマルチセーフにすれば良くなるってもんでも無いのね。
排他制御のコストは大きいから、なるべくそれを無くす設計が重要。
599:デフォルトの名無しさん
17/03/23 02:32:30.61 Un9Q+jtZ.net
>>572
いやいや、それでもあった方がいいよ
マルチスレッドできっちり分散できれば、1CPU辺りの負荷が軽くなる
すると低クロックで動いて消費電力が小さい。
シングルスレッドだと、同じ負荷でも1CPUに集中するからクロックが上がってしまう。
600:デフォルトの名無しさん
17/03/23 02:35:01.08 Un9Q+jtZ.net
>>573
質的にはTaskは逆立ちして徒競走しているようなモンだなw
普通立ってに走れよ、頭オカシイんかいってなもんだね。
601:デフォルトの名無しさん
17/03/23 02:36:32.46 9gkqdxMB.net
しかし、マルチコアっていうのは苦し紛れの「苦肉の策」であってポジティブな進歩じゃないって
パソヲタレベルでも知ってる常識だと思ったけどプログラマでもそういう認識がない奴がいるんだね。
そういう奴は「人月の神話」って言葉も聞いたことないんだろうな。
生産性は作業者の投入人数に比例しないのはコンピュータも同じだよ馬鹿
602:デフォルトの名無しさん
17/03/23 02:38:13.08 Ei+8urX3.net
>>575
いやお前実は分かってないだろ。
575はinvokeを肯定しているぞ。てかお前どっち派よ？
603:デフォルトの名無しさん
17/03/23 02:40:35.49 Un9Q+jtZ.net
>>578
async / await 最新わかってる俺スゲーなヤツが死んでほしい派
技術的には、まぁあるもん使うさってなもんだ。
604:デフォルトの名無しさん
17/03/23 02:57:11.32 VjAjr2s9.net
>>576
Taskはスレッドプールを使いやすくしたもの。
スレッドプール自体は昔から使われるテクニックだし、なんでそこまで嫌うのか分からん。
Taskのおかげで非同期処理が非常に楽に扱えるようになったのに。
605:デフォルトの名無しさん
17/03/23 03:07:35.11 Un9Q+jtZ.net
>>580
以前作って滅びたATLなんかと同じだね、入門者がすぐに理解して使えない物は糞
WPFも同様の香りがするね
分からないけれどなんとなく使えているって人だらけになって理解していないから、エラー対処ができない。
そうすると、全部特定の人に負担が行く、そんなコードやライブラリは使えない。
これはマイクロソフトの象牙の塔だよ
606:デフォルトの名無しさん
17/03/23 04:45:12.92 0wLqn0eU.net
ATLがいつ滅んだんだよw
607:デフォルトの名無しさん
17/03/23 07:10:17.81 UmFjwc/F.net
昔の名残とかじゃなく、単にマルチスレッドでUI部品を扱うのが大変だということだと思うんだが
ユーザーインターフェイススレッド - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
>例えば、Java の AWT では、1996年の最初の時点では、
>単純にスレッド間でデータ共有型のマルチスレッドになっていた。
>しかし、データ共有するには、ロックをかけないといけないが、
＞親コンポーネントから子コンポーネントを呼んだり、
>コールバックで子から親を呼んだり、
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
>異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。
>これはソフトウェアが非常に複雑になる原因となってしまう。
>また、ロック順序のミスが引き起こすデッドロックは常にではなく
>たまに発生したりすることの多いバグ（時間的確率要因が関与する偶発性のあるバグ）であり、
>バグ取りが大変になるという問題があった[
608:3]。 > >そこで、1997年の Java の Swing からは、 >UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから >操作しなくてはならない、というルールを設けた。
609:デフォルトの名無しさん
17/03/23 07:23:37.05 i5lX3ZQq.net
それを昔の名残とかラッパー、速度優先って言ってるんでしょ
マルチスレッドにしようと思ったらできるんだから
610:デフォルトの名無しさん
17/03/23 08:05:24.99 eX8m9MWo.net
WinFormsやWPFを含めたGUIフレームワークって
イベントハンドラなどのユーザーコードに制御を渡す前後で
一時的に状態を変えたりしてることが多いから、
それ以外のタイミングで触られると壊れる
結局それを防ごうとするとユーザーコードの実行タイミングまでブロックすることになるので、
Invokeと変わらなくなる
611:デフォルトの名無しさん
17/03/23 08:14:01.02 HovpjxiM.net
>>584
> マルチスレッドにしようと思ったらできるんだから
話がループしてるぞ
やればできるけどコールバックとかでロックの管理が面倒だしUIだから極限まで性能追い求める必要もないから
>> UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから
>> 操作しなくてはならない、というルールを設けた。
ってことだろ
612:デフォルトの名無しさん
17/03/23 10:27:00.68 BTeOg9CT.net
>>564
COMのアパートメント問題を解決するためじゃないの？
厳密にはInvokeしなくて良いケースもあるけど、それを保証する方法が皆無に等しいという。
ウインドウメッセージ云々とか、本質とはかけ離れている気が。
613:デフォルトの名無しさん
17/03/23 12:30:56.91 Un9Q+jtZ.net
>>582
もう誰も使っている奴いないだろう、放棄されて保守だけが残っている。
こういう技術はいずれそうなるよ
614:デフォルトの名無しさん
17/03/23 12:53:23.45 Un9Q+jtZ.net
>>586
UI側がバージョン管理システムみたいな扱いをすればいいんだと思うけどね
非ロック型で同期をとる方法としては有効だと思う。
いわゆる
読み込んで、内容を変更して、読み込み時点データとともにUIに返す。
UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
ロックオブジェクトが自分自身に限られるからデッドロックの可能性はない。
この方法の場合、読み出すだけならロック不要でいつでも読み込めるしね。
俺は、UIに関してはそういう設計にして自分のメソッドはすべてスレッドセーフだ。
長年の実績ある方法だし、このやり方は非常に優れていると思う。
更新失敗とリトライは発生するが、並列度はかなり高くなる。
デッドロックは皆無で、見通しも良い。
615:デフォルトの名無しさん
17/03/23 12:55:44.66 Un9Q+jtZ.net
>>589 に追加
これのよい所は、バージョン管理システムは普通誰でも使わなきゃならないもので
どういう風に機能させるのか誰にでもすぐ分かる。
問題が発生しても初心者に簡単に解決できるという点が良いと思っている。
616:デフォルトの名無しさん
17/03/23 17:07:47.97 EtPn1ouj.net
なんか酷いやり取りだね
マルチスレッドを根本的に理解してないのが何人かいるねw
スレッドセーフに作ることは高コストだから特に理由がない限りそうしないのは
マルチスレッド理解の初歩の初歩だと思うんだけど。
あれだ、UIは別スレッドからのアクセスを検出して例外投げるようになってるわけだけど、
例外が投げられなければ何も問題ないはずだ、っていうVBerな発想なのかねw
617:デフォルトの名無しさん
17/03/23 17:21:43.84 ncdnXTN/.net
.NETは実行コストよりも実装コストを重視する傾向にあるからね
スレッドセーフなformになってもいいと思うわ
618:デフォルトの名無しさん
17/03/23 17:24:03.63 30c+rZIc.net
>>592
君のコードはイベントハンドラが並列に実行されても大丈夫?
利用する側の実装コストも確実に跳ね上がるよ
619:デフォルトの名無しさん
17/03/23 18:15:58.21 ncdnXTN/.net
マルチスレッド動作のformにとは言ってないんだよ・・・
620:デフォルトの名無しさん
17/03/23 18:57:02.57 99dRkoLd.net
>>592
そこでwpfのバインディングですよ
621:デフォルトの名無しさん
17/03/23 1
622:9:28:24.32 ID:Un9Q+jtZ.net
623:デフォルトの名無しさん
17/03/23 19:30:23.84 Un9Q+jtZ.net
バインディングとか最悪やな、何処がどうなっているのか把握できる人間が居なくなって
誰にもメンテできなるなる典型w
624:デフォルトの名無しさん
17/03/23 19:32:40.10 Ei+8urX3.net
>>583
> GUIライブラリからアプリケーションをコールバックしたりと、
これってあるか？ピンとこない。
そもそも、UIってロックする必要があるか？
現状、UIスレッドとタスクスレッドは別で、結果的にプログレスバー等の更新にはinvokeを使うしかない。
これがウザイから「直に書き込みさせてくれ」というのが俺の希望。
そもそも、排他的な実装をしなければならない理由がないだろ。
プログレスバーなんて普通は共有しないし、
してたらしてたで「どちらの内容が表示されてもいい」が仕様になるのだから、
レーシングしたところで問題ない。
結果、リクエストがあったらただ更新すればいいだけ、それを表示すればいいだけ、で終わりじゃないか？
ファイルみたいにロックありきの物ではないと思うんだが。
625:デフォルトの名無しさん
17/03/23 19:35:54.46 g/kXmQSp.net
マルチスレッドアクセス可能なGUI採用してるシステムなんてあったっけ
UIスレッドモデルが遺産だというのなら
新しいシステム(Windowsに限らんぞ)ほど「そうなってはいない」はずだが
実際は最近のOS(やはりWindowsに限らない)でもUIスレッドモデルだ
何故だろうなあ
下手の考えなんぞ大抵は
「先人が思いついたけどあえてやらなかった」か「すでに失敗した」か
626:デフォルトの名無しさん
17/03/23 19:36:15.02 Un9Q+jtZ.net
Haskellみたいに極度に小さい記述で複雑なシステムが組めるのは確かに凄いんだよ
あれはマジ使える、ただし誰にでも使えるものでは無い。
こういう物は、チーム作業には向かない。
少人数で高度なプログラミングをするのには向いているがね。
で、C#はHaskellみたいなアプリケーションを作るために開発されたものなのかというと、それは違う。
誰でも使えるBasicの延長線上のものだ。
TaskもWPFもHaskellみたいな超絶技巧を目指しているだな、そんなものは要求されていないのに。
627:デフォルトの名無しさん
17/03/23 19:37:49.41 Ei+8urX3.net
>>595
あー、WPFのバインディングはこれを目指していたのか。
なるほど俺の要求だけならこれでいいわ。
628:デフォルトの名無しさん
17/03/23 19:39:47.03 FkdET+B0.net
不思議だな
新しい技術のおかげでプログラミングはますます簡単になってるのに
まるで難しくなったような意見が出てくる
629:デフォルトの名無しさん
17/03/23 19:40:57.33 Un9Q+jtZ.net
結局ね、マイクロソフトの技術者はコンセプトという物が理解できないバカの集団と化してしまったんだよ。
多分、社内政治とスタンドプレーの果てにこうなったんだろうなと。
だから、マイクロソフトは象牙の塔。
勉強しまくっているが自分のやっている事しか見えていない奴が音頭を取り始めてしまっている。
630:デフォルトの名無しさん
17/03/23 19:46:09.55 J2eFkRx5.net
ほーん、で？いちいち同意求めんなカス
知恵袋で恋愛相談してるクソアマかテメー
631:デフォルトの名無しさん
17/03/23 19:57:59.50 HovpjxiM.net
>>589
> UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
一致してない時に再計算をする必要があるからその計算が軽い時に有効な方法
ちなみにバージョン管理システムでは他の人が変更してるからやり直せって言ったら使い物にならないのでいわゆるマージ処理を行うのでちょっと違う
632:デフォルトの名無しさん
17/03/23 20:26:39.42 HovpjxiM.net
>>598
GUI 組んだことないのか？
イベントってフレームワークからのアプリケーションの呼び出しだぞ
あとロックするのは GUI のフレームワークじゃなくてア�
633:vリケーションの方 マルチスレッド化したフレームワークだとイベントっていつ発生するかわからないのでお前みたいなよくわかってない奴が組むとデッドロックを引き起こしたりしやすいって話
634:デフォルトの名無しさん
17/03/23 20:27:34.06 99dRkoLd.net
>>601
但しコレクションに関してはBindingOperations・・・のおまじないが必要だ
635:デフォルトの名無しさん
17/03/23 20:48:03.89 Ei+8urX3.net
>>606
今時GUIしかやらんだろ。
が、まあこっちの認識がずれていたのは分かった。
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
前者が「プログレスバーの更新」で、
後者が「 XXX.click += YYYY;」か。
確かに双方向だ。
で、ロックは必要か？
プログレスバーの更新なんて、ロックする必要ないだろ。
他もそうだと思うが。
636:デフォルトの名無しさん
17/03/23 20:49:29.54 30c+rZIc.net
>>606
具体的な最大の問題は、マルチスレッドアクセスを許容するとUIスレッド上で排他処理をしなきゃいけないことなんだよな
UIスレッドは多種多様なタスクによってタイトに使い回されるので、それをブロックすることは容易にデッドロックを引き起こす
UIスレッド上で別の処理Xが終わるのを待ってたら、XもUIスレッド上で呼び出される処理で
いつまでもXが呼ばれなくなりデッドロック、というのはよくあるパターン
637:デフォルトの名無しさん
17/03/23 20:55:57.96 30c+rZIc.net
>>608
そのプログレスバーの更新一つとっても中でどれだけ複雑なことをやっているかは君にも想像できるだろ?
君がロックしてるつもりがなくてもプログレスバーの更新処理を呼び出せば内部で当然ロックがかかる
638:デフォルトの名無しさん
17/03/23 21:00:57.40 Ei+8urX3.net
>>609
普通に組んだらデッドロックはしなく無いか？例えば、
1. UI <- Task_thread_A で Aが止まる。
2. Task_thread_A <- Task_thread_B で Bが止まる、ここまではありがち。
3. Task_threadB <- UI ：これはねーよ。
UIスレッドがTaskスレッドを見てロックするという使い方は普通しないだろ。
639:デフォルトの名無しさん
17/03/23 21:14:48.29 Ei+8urX3.net
>>610
いや、ロックの必要はないだろ。
正確に言えば、外部からの明示的なロックが必要無いように作れば作れるだろ。
今そうなってないだけで。
要するにプログレスバーを UI, Task_thread_A, Task_thread_B の
どこからも更新出来るようにしたいとして、
全部、 progressBar.value = x; と書かせろ、と言いたいだけで。
内部的に細かくロックして、順に処理するのはCLRが勝手にすればいい。
その結果、それぞれのスレッドが微妙にロックするのも仕方ない。
ただ、循環ロックにならない限り、デッドロックにはならないだろ。
そして普通に書けば、循環ロックにはならないだろ。
640:デフォルトの名無しさん
17/03/23 21:17:21.47 5A+rvbXC.net
独りで仕方ないと思って存分に射精してろハゲ
641:デフォルトの名無しさん
17/03/23 21:24:07.98 NnBP2eXC.net
>>608
GUIしかやらない？どこの世界の話だよ
642:デフォルトの名無しさん
17/03/23 21:27:34.82 VjAjr2s9.net
>>589
アトミックなデータでない限り、読み出しでロックが不要は誤り。
更新中の中途半端なデータが読みだされたらどうすんの。
643:デフォルトの名無しさん
17/03/23 21:30:44.46 5A+rvbXC.net
生兵法はケガの元だな
毛がなくて良かったね～
644:デフォルトの名無しさん
17/03/23 21:32:55.65 HovpjxiM.net
>>608
> あとロックするのは GUI のフレームワークじゃなくてアプリケーションの方
の意味を理解してないのかよ...
そりゃ単純にプログレスバーに表示するぐらいなら問題は発生しないよ w
例えば複数の銀行口座の預金額を表示して振り込みを行うアプリケーションを作るとして
他の端末から入/出金があるのです定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
でないと額の不整合が起きるからな
このロックして時に振り込みボタンが押されたら当然こっちも振り込み元と振込先の口座をロックしないとダメだろ
でこのロックの順番がテレコになってたら簡単にデッドロックをするって訳
もちろんちゃんとロック順序を考えて組めばいいんだけどでかいシステムをよくわかってないドカタに組ま
645:せることを考えたらわざわざそんな危険な構造にする意味がないってこと 前にも書いたけどUIなので超高速で画面のあちこちが更新できても意味ないしな
646:デフォルトの名無しさん
17/03/23 21:33:06.10 0wLqn0eU.net
>>588
寝ぼけるのはいいかげんにしろ。
647:デフォルトの名無しさん
17/03/23 21:34:23.52 5A+rvbXC.net
3行以上はキチガイ
648:デフォルトの名無しさん
17/03/23 22:20:43.54 ncdnXTN/.net
>>617
> 定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
そういう糞UIでもつくれるけど、まともだったらやらないよ・・・
649:デフォルトの名無しさん
17/03/23 23:30:21.13 u0oYY3Ci.net
>>620
で、お前はどうやるんだい？
650:デフォルトの名無しさん
17/03/23 23:38:12.29 uQaoHdGv.net
普通は読みだす時はロックなんてしないよw
複数のデータの不整合が問題になる場合は微妙だけど、その場合でも
2回一致するまで読む方が低コスト
651:デフォルトの名無しさん
17/03/23 23:39:06.22 uQaoHdGv.net
っていうか、何でこんなマルチスレッドの初歩みたいな話になってるの？w
652:デフォルトの名無しさん
17/03/23 23:47:48.47 Ei+8urX3.net
てす
653:デフォルトの名無しさん
17/03/23 23:50:59.28 Ei+8urX3.net
>>617
ちげーよ。まあ結論としては、簡単に出来るけどC#はやらなかった、というだけだ。
そして俺はこの選択は間違いだったと見るね。
実装例としては以下。(C#の文法は知らないので真似てみた。適宜脳内修正よろしく）
//ここにコードを書いたのだが、403 Forbidden になるぜorz
mutexを使う場合、mutex確保中に他ロックを取りに行かなければデッドロックはしない。
或いはthread_IDを付けておいて、UIなら直接変更、その他ならinvokeにしてもいい。
いずれにしても、ユーザー側にはinvokeが見えなくなる（隠蔽される）
これの方が良かったと思うよ。いちいち混乱しなかった。
そちらの例は、2人のユーザ間でのデッドロックであって、
俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
なお、解法は、普通に「両方取れなかった場合は一旦全部リリースしてリトライ」でいい。
ただし今時はそれはDB任せで、ユーザ側でのロック管理なんてしない（はず）
654:デフォルトの名無しさん
17/03/23 23:52:19.70 FkdET+B0.net
スレ読み返すと細かいことはどうでもいいけどとにかくInvokeしたくないプロパティでアクセスさせろって暴れてる変な子が居るように読めるんだが
Invokeを適当なプロパティでラップしろで終わる話じゃないのこれ？
655:デフォルトの名無しさん
17/03/23 23:53:41.78 u0oYY3Ci.net
>>622
ケースバイケースだろ
そもそも >>617 は説明のためのサンプルだから不満なら両方書き込みのケースを考えればいいだけ
>>623
マルチスレッドGUIフレームワークに夢見てる奴がいるからでしょ w
656:デフォルトの名無しさん
17/03/23 23:54:44.80 Ei+8urX3.net
>>626
その通りだ。そしてそのコードを貼ろうとしている。
つか、貼らなくても分かるんならもういいね。
657:デフォルトの名無しさん
17/03/23 23:57:20.64 u0oYY3Ci.net
>>625
> 俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
そんなことを言ってるのお前だけ
>>583 をちゃんと読み返せよ
658:デフォルトの名無しさん
17/03/24 00:00:02.01 Lq7k+m1v.net
>>622
そんな力業してないでリーダー/ライターロック使いなよ。
比較のループとかデータ量次第ではCPUパワーの無駄遣いだろ。
659:デフォルトの名無しさん
17/03/24 00:07:18.67 P/PrHj1p.net
既製品に文句があるなら自分で作ってgithub
これができないプログラマはいつまでも三流のまま
コードを書き使ってもらい持論を証明するんだよ
660:デフォルトの名無しさん
17/03/24 00:13:35.16 OAgok+ci.net
Windows Formsの場合は、単純にFormがActiveXコンテナになり得るから、
アパートメントの制限に対応するために用意された、実装上の都合による物だよ
おそらく、ロックの問題ではなく
リソースリークを根本的に解決する方法がないから用意された手続きなんだよ。
ラップして
661:解決できると思うなら、それで良いんじゃないか
662:デフォルトの名無しさん
17/03/24 00:14:57.73 gW3AbLz/.net
だからUIスレッドが気になるなら、wpfでMVVMやれば解決でしょうに
663:デフォルトの名無しさん
17/03/24 00:38:36.13 9w5lj4S/.net
UWPで非同期メソッドとかTask使ってるけどすごい不毛。
非同期メソッドの完了を基本的にはawaitで待つから
非同期メソッドを複数回実行するような場合だと
全部同期呼び出しにして全部まとめてTask.Runしたい。
664:デフォルトの名無しさん
17/03/24 00:50:30.06 RtKD05ZR.net
>>630
俺は622じゃないけど。
従来型のロック機構だとコストが高すぎる場合もあるんだよ。
俺は詳しくないけど、多分Erlangとかの世界で。
mutex等は共有メモリへの書き込みが生じるから実はかなり重い。
665:デフォルトの名無しさん
17/03/24 02:13:48.63 5bMFJR3b.net
馬鹿にマルチスレッド。
666:デフォルトの名無しさん
17/03/24 02:33:18.25 99176uAd.net
結局少しでも重たい処理は全部ワーカーにしなけりゃならないから
UI弄る時だけInvokeした方が見通しすっきりするんだよねw
async/awaitとか使うよりは
ここがUIスレッドですってはっきりわかる。
667:デフォルトの名無しさん
17/03/24 02:44:50.15 7cONiVN5.net
ここはまだWinFormsの時代かｗ
668:デフォルトの名無しさん
17/03/24 02:50:50.13 99176uAd.net
WPF？誰が使うか
そんなもんが必要なモバイルなら普通にJavaScriptにWebアプリで行くわって感じだねw
669:デフォルトの名無しさん
17/03/24 03:11:50.24 m/Lurhmo.net
>>612
progressBar.Value+=1
としたときに
1.読み込み
2.加算して書き込み
の処理が必要とすると、1と2の間に別スレッドが書き換えを行うことで結果が矛盾する
Interlocked命令を使えばそれは防げるけど、MaxValueを超えないかとかの判定が入るので結局ロックが必要
この程度ならまだしも、裏でWin32やCOMを叩いてるコントロールはさらにややこしい
670:デフォルトの名無しさん
17/03/24 03:44:24.59 5bMFJR3b.net
レベル低すぎて引くわ C#、LINQ、WPFが高速とか言ってたおれ最先端君が戻ってきたのか？
671:デフォルトの名無しさん
17/03/24 06:28:32.59 Cpc8yNoh.net
高速(で書ける)
672:デフォルトの名無しさん
17/03/24 07:23:36.10 vGZXBTd1.net
高速で壊れるの間違いだろ
馬鹿はphp書いてろ
673:デフォルトの名無しさん
17/03/24 07:56:00.46 P/PrHj1p.net
>>640
壊れても遅くてもいいからとにかくプロパティで書きたいというのが要件
674:デフォルトの名無しさん
17/03/24 08:24:47.57 gW3AbLz/.net
データの保証がないコントロールなど、標準品ではありえないから
頑張って作ってくれとしか言いようがないな
675:デフォルトの名無しさん
17/03/24 12:55:58.77 99176uAd.net
>>645
横だけれど、そもそも問題としてValueをインクリメントする事自体が余り良くない考え方かもね。それは表示と処理が分離できていないから。
カウント処理のカウンターはUIがもっているべきじゃない。
別途カウンターを作って、結果だけをUIに代入すべきだ。
このように設計されているなら、破損無視で書き込んでもうまく動作するだろうと思う。
問題は、それをすべての人に要求するのは難しい、自分の忙しくなったらきちんとせずにインクリメントしてるしなw
という事なんだな。
676:デフォルトの名無しさん
17/03/24 15:14:34.51 suDsBIm1.net
やっとまともなやつ来た
677:デフォルトの名無しさん
17/03/24 16:13:38.13 m/Lurhmo.net
>>646
今もそうなってるじゃん
ProgressBarクラスがカウンターを持ってて、ネイティブのmsctls_progress32にメッセージを送って表示を更新してる
ぜひスレッドセーフに再実装してみてくれ
678:デフォルトの名無しさん
17/03/24 18:30:43.13 kZHdS/d5.net
>>646
> カウント処理のカウンターはUIがもっているべきじゃない。
そんな低レベルな話をしてるのは ID:Ei+8urX3 だけだから、お前らもうでてくるな
679:デフォルトの名無しさん
17/03/24 19:42:33.91 RtKD05ZR.net
>>640
> 結局ロックが必要
いや、要らん。正確には、要らない組み方はある。
アトミックはデータを構造体にして参照を持つことで解決出来る。(一発ライト）
レーシングはインミュータブルとCASで解決出来る。x86ならCMPXCHG命令。
具体的には以下。
1. まず有効な値かどうかを先に判定する。（これは今も先にやっているはず）
2. 書き換える場合、元データのポインタをローカルにまず確保する。
3. 上記旧ポインタから参照して、書き込むデータを
new ProgressBarData() で新しく作る。（インミュータブル）
4. 本体のポインタをCAS命令(LOCK付き）で差し替える。
5. 失敗した場合は3からリトライする。（CAS命令の結果に最新ポインタが入っている）
この方法だとメモリを余分に食うけど、ロックは要らなくなる。
(なおErlangは共有メモリ無しで全て通信という別解決方法だった）
いずれにしても、やりようはあるんだよ。どこにコストを掛けるかという話で。
そもそもGUIなんてレーシングしても問題ないようにも組めるし。
(ProgressBar.value += なんて要らない。 = だけでも組める。>>646に同意)
その上で、invokeなんてユーザーに見せる必要あったのか？というのが疑問。
.NETはVC++でも使うから少しでも速い方がいいという需要もあるのかもしれんが、
C#のノリならここは隠蔽して欲しいところでしょ。GUIなんて極限まで速い意味はないし。
ラップしてもいいし、上記のようにロックフリーにしてもいい。
(もちろんユーザがやってもいいんだが、そういう言語じゃないでしょ）
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(ja.wikipedia.org)
つかいつからお前らこんなに馬鹿になったんだ？ふらっとから混ざったのか？
ロックの設計の仕方を知らないのはお前ら全員じゃねーかよ。
680:デフォルトの名無しさん
17/03/24 19:51:21.19 9LJ2CaVF.net
>>650
なーんかしょうもない話を延々続けて頭悪そうだけど、
特に理由がない限りわざわざスレッドセーフに作らないのはGUIに限らんって何度言えばわかるの？
馬鹿なのかほんと
681:デフォルトの名無しさん
17/03/24 19:54:06.25 HsxCjAja.net
>>650
2と3もロックされなければ既に破棄され別の領域として
再利用された誤った情報を読み出す可能性があるだろ
682:デフォルトの名無しさん
17/03/24 19:54:24.48 9VMQOfeX.net
MSにとっての実装コストの問題でもあるしな
MSが苦労するのはいいとしても、その結果激増したバグに悩まされるのはお前らだぞ
683:デフォルトの名無しさん
17/03/24 20:07:48.70 RtKD05ZR.net
>>651
お前がinvokeをウザイと思わなければそれでいい。
俺はinvokeをウザイと思うからMSが隠蔽しとけ、と思う。
多分後者の方が多いだろ、この件に関しては。
>>652
ついにC#がGC言語だと知らない奴も出てきたか、、、
>>653
MSはこの程度ならきっちり実装出来るよ。
というかMSって比較的まともだと思うぞ。
684:デフォルトの名無しさん
17/03/24 20:09:50.64 UKoqSEXl.net
BeginInvokeはどうするの？
685:デフォルトの名無しさん
17/03/24 20:15:53.11 RtKD05ZR.net
というかここでも単発は池沼なんだな。
いちいち言ってることがアレだし。
686:デフォルトの名無しさん
17/03/24 20:24:26.17 RtKD05ZR.net
つかまあ、百歩譲って他のコントロールならいいよ。
ただ、ProgressBarなんてどう考えてもタスクスレッドから書き換えられるのが仕様だろ。
(むしろUIスレッドから書き換えることがない)
それをいちいちinvokeはねーだろ。
せめてProgressBarだけでも対応しとけよと思うだろ普通。
687:デフォルトの名無しさん
17/03/24 20:27:59.45 9LJ2CaVF.net
>>656
アレなのはお前だよ馬鹿...
しかも重症のな。
何度も言うけど、こんなのはweb上にあるようなマルチスレッドの入門記事レベルの話だ。
そもそもスレッドセーフってどういうことなのかすら理解してないし、自分でそういうコードを書いたこともないだろお前。
しかし、
688:こういう馬鹿に限って偉そうなのは何なのかね
689:デフォルトの名無しさん
17/03/24 20:32:42.95 RtKD05ZR.net
皆さん、今からスレッドセーフ大先生の講義が始まります。ご静聴下さい。
ではよろしく>>658
690:デフォルトの名無しさん
17/03/24 20:57:32.53 UKoqSEXl.net
＞せめてProgressBarだけでも対応しとけよと思うだろ普通。
ProgressBarを対応させたら○○も対応させろとか言い出す人が出ると思うでしょ普通
691:デフォルトの名無しさん
17/03/24 21:56:51.21 vGZXBTd1.net
馬鹿+偉そうときたから例外を握りつぶすニキだな
692:デフォルトの名無しさん
17/03/24 22:04:34.44 vGZXBTd1.net
ああでも今回はさすがにClickOnceは危険ニキを支持だな
＞MSならこの程度はきっちり実装出来る
ここが一番面白かった
693:デフォルトの名無しさん
17/03/24 22:13:22.45 RtKD05ZR.net
つまり、俺が言いたいのは、以下ね。
>>559 > invokeってフォームに限ってどうして必要なのですか？
老害： それがしきたり。
ゆとり池沼連呼リアン>>658： スレッドセーフ！スレッドセーフ！
俺： MSが馬鹿だから。
ゆとりって連呼リアン程度の知能しかないよなマジで。
そもそも俺の>>650は>>589（俺ではない）とほぼ同じ内容だぞ。
お前ら馬鹿が付いて来れてないから書き直しただけでね。
お前らが589を最初から理解していればもっとマシな議論だったろうさ。
694:デフォルトの名無しさん
17/03/24 22:24:18.31 9LJ2CaVF.net
だからスレッドセーフじゃないのはControlのメンバだけじゃないって言ってるのに懲りない奴だな
馬鹿なのはMSじゃなくてお前だっての馬鹿
695:デフォルトの名無しさん
17/03/24 22:36:30.53 9LJ2CaVF.net
Control「だけ」がメンバをUIスレッドからしか呼べないとか訳の分からん錯覚をしているのは、
Controlのメンバが非ユーザーコードからも呼ばれることを理解してないからだろうなたぶん
696:デフォルトの名無しさん
17/03/24 22:41:45.59 RtKD05ZR.net
スレッドセーフ君はやはり連呼リアンであったか、、、
お前がそう思うんなら(ry
697:デフォルトの名無しさん
17/03/24 22:42:26.38 9LJ2CaVF.net
馬鹿な上にネトウヨって人生終わってるな
698:デフォルトの名無しさん
17/03/25 01:12:27.10 66tFvNtY.net
>>657
こんなもんで余計なパフォーマンス食われるのも嫌な感じだしね
スレッド無視で叩きこめるならその方がありがたい物ではある。
インクリメント問題くらいならこっちで対処するわって感じですな。
699:デフォルトの名無しさん
17/03/25 01:17:38.46 66tFvNtY.net
ああ、そういえば高負荷バックグラウンドスレッドで
progreassBarの操作をasync/awaitでブチかましてスレッドプール爆発させてた新人いたな(笑)
凄い困ってたけど、きっと何が何だか分からなかったんだろうな。
700:デフォルトの名無しさん
17/03/25 01:39:16.42 O6oCv4KM.net
>>668
そもそもコードの設計論から言ってもワーカースレッドからUIを操作するなんてありえない。
UIに依存するモデルってどんな糞設計だよ。
モデルにSynchronizationContextとか持たせてUIスレッドに同期したイベントで通知させるのは
設計としてありだけど、直接コントロールをいじるとかありえん。
それも気に入らないならUI側が能動的にタイマーでも使ってモデル側を読めばいいだけ。
701:デフォルトの名無しさん
17/03/25 04:16:02.72 ++OH//Pd.net
VB上がりにモデルなんて概念ないからｗ
702:デフォルトの名無しさん
17/03/25 09:54:01.33 QDpQza6M.net
.NETの質問したいんですがここで大丈夫でしょうか？
とりあえずします。
PictureBoxのPaintイベントでImageプロパティを再設定する処理などをしてるんですが
どうもMessageBoxの挙動がおかしくなってます。
フォームより後ろに表示されてしまって操作不能になってます。
とりあえず通常のメッセージボックスの場合はパラメータを弄って強制的に全面に表示させてますが
困るがSaveFileDialogなどで上書き確認のメッセージボックスが表示された時です。
この場合も後ろに表示されてしまって操作できない
703:のでどうしようもないです。 これを回避する方法はどうやればよいんでしょうか？ Paintイベントの中身を消去すれば普通に表示されますが出来ればそのままでメッセージボックスも前面に表示させたいです。
704:デフォルトの名無しさん
17/03/25 09:57:11.64 iGx2aDuI.net
Paintイベント内の処理がおかしいんだろ
俺たちはエスパーじゃないんだから、まずそれがどんなコードか教えてくれよ
705:672
17/03/25 09:57:40.89 QDpQza6M.net
すいません。自己解決しました。
Paintイベントで毎回PictureBoxのImageプロパティを再設定してるのが原因でした
下記のように条件を入れてやるだけで回避できました。
if(pic.Image != img){
…
}
706:デフォルトの名無しさん
17/03/25 09:59:45.97 swqPfyBg.net
だと思った
707:デフォルトの名無しさん
17/03/25 10:45:00.80 omxknQTj.net
DataReaderを使って
while(await ReadAsync().ConfigureAwait(false)) {
...
}
って書いてるライブラリがあるんだけど
件数が多くなりそうなループでasync/awaitするとタスク生成とコンテキスト切り替えのオーバーヘッドで逆にパフォーマンス悪くなったりしないもんなの？
708:デフォルトの名無しさん
17/03/25 11:08:32.17 oe75j5bC.net
>>676
ReadAsync使う時点でそれらよりデータソース読み取りの方がコスト大と作者が判断しているんじゃないかね
MemoryStreamに対してReadAsyncとか使っているなら知らんけど
709:デフォルトの名無しさん
17/03/25 11:09:13.59 kGpqWpaU.net
>>676
そりゃ呼び出しのオーバーヘッドは増えるだろうけど、それが問題になるかどうかは別だ
パフォーマンスという言葉を安易に使うのはやめよう
君はバッチ処理をしてるのかオンライン処理をしてるのかストリーミング処理をしてるのか、
そのライブラリの方はどういう使われ方を想定してるのか、
処理の規模はどれくらいか
パフォーマンスってのは結果的に目的をどれだけうまく達成できたかであり、一面だけを見て判断できるものじゃない
710:デフォルトの名無しさん
17/03/25 11:11:43.78 2T3avjLL.net
パフォーマンスって何を指してるんだ
処理速度出すためにasync/await使うわけじゃないのは理解しているよな？
711:デフォルトの名無しさん
17/03/25 11:13:12.94 2T3avjLL.net
具体的に何を指すんだと問い詰めたい単語
パフォーマンス
スマート
712:デフォルトの名無しさん
17/03/25 12:12:06.97 AJzcpICN.net
話題が長引いても安心な匿名掲示板「Anontown」 [無断転載禁止]?2ch.net
ｽﾚﾘﾝｸ(tech板)
713:デフォルトの名無しさん
17/03/25 13:35:04.97 66tFvNtY.net
>>671
とりあえず動くもの作るからな、クリックして必要な事をかける構造になっている以上
次に起こる事は、必然的にスレッドプール爆発なんだわw
714:デフォルトの名無しさん
17/03/25 14:21:07.83 pA2Zx06R.net
馬鹿がプログラムを書かなければ解決
715:デフォルトの名無しさん
17/03/25 14:49:04.12 66tFvNtY.net
そういうヤツはHaskellでもやってろって話だよ
C#はそういう言語じゃない
716:デフォルトの名無しさん
17/03/25 15:02:20.11 OnvCww5G.net
勝手にそういう言語とか決めないで欲しいな
糞袋の観測範囲で
717:デフォルトの名無しさん
17/03/25 17:12:28.65 P4wL6N6L.net
webbrowserのdocumenttextでｈｔｍｌを文字列で直接埋め込みたいんですが
ローカルに設置したcssやjsファイルを読み込む方法がわかりません。
どこに配置してどのように読み込めば良いか
ご存じの方教えていただけますでしょうか？
どうぞよろしくお願いします。
718:デフォルトの名無しさん
17/03/25 18:18:23.98 gz8AHGhh.net
Data URIスキームで埋め込むとか
719:デフォルトの名無しさん
17/03/26 00:26:03.65 b1vqxh2T.net
HaskellといえばAI。つまりそういうこと。
720:デフォルトの名無しさん
17/03/26 11:09:36.56 WUrKAJma.net
こんな感じか？
URLﾘﾝｸ(livedoor.blogimg.jp)
721:ymatome/imgs/7/6/76ec3c1e.jpg
722:デフォルトの名無しさん
17/03/26 12:41:56.97 Uwt+/Suh.net
>>670-671
釣りか？マジで言ってるのなら
お前ら別の意味でのスタティックおじさんになってるぞ。
まあC#erなんてそんなもんだと今回思い知ったが。
723:デフォルトの名無しさん
17/03/26 13:20:23.73 x9SVAeuT.net
progressbarなど、多くても１００回程度書き換えれば充分なわけで
たかが１００回のUIスレッド切り替えでオーバーヘッドとか笑っちまうな
スレッドを無視するより書き換え回数減らしたほうが余程生産的だし簡単だ
724:デフォルトの名無しさん
17/03/26 13:20:26.49 hVl7ZVni.net
>>690
そもそも今時Windowsのデスクトップアプリなんか作ってる時点で
スタティックおじさんであることを自覚したほうがいいよ
725:デフォルトの名無しさん
17/03/26 13:24:42.49 TjDGXANh.net
暴論w
726:デフォルトの名無しさん
17/03/26 13:28:02.28 WQ8v1gdY.net
みんなコード書くよりレッテル貼りの方が得意なんだな
727:デフォルトの名無しさん
17/03/26 13:48:27.23 7xcWRiGy.net
プログレスバーはカウントアップが面倒なのかいつからかグルグルするモードがついたね
ハングアップしてないかわかればまぁいいんでそればかりつかってる
728:デフォルトの名無しさん
17/03/26 13:59:10.19 TjDGXANh.net
いつ終わるか分からない処理もあるから。
729:デフォルトの名無しさん
17/03/26 14:02:35.77 Lixhnbpu.net
>>695
それ追加されたの.Net2.0だから10年以上前だよ
730:デフォルトの名無しさん
17/03/26 14:03:21.73 xbLciI4B.net
鬱陶しいから来週まで続けるなよ
でないとこのスレ埋め立てるからな
731:デフォルトの名無しさん
17/03/26 14:13:37.56 Lixhnbpu.net
4月1日までか…長いな
732:デフォルトの名無しさん
17/03/26 14:19:29.01 Uwt+/Suh.net
つかお前ら落ち着けw
俺は>>650だよ。そして>>640含むお前ら大多数よりは賢いことはもう示したろ。
で、>>670-671も同様にアホっぽく見える。
しかしマジでそう思っているのなら、それを示せば多少は教えてやるよ、ということだ。
何か最近、煽ったりカニンガムの法則を試しているような奴も多いんでね。
それに付き合わされるのはウザイ。
俺の意見は ID:Un9Q+jtZ とは完全には一致はしないが、
6割くらいは一致するし、彼が何を言いたいのかは分かる。
既に言ったとおり、650も>>589の代弁に近い訳でね。
お前らは>>597(重ねて言うが俺ではない）の意味を理解出来ていないように見える。
そこでお題を出してやる。
これをお前ら流の「美しい実装」をする方法を述べてみろ。
駄目出ししてやるよ。
フーリエ変換をする関数 calc_FFT があって、
計算に時間がかかるので、プログレスバーに進捗状況を表示したい。
参加する人はどうぞ。
733:デフォルトの名無しさん
17/03/26 14:24:02.60 13fTqv5I.net
>>700
まだやる気かよ。
だからねえ、そういうのは>>670に書いた2つのやり方のどちらかを選択するのが普通。
どんな方法論を取るにしろ、モデル側から直接UI部品をいじるとかありえない。
依存方向は一方通行にするなんて基本中の基本だろ
734:デフォルトの名無しさん
17/03/26 14:32:06.72 13fTqv5I.net
この元の話題、つまりUI部品のメンバーがUIスレッドからしかアクセスできないように
なっているのは不合理かどうかって話も、はっきりいって問題提起した奴が何も分かってない馬鹿なだけ。
こういう仕様は十分に合理的。
735:デフォルトの名無しさん
17/03/26 14:55:35.58 V5FfYo93.net
だからVB上がりにモデルなんて概念はないって言ってんだろが
通じない話を繰り返すな
壊れて向きが変わらなくなったチョロQかテメー
736:デフォルトの名無しさん
17/03/26 15:00:04.71 7VPGG3Vy.net
モデル概念�
737:mらないおじさんや初心者以前に エキスパートからしてみてもC#を使いたい動機は素早く手軽に組みたいという動機にあるからね。 時間をかけてガチガチにやらないかぎり上手くいかないとか、それは勘弁願い下げたよな。
738:デフォルトの名無しさん
17/03/26 15:09:11.18 N/oWszN2.net
うぇーゴミ虫の狭い観測範囲で勝手にC#ユーザーの動機を定めちゃう？
いくら寛容な人間様でも下等生物と一緒にされるんでは不愉快ですわ
739:デフォルトの名無しさん
17/03/26 15:14:26.60 7VPGG3Vy.net
お気に召さなければC++でも使ってみたらどうよ？
templateメタプログラミングならなんでもお望みの書き方でできるよ。
740:デフォルトの名無しさん
17/03/26 15:37:28.26 Uwt+/Suh.net
ちなみに、回答は後日ね。
こういうのは急いで出来る必要はないから、じっくり考えてみてよ。
当たり前だが俺は>>670-671よりもマシな解決方法を持っている（つもり）
>>701
採点結果： スタティックゆとり乙
君はどういう依存が悪いのかを理解出来ていない。
そしておそらくUIはスタティックだと信じている。
ただしMSも同様に馬鹿だった。だからFormは糞なのも事実。
しかし世の中には他の実装方法もあるって事さ。
君達がロックフリーの世界を知らなかったようにね。
ヒントとしては、
> どちらかを選択する
ここが間違っている。
何通りも用意するとか、ラップして変換するとかは、明らかに無駄だよね。
741:デフォルトの名無しさん
17/03/26 15:46:45.12 bdiJ1zQR.net
>壊れて向きが変わらなくなったチョロQかテメー
斬新な煽り方だなw
742:デフォルトの名無しさん
17/03/26 16:30:36.77 E6fNHh8L.net
ネトウヨとかもそうだけど、頭悪い奴に限って、
「この俺だけが世の中の真実に覚醒した！！！この世は嘘と欺瞞にまみれていて（笑）
俺以外の連中は馬鹿ばかりだ！！！」
ってなるのは何なのかね。
まあ2chにはこういう単細胞で自分を客観的に見られない奴いっぱいいるけど、
>>707みたいにそういうタイプはプログラマとか知的な仕事についてはいけない人だよな本来
743:デフォルトの名無しさん
17/03/26 16:33:32.75 7VPGG3Vy.net
彼が相手している誰かさんの方がむしろヤバイという客観的印象ありなんですけどねw
744:デフォルトの名無しさん
17/03/26 17:00:26.56 nZrkbKSG.net
ロックフリーおじさんはスタティックおじさんを馬鹿にできんだろ
○○おじさんが馬鹿にされる本質は金のハンマー信仰にあるのだから
745:デフォルトの名無しさん
17/03/26 17:09:41.70 E6fNHh8L.net
銀の弾丸を求める者は少なくとも倒すべき「怪物」の存在には気が付いているが、
彼はそのレベルにすら達してないよたぶん。
背後にあるトレードオフに気が付かないから不条理でないものが不条理に見えてしまう
自分の馬鹿さ加減を自覚できないだけ
746:デフォルトの名無しさん
17/03/26 18:57:25.59 iTS+fWTZ.net
>>700
ダメ出しなんて要らん
どや顔で語りたいならぐうの音もでない実装を晒しやがれ
747:デフォルトの名無しさん
17/03/26 19:11:26.31 iZtP8D0n.net
初歩的な内容ですが。
RxのISchedulerインターフェースを実装したいのですが、ScheduleメソッドのDateTimeOffsetを引数にとるオーバーロードとTimeSpanを引数にとるオーバーロードって
どのように実装すればいいのですか。
本家Rx.NETのリポジトリにあるコードをいくつか見ましたが、
なんとなく、指定された時間の分だけ遅延させて
デリゲートをInvokeさせるというのは分かりましたが、この2つのオーバーロードの具体的な実装方法を文章で書いてあるところを教えてください。
あと、戻り値がIDisposableなんですけど、これはスケジュールの解除を行うDisposableでいいですよね。
748:デフォルトの名無しさん
17/03/26 20:02:08.99 YTmW3NMW.net
>>707
利根川さんきたーーーーw
749:デフォルトの名無しさん
17/03/26 20:06:43.37 Uwt+/Suh.net
>>713
俺は語りたいわけじゃない。
だから君の意見を尊重して、俺の答えは書かないことにするよ。
君らは一生馬鹿なままで過ごせばいい。
C#にとどまっている限り、回りもみんな馬鹿だから、ばれないで済むだろう。
ただ、知っている奴が見たら、お前らは本当に間抜けなことをしている。
だけど、そういうのは自分でいろいろ考えないと身につかないんだよ。
だから自助努力する奴に対してはサポートしてやろうとしただけ。
とはいえ、俺の案も他言語では普通に使われる手だから、探せば出てくるはず。
それは君たちで探すんだね。
俺はくだらない煽りには本当に辟易している。
そのエネルギーは正しくプラスの方向に使うべきだよ。
マイナス方向に使って煽るのではなくてね。
君は何がしたかったんだ？
俺の面目を潰したかったのなら、俺より素晴らしい実装を先に言ってしまえばよかっただろ？
或いは他の人から、もっと素晴らしい実装が出てきたら、君にも糧になっただろ？
そうやってプラスの方向にお互いに高めていくべきなんだよ。
それを、｢じゃあ教えてやらない｣と言われる話の振り方をしてしまうから、
ゆとりはゆとりのままなんだよ。
聞くは一時の恥、聞かぬは一生の恥、だよ。
こんな匿名のところですら面子を重視しているうちは一生ゆとりだよ。
750:デフォルトの名無しさん
17/03/26 20:09:36.55 XWnO8Cg2.net
めっちゃ早口で言ってそう
751:デフォルトの名無しさん
17/03/26 20:52:30.96 iTS+fWTZ.net
なぜかバカって無駄な長文書くんだよな
こういう奴が書くコードも推して知るべしなんだろうな w
752:デフォルトの名無しさん
17/03/26 21:11:54.02 DeCVSWGu.net
そういうのも馬鹿っぽいよ。中学生か。
問題なのは言ってることが正しいかどうか、それだけ。
長文かどうかなんてそれとまったく関係がない。
彼はトンチンカンな勘違いをしてるから馬鹿にされてるだけ。
753:デフォルトの名無しさん
17/03/27 00:01:17.74 rNkb8v7V.net
日本語理解できないアホ？
頓珍漢なこと書く奴ってたいてい長文だろって話だぞ
754:デフォルトの名無しさん
17/03/27 00:14:45.53 qUMQbQ0X.net
馬鹿な奴だ。
馬鹿の世界ではきっとすべての事柄が三行以内の短文で表現できることになってるんだろうね。
己の無学を語るに落ちてるな
755:デフォルトの名無しさん
17/03/27 00:18:01.70 rNkb8v7V.net
誰もまともなこと書く奴が長文ではないって言ってないんだが w
逆とか裏とかを理解してないのってプログラマーとして致命的じゃね？
756:デフォルトの名無しさん
17/03/27 00:19:42.90 wneB9bMR.net
じゃあ一行で。スレタイ読め。
757:デフォルトの名無しさん
17/03/27 04:02:24.71 UZsp8jX5.net
>>716
せっかくなので教えて欲しい
ちょっと考えたけど、やっぱりMaximumとMinimumがValueの変換中に変わるときとかが結構めんどくさい
あと、オーナードローや継承が安全にできることも必要か
プログレスバーのValueだけどかならともかく、コントロール全部をスレッドセーフにとかは非現実的なんじゃないか？
実際近年やってるところは少し調べた限り無いし
758:デフォルトの名無しさん
17/03/27 04:51:00.01 FSqhbRGK.net
>>714
誰も触れてくれなくて草
759:デフォルトの名無しさん
17/03/27 05:02:30.31 rNkb8v7V.net
>>723
>>700 に言えよ w
760:デフォルトの名無しさん
17/03/27 14:11:21.66 H4MLQPNT.net
>>725
まあ正直今時Rxかよwwwwww
と草生えるからな
保守案件かも知らんが御愁傷様だ
761:デフォルトの名無しさん
17/03/27 15:09:08.98 OggmZorO.net
そもそもRxって今は.NETの一部じゃなくてサード扱いだからな
知ってるのが当然みたいに言われても困る
.NET Fx以外の個別のライブラリについてはスレ違い
762:デフォルトの名無しさん
17/03/27 22:59:41.60 ty5ByWfa.net
>>690
スタティックおじさんって誰よ？
763:デフォルトの名無しさん
17/03/27 23:14:42.86 53TkDvRN.net
スタティックジジバンドのリーダーだよ
知らなかったのか
764:デフォルトの名無しさん
17/03/27 23:28:21.19 c1Kh3EUH.net
もう今ならスタティックの悪い使い方を知ってるほうがおじさんな気がする……
765:デフォルトの名無しさん
17/03/27 23:52:27.87 dYBhOZra.net
性的
766:デフォルトの名無しさん
17/03/28 07:20:39.72 1WRXezaS.net
>>712
不二痛のノンプログラミングツールの
販促で 銀の弾丸を求めて とか
書いてあったの思い出した
あんな大手企業がスゲー認識してるなと思った
767:デフォルトの名無しさん
17/03/28 08:08:28.90 W2JaqSVc.net
ラズパイでMVCのwebアプリって動かせますか？
768:デフォルトの名無しさん
17/03/28 16:32:12.10 WR7Bj+dr.net
Windowsがまともに動きゃ動くだろ
769:デフォルトの名無しさん
17/03/30 00:54:43.35 8DsEMtOy.net
.NET CoreならWindowsじゃなくても動くんじゃね
770:デフォルトの名無しさん
17/03/30 01:35:10.25 DtnWdi8P.net
ARMで動くのか？
771:デフォルトの名無しさん
17/03/30 01:58:32.69 Qg6ZUcGU.net
Formのコントロールのイベントに紐づけしたFormのメソッドって
Formが閉じられた後も紐づけしたままだとお漏らしになるんだっけ？
772:デフォルトの名無しさん
17/03/30 02:50:16.54 DVY8Bk9i.net
>>737
動くよ、ググってみ
773:デフォルトの名無しさん
17/03/30 06:49:49.86 U97Tvha+.net
>>738
ならない
774:デフォルトの名無しさん
17/03/31 09:35:08.92 YcsHI68o.net
UI AutomationでVB6で書かれたレガシーなアプリのUIテストをしたいのですが、
操作したいコントロールの多くに一意のAutomatinIDが割り当てられていません。多くのコントロールのIDが1や2になっています。
一応、コントロールの順番が変わらないものと決め打ちして操作したいコントロールを特定することは可能なのですが、不便です。
もっとうまいやり方ってありますか？
後は表示位置を元に特定するくらいしか思いつかないのですが。
AutomationIDって、少なくともVB6では自分で設定できないのでしょうか。
一応このレガシーアプリのソースコードはあり、編集も可能なのですが、
AutomationIDというのを設定するところは見当たりません。
775:デフォルトの名無しさん
17/03/31 14:28:02.89 gIiQslt6.net
スレチ
776:デフォルトの名無しさん
17/03/31 19:34:04.77 BtloYTx6.net
ASP.NET MVCなんですが
DBに処理対象データがあるか確認
__ある場合:メッセージボックス(*件処理します。処理を続けますか？)
____はいの場合:データ更新処理
____いいえの場合:なにもしない
__ない場合:メッセージボックス(データがありません)
こういう処理を非同期リクエストを使わずに実装したいのですがどうすればいいでしょうか
入力フォームの内容もクリアされないようにしたいです
777:デフォルトの名無しさん
17/03/31 19:36:51.55 kI20EOUu.net
簡単だよ
778:デフォルトの名無しさん
17/03/31 20:45:16.64 BtloYTx6.net
>>744
教えてください
お願いします！
779:デフォルトの名無しさん
17/03/31 21:59:00.75 wAJQEnGm.net
なぜそんなことを他人に聞かないとわからないのかわからない。
780:デフォルトの名無しさん
17/03/31 22:08:53.88 PPRsLJ2Y.net
>>740
遅くなったけどありがとう
やっぱりそうか
781:デフォルトの名無しさん
17/03/31 22:10:11.37 9w4qNkVe.net
>>743
正直おまえキモイ
782:デフォルトの名無しさん
17/03/31 22:38:20.66 BKtRT3pJ.net
>>743
フォームの入力内容を書き戻すのに加えて、確認中であることを示す値を入れたhiddenフィールドと
$(function() { if (confirm(msg)) $("#form").submit(); });
みたいなスタートアップのスクリプトを仕込んで返せばいいんじゃないの
俺ならこんな汚物を出してきたら差し戻してAJAXで書き直させるけど
783:デフォルトの名無しさん
17/04/01 19:08:34.68 iJwskPQ3.net
while(true)
{
Console.Out.WriteLine("氏ね");
}
784:デフォルトの名無しさん
17/04/01 19:15:59.90 4r7Zvrb2.net
標準出力とか久々に見たわ
785:デフォルトの名無しさん
17/04/03 13:09:41.47 sZC7W3vJ.net
aspでviewだけをデザイナーに触らせたいんだけどどうすればいいの？
view以外（controllerとか）のソースを弄られたくないし見せたくもない
786:デフォルトの名無しさん
17/04/03 13:48:10.33 YcnJ2dMt.net
フォルダにアクセス権限でも付けとけや
スレ違い
787:デフォルトの名無しさん
17/04/03 14:12:13.73 sZC7W3vJ.net
こういうプロジェクトの共有（共同開発）は出来ないのですか？
788:デフォルトの名無しさん
17/04/03 14:18:51.99 G0J69e58.net
普通にできるが
789:デフォルトの名無しさん
17/04/03 15:39:57.58 sZC7W3vJ.net
普通にはできませんでした
790:デフォルトの名無しさん
17/04/03 19:12:16.74 zJguOVHN.net
>>752
それならREST APIで良いんじゃないか
RazorというかサーバーサイドのHTMLテンプレートはもう時代遅れだから思い切って捨ててしまえ
791:デフォルトの名無しさん
17/04/03 20:15:16.37 YcnJ2dMt.net
WebAPIを使った動的ページの開発ができる有能なデザイナならソース隠す必要ないだろ
むしろバックエンドも含めて全部そいつ一人に作らせた方が早いんじゃないか
792:デフォルトの名無しさん
17/04/03 20:38:02.81 DvppQH2R.net
わろたｗ
ビューのソースファイルだけ渡してデバッグできない状態で作らせるか
テンプレート関連の読み込み処理を自前にするしかないだろうな
もともとc#のtemplate使ってるから自前もわりと簡単だよ
793:デフォルトの名無しさん
17/04/03 22:10:44.51 zJguOVHN.net
冷静になって考えるとモックコントローラー作るだけだったわ
794:デフォルトの名無しさん
17/04/11 23:45:38.38 f9LqqWjR.net
バイト配列を並列で0クリアしようと思ったんだが、なんかほぼ変わらない
なにか間違ってるんだろうか？
public static void Main()
{
var methods = new Action<byte[]>[] { ArrayClear, ConcurrentClear };
for (var i = 0; i < 5; i++)
foreach (var method in methods)
{
var sw = Stopwatch.StartNew();
var buffer = new byte[64 * 1024 * 1024];
var random = new Random(0);
random.NextBytes(buffer);
method(buffer);
Console.WriteLine(method.GetMethodInfo().Name + ": " + sw.ElapsedMilliseconds);
}
}
private static void ArrayClear(byte[] buffer)
{ Array.Clear(buffer, 0, buffer.Length); }
private static void ConcurrentClear(byte[] buffer)
{ var t0 = Task.Run(() => Array.Clear(buffer, 0, buffer.Length / 2));
var t1 = Task.Run(() => Array.Clear(buffer, buffer.Length / 2, buffer.Length / 2));
Task.WaitAll(t0, t1); }
795:デフォルトの名無しさん
17/04/11 23:59:42.35 WDRtNXIn.net
>>761
なんでそんなクソ遠回りなことやってんのか知らんが
Taskでパラレルやるなら引数渡せ
796:デフォルトの名無しさん
17/04/12 00:22:54.01 QhQPiH2H.net
>>761
少し考え違いをしていると思う、並列処理は分割すればするだけ速くなるような代物じゃないし
粒度が細かすぎる、Taskは並列というより並行処理向け。同配列に対する処理などはCPUよりGPGPU向き
―だがそれより何より
797:、その計測された時間のほとんどは配列生成と乱数格納に費やした時間だ
798:デフォルトの名無しさん
17/04/12 00:52:15.63 PvBuykCK.net
毎度思うけど命令口調のバカ何なのかねw
799:761
17/04/12 02:52:03.74 E1U6B9R0.net
>>762
Parallel 使えってことかな？
>>763
あ、乱数生成の時間まで入れてたのか
でも乱数生成分入れないようにしても、どっちも同じような時間なのは変わらない
バイト配列キャッシュ作ってるんだけど、1GBぐらいの超巨大配列の初期化に
Task の生成や切り替えに数msec使っても、効果があると思ったんだ
分割すればするほど速くなるとは思ってないけど、
2分割程度なら速くなって当然と思ってるんだけど
800:デフォルトの名無しさん
17/04/12 03:38:43.21 QhQPiH2H.net
>>765
オーバーヘッドはご存じか、C#の場合はネイティブスレッドのそれほどでも無いだろうけど
ただ…結局この場合だと演算が皆無でメモリストアに割食って無意味って所だろうか（範囲が被るほど速い
801:デフォルトの名無しさん
17/04/12 06:57:20.84 uWep8obc.net
メモリーアクセスがボトルネックになってるだけじゃねーの？
802:デフォルトの名無しさん
17/04/12 07:57:27.76 A6XRqe5e.net
常識的に考えて、ボトルネックはNextBytesじゃないかなw
803:デフォルトの名無しさん
17/04/12 11:23:50.73 E1U6B9R0.net
>>766, 767
なるほどメモリアクセスかー
Taskの切り替えや待ち時間などのオーバーヘッドはご存知よ
書いたとおり、Taskをふたつ待つ程度のオーバーヘッドは数msec
NextBytesを計測から外し、1GBで0クリアを試してみたら、150msec前後かかった
レートだと 6700MB/sec ぐらい
実行環境は DDR3-1333 なんだけど、理論値 10667MB/sec
途中GC入ってたし、こんなもんかー
804:デフォルトの名無しさん
17/04/12 11:40:08.42 7YKbJJVc.net
byte（IntPtrじゃない）の配列のアクセスでそんなにHWの理論値に近い数字が
出る訳ないと思うよw
っていうか理論値はあくまで純粋にHWの転送能力であってCPUが介在する場合は
そんな値絶対出ないし
測定値、計算のどちらかまたは両方が間違いなく間違ってるw
805:デフォルトの名無しさん
17/04/12 12:09:07.27 E1U6B9R0.net
>> 770
Array.Clear() って .NET Core の内部ではポインタ幅(64bit？)で0クリアしてたよ
端っこはバイト単位での0クリアだったけど
// now write pointer sized pieces
size_t nPtrs = (endBytes - memBytes) / sizeof(PTR_PTR_VOID);
PTR_PTR_VOID memPtr = (PTR_PTR_VOID) memBytes;
for (size_t i = 0; i < nPtrs; i++)
*memPtr++ = 0;
GC発生しないようにバッファ使い回してみたら、7000～8000MB/sec くらいだった
理論値でるとも言ってないし、7～8割なら測定値、計算ともに妥当じゃない？
806:デフォルトの名無しさん
17/04/12 13:46:41.47 PeioJu3J.net
(byte配列ならnewした時点で既定値(則ち0)で埋められてるだろ、と言ったらあかんのか?)
807:デフォルトの名無しさん
17/04/12 14:05:20.61 OIzgc8H/.net
>>772
そりゃ実験のためのコードだからね
何のためにこんなこと試すのかわかんないけど
808:デフォルトの名無しさん
17/04/12 14:11:16.09 E1U6B9R0.net
>>772
LOH(約85000バイト以上のオブジェクト)は仮想メモリ空間のフラグメンテーションを発生させるので、
OutOfMemoryException が発生しやすくなる
巨大バッファをガンガン使いまわすアプリは OOMを防ぐため、
バッファをキャッシュして使いまわす必要があったのね
んで、キャッシュしてたバッファを使うときに高速�
809:ﾉ0クリアしたいってのが、今回の大元でした
810:デフォルトの名無しさん
17/04/12 18:50:16.39 IE9Tc5o9.net
配列のメモリークリアみたいな物はマルチスレッド化しても高速化しないだろうね
原理的にサイズが大きくても高速化しないと思われる
811:デフォルトの名無しさん
17/04/12 19:03:44.50 0XMPUeTg.net
15年前のシングルコアのプロセッサーが当たり前の時代ならその通りだけど、
今日的にはそんなこともないんじゃないの？
たとえ物理メモリーは排他的にしかアクセスできない制約があるにしろ、
並列化の効用がまったくないとも思えん
812:デフォルトの名無しさん
17/04/12 19:08:41.74 giyYheDf.net
むしろCPUキャッシュに左右されんじゃねのか
環境でばらつきまくって計測の意味もなさげ
813:デフォルトの名無しさん
17/04/12 19:51:51.86 QhQPiH2H.net
とりあえずWindowsマシン＠4.6.2で色々試してみたら
[SuppressUnmanagedCodeSecurity, DllImport("kernel32")]
extern static void ZeroMemory(byte[] Destination, IntPtr Length);
[SuppressUnmanagedCodeSecurity, DllImport("msvcrt", CallingConvention = CallingConvention.Cdecl)]
extern static void memset(byte[] _Dst, int _Val, IntPtr _Size);
とかした方が雀の涙ほど速かった、CILだと
ldarg.0
ldc.i4.0
ldelema uint8
ldc.i4.0
ldarg.0
ldlen
initblk
あたりで漸く同等、しかも64bitに限った話、32bitだとどれも誤差レベル
814:デフォルトの名無しさん
17/04/12 21:18:24.58 u533e0uw.net
>>776
ほとんどメモリーアクセスしかないのに高速化できるわけないだろ
815:デフォルトの名無しさん
17/04/12 21:45:31.51 0XMPUeTg.net
>>779
高級言語のコード上はそうでもCPUの実際の動作はそうじゃないよw
816:デフォルトの名無しさん
17/04/12 21:56:27.84 5KMe1hi6.net
どう動いてるんだ？
817:デフォルトの名無しさん
17/04/12 23:32:44.30 7AJloho+.net
>>780
はあ？
メモリーアクセス以外のどんな動作があるんだよ w
818:デフォルトの名無しさん
17/04/12 23:49:21.06 fn4L3E2o.net
仕組み判らないけどメモリをキャッシュしてる場合
同じキャッシュ単位内に同時に書き込みできるものなのか？
819:デフォルトの名無しさん
17/04/13 00:14:45.08 Vv6BlwOK.net
使うときに必要な分だけ0クリアじゃだめなんか?大量にバッファを0クリアする場面が思い付かん。
820:デフォルトの名無しさん
17/04/13 00:38:14.37 px7lD0L1.net
>>782
DMAでも使ってない限り、少なくともポインタのインクリメントとループの終了条件のチェックは入る
821:デフォルトの名無しさん
17/04/13 00:57:14.48 G9tlFT6D.net
>>785
ｘ86にはストリング命令というチートが有ってだな
822:デフォルトの名無しさん
17/04/13 01:07:16.95 px7lD0L1.net
あ、ポインタは自動インクリメント付きの命令が使えるかも
823:デフォルトの名無しさん
17/04/13 01:22:49.09 sVC5qkLg.net
>>784
つ GC
>>783
Core i7 2600 4Core Sandy Bridge とかだと、CPU-Z とかのツールで見てみると
L3 キャッシュまで搭載していて、
・L2 は 256KB が 4コア分
・L3 は 8MBひとつ
なので、L2間でコア間のキャッシュコヒーレンシ（一貫性）を解決してるはず
キャッシュライン(64Byte)ごとに他のコアで書き込みがあるかとかをチェックしてる
同時の書き込みもちゃんと検知されている
キャッシュラインで競合すると書き戻しとかが発生するので、
重ならないようにするのがいいらしい
824:デフォルトの名無しさん
17/04/13 01:23:52.75 DHabuNl5.net
そもそもrep stosb云々とか以前に、命令のクロックサイクルなんかより
メモリレイテンシがデカすぎて取るに足らないって事よ、コヒーレンシの実装にも左右されそうだし
1つのバカでかいバッファより、バッファ自体を分割したほうが良いんでないか
825:デフォルトの名無しさん
17/04/13 01:44:29.44 G9tlFT6D.net
スレッドをいくつ作ろうが、単純な０クリアだからキャッシュ内のメモリーを処理する速度がキャッシュとメモリーの転送速度より早くなり
CPUはキャッシュが満たされるのを待つ必要があるから頭打ちになるってことかね
826:デフォルトの名無しさん
17/04/13 03:28:18.29 NHsAQDrp.net
WinFormsはif文やっと覚えましたってレベルでも
有名なサイトのコピペで目的のもの作れたが
WPFはデリゲートや非同期を熟知してないと一歩も進めない感じ
コピペしたくても自由度が高く手法が多すぎて無理
827:デフォルトの名無しさん
17/04/13 05:44:30.50 FNNFGlTu.net
今のCPUなら1CPUでも、連続0書き込みなんかしたらメモリーの速度を圧倒してしまうからな
マルチスレッドなんかにしたら、そのオーバーヘッドが邪魔してかえって遅くなるだろう
828:デフォルトの名無しさん
17/04/13 06:14:59.28 wfOumNdE.net
CPUの実際の動作がさっぱりわからん
829:デフォルトの名無しさん
17/04/13 06:22:05.68 vvMMmk8r.net
気にしなくていい
830:デフォルトの名無しさん
17/04/13 06:53:09.50 DSZn496T.net
>>785
おっさんいつの知識で語ってるんだよ w
そんなもん主記憶への書き込みに比べたらゴミにしかならんぞ
831:デフォルトの名無しさん
17/04/13 07:19:52.20 FNNFGlTu.net
>>793
CPUというよりも、CPUとメモリーのスピード差が決定的すぎるんだよ
メモリーにアクセスするとCPU命令で数千命令程度の待ちが入る
余りに待ちが長いので、その間に色々計算ができるようにCPUには工夫が入っていたり
マルチCPUにして、別のCPUが計算している間に書き込んでしまえといった方面で創意工夫がされているんだ。
境界チェックくらいなら、書き込み待ち時間で十分にできるから他のCPUにまで影響を与えないようにして
書き込みスレッドは一本にして、他のCPUは別のメモリーアクセス以外の仕事ができるように開けておいた方がトータル良い結果を出すって事。
832:デフォルトの名無しさん
17/04/13 08:39:19.14 2TLG8dmE.net
どうでも良いが、メモリーに書き込まないスレッドとかありえないと思うんだ・・・
833:デフォルトの名無しさん
17/04/13 10:17:04.48 xhr4sxE5.net
本当に小規模な計算ら、レジスタだけで解決できるだろう
834:デフォルトの名無しさん
17/04/13 13:14:58.98 mVrmFNTT.net
C++ならともかくC#で気にする必要のあることなんだろうか
835:デフォルトの名無しさん
17/04/13 13:31:22.91 FNNFGlTu.net
>>799
知っていれば無意味な並列化とかしなくて済むだろ
そうすればソースも分かりやすくすっきりするし
0フィル処理なんて詰まらない処理なら、効果はてきめんだ。
836:デフォルトの名無しさん
17/04/13 13:43:29.67 xhr4sxE5.net
無意味な並列化にかかる工数と、無意味な並列化は逆効果ということを検証する工数
どちらがよりコストがかかるんだろうか。
837:デフォルトの名無しさん
17/04/13 13:49:55.01 FNNFGlTu.net
高速化目的で並列化しなきゃならない程の状況なら、検証はするだろ。
で、並列化するときにどういう方向性が効果的かってのを知っておくことは
コードを手早く書く上での基本テクニックだよ
無意味なコードは、そもそも書かないし試さないというショートカットができるからね。
将棋の名人でもすべての手を読んでいる訳じゃない、効果的な枝だけを深読みしているみたいなもんだ。
838:デフォルトの名無しさん
17/04/13 14:09:41.46 xhr4sxE5.net
並列化をしたくなるのは、代替がそういう状況に陥る前の段階での思いつきなんだよねたとえば今回の0フィルとか。
839:デフォルトの名無しさん
17/04/13 16:09:48.66 aK+zC0HQ.net
並列化の基本はいかに粒度を上げるかだよ
極端な話、プロセスを2つに増やして2倍速くなるならそれでいい
ミクロな視点で考えるのはほとんどのケースにおいて時間の無駄
840:デフォルトの名無しさん
17/04/13 16:28:44.49 FNNFGlTu.net
>>803
こういうのってコンピュータの仕組みが分かってしまえば、高速化手法として頭に浮かぶことすらないですから。
考えるまでもなく除外なんですよ、脊髄反射。
よく似た物にページングのチューンなんかがあるね。
並列化したら、ずっと仮想メモリにページアウトページインばっかりするようになってしまうのが見え見えのコードとかね。
こういうケースが見えて居る時にマクロ視点でプロセス増やして・・・と考えることは無いねw
841:デフォルトの名無しさん
17/04/13 18:05:14.12 sVC5qkLg.net
>>805
コンピュータの仕組みなんて常に変わっていくもの
脊髄反射で手法を除外するのはよくない
あと一レス目で指摘するならともかく、問題点が整理されてから
後出しで手法をダメ出しするのはカッコ悪い
842:デフォルトの名無しさん
17/04/13 18:18:41.10 xmE6C1ua.net
>>796
それってCPUの実際の動作じゃなくて単なる考え方だよね・・・
843:デフォルトの名無しさん
17/04/13 18:34:37.22 2TLG8dmE.net
と、言うより>>796は思いっきり出鱈目ですわ
境界チェック云々はマルチCPUじゃなくてパイプラインで解決されるからプログラミング要らずだし
844:デフォルトの名無しさん
17/04/13 19:49:41.71 woBc/tdN.net
>>79
> メモリーにアクセスするとCPU命令で数千命令程度の待ちが入る
今時のメモリー（主記憶）のレイテンシーって10ns以下だと思うが10nsで1,000命令も実行できるCPU教えてくれ
845:デフォルトの名無しさん
17/04/13 20:53:44.12 FNNFGlTu.net
>>808
まぁ、その手の事を指摘したつもりだけれどそう読んではくれないみたいだね。
あと、最近のはパイプライン以外にも命令の並べ替えやら入っているからw
ホコポコ無意味に返信している内容は、多分自演なんだろうけど、そろそろやめたら。
こういうのはゲーム作ったことあるような人間なら常識の範囲なので、考えるまでもないような話の類。
俺以外のヤツもたくさん指摘しているが、それだけ普通に知っている人は多い話なのだよ。
846:デフォルトの名無しさん
17/04/13 21:04:00.56 1tPgrneG.net
いつの時代のどのハードのゲームだよ
アセンブラのバイトコード気にするとか２０年前の話だろ
いっぽかたが計算してる間に他のCPUで書き込みするのは
同時にメモリに書き込もうとして競合するのを避けるためじゃないん
847:デフォルトの名無しさん
17/04/13 21:15:04.20 FNNFGlTu.net
しつこいねぇ
この手の話をゲーム屋が知ってるのは、何かの本で読んだとかではなくて
ソニーとか任天堂とかマイクロソフトとか今は逝ってしまっているセガとかハード屋が
セミナーで現在のハードの状況と止めた方が良いコードなんかのヒントとして教えてくれるからなんだよ。
その知識を持って、インテルの資料とかを読めば大体の事は分かるんよ。
もちろん素から勉強している人も居るだろうけどね。
今回の話はマシン語ではなく、最近のメモリー事情の話なんだよ。
連続アドレスの書き込みor読み出しには強いが、飛び飛びのアドレスにアクセスすると弱いダイナミックメモリー事情とかの話。
メモリフィルとか連続アドレスをアクセスしているのに、わざわざ壊すようなマルチスレッドはそういう点でも駄目なんだな。
決定的にはメモリーが遅いという点に尽きるが。
こんな風に駄目な理由に一つ以上のネタがあるんだよ、だからやるまでもないの。
848:デフォルトの名無しさん
17/04/13 21:29:31.37 1tPgrneG.net
ほんとに理解してるか？
パイプラインで境界チェックを解決って意味が分からん
どうやってんの
849:デフォルトの名無しさん
17/04/13 21:32:07.91 3oML3qao.net
そろそろ死ねよチンカス勢
これ以上口を聞くとスレを埋めるぞ
850:デフォルトの名無しさん
17/04/13 21:46:56.27 2TLG8dmE.net
>>813
パイプラインがRISC時代に進化して、レジスタが干渉しなければインストラクションを同時実行するようになったから
件の例だとメモリクリアと境界チェックを同時にヤるんだわ
だから一つのCPUは見かけ上メモリクリアを境界チェックの時間０で延々と実行する
コレを実行するのは一つのCPUだし、同時実行に人が介在すること
851:無いのでプログラマーは何もヤることはありません ホント>>796は酷い出鱈目ですわ
852:デフォルトの名無しさん
17/04/13 22:00:11.37 oixKZUzL.net
何を争ってるのかさっぱりわからんw
ただ昨日書いた>>776が間違ってることはよくわかった。
よく考えればこれ486の時代とかでも当たり前だw
すまんかった
853:デフォルトの名無しさん
17/04/13 22:00:58.20 FNNFGlTu.net
>>815
>境界チェックくらいなら、書き込み待ち時間で十分にできるから他のCPUにまで影響を与えないようにして
これがパイプラインやらディレイスロットに相当する話として描いたんだよ
計算時間隠ぺいはパイプラインだけじゃないからな、不正確になるだろ。
854:デフォルトの名無しさん
17/04/13 22:08:08.05 FNNFGlTu.net
ちなみに昨今のCPUは、機械語命令を別の内部用の命令に一旦変換することで互換を取っている
この変換で色々な隠ぺい処理がされる。
パイプラインの直接関与は無い。
855:デフォルトの名無しさん
17/04/13 22:55:07.48 UJp3daw4.net
そういうのはC++使いにやらせとけ
856:デフォルトの名無しさん
17/04/13 23:32:52.23 ZueE7S//.net
CPUの種類もいっぱいあるし実装すらmonoとかあるんだから考えても無駄だよ
ふつーにヤレ
857:デフォルトの名無しさん
17/04/13 23:35:00.21 8HEXXOrW.net
.NET 4.7でTupleも標準で使えるようになったと思ったら
Windows Server 2016でまだ使えない
858:デフォルトの名無しさん
17/04/13 23:51:42.17 qn5HP47l.net
>>821
4.7がまだインストールできないってこと？
859:デフォルトの名無しさん
17/04/14 00:17:56.85 SWEjH6Xz.net
>>788
GCってガベージコレクタか?
メモリを回収するときにゼロクリアする必要はないんじゃね。痕跡を残したくないとかなら分からないでもないが。。
860:デフォルトの名無しさん
17/04/14 07:19:22.25 KckXzUzz.net
>>822
4。7って自動で入るのか？
861:デフォルトの名無しさん
17/04/14 08:29:17.03 pJlkTYEJ.net
.NET Framework 4.7 is part of Windows 10 Creators Update. What about other Windows versions?
You can start using .NET Framework 4.7 today on Creators Update. It will be available on other Windows versions soon. .
NET Framework 4.7 will support the same Windows versions as .NET Framework 4.6.2. It is an in-place update.
Windows10だけらしい
862:デフォルトの名無しさん
17/04/14 19:41:38.09 zACr9/Dt.net
4.7なんて何に使う気なんだ
863:デフォルトの名無しさん
17/04/14 19:57:13.78 vwaM1ek4.net
NuGetで取ってこなくても最新の機能が使えるとか
ValueTupleとかValueTaskとか
自分も試しにアップデートしてみたがまだ使えないみたいだね
もうちょっと纏めてからアップデートしてくれた方がいいんだけど
アップデートが細かすぎる
864:デフォルトの名無しさん
17/04/14 20:03:25.72 znF0F+kk.net
>>826
何に使うのかは知らんけどtupleを使いたいんだろ
865:デフォルトの名無しさん
17/04/14 20:10:48.82 pJlkTYEJ.net
知っていると思うけど、VSインストーラ立ち上げて４．７を追加インストールします
Windows１０をCreatorsUpdateしてから処理したから、必須なのか不明ですが
多分それも必要です
866:デフォルトの名無しさん
17/04/14 20:19:05.97 bLw6Whqv.net
Tuple<T>ってC#4.0からあったと思ったがそれじゃなく?
867:デフォルトの名無しさん
17/04/15 02:12:01.30 aGMB9daN.net
>>830
それとは違う
868:デフォルトの名無しさん
17/04/15 10:12:37.06 iCdjVYwG.net
>>818
ペンティアム２を昨今のCPUって言う人初めて見たｗ
てか、それらはx86のRISC化なんだが、
RISCっても
869:のはパイプラインを高度に利用してトランジスタを増やさずに多重実行する技術だよ パイプラインの関与と言うか、要です
870:デフォルトの名無しさん
17/04/15 10:16:28.45 C33P0hB8.net
アセンブラできない奴はまともに最適化はできない。これだけ。
871:デフォルトの名無しさん
17/04/15 10:18:54.18 3qBkA9st.net
アセンブラとか老ガイジかな？
872:デフォルトの名無しさん
17/04/15 10:23:22.48 C33P0hB8.net
c#のデバッグでなんで機械語が表示できるようになってると思ってんだ？ 低脳馬鹿デジタルネイティブさん >>834
873:デフォルトの名無しさん
17/04/15 10:35:26.60 QicJR8ZP.net
ValueTupleって最初はワクワクしたけど使い所あんましないな
どういう時に使うんだこれ
874:デフォルトの名無しさん
17/04/15 10:36:36.36 qt9qpnGQ.net
うわあ
875:デフォルトの名無しさん
17/04/15 10:43:55.01 iCdjVYwG.net
>>836
ｏｕｔ 使って値を返しているやつを素直に書けるだろ
876:デフォルトの名無しさん
17/04/15 10:49:59.89 3WGNKYp+.net
>>832
まてまて、SIMDとパイプラインと並列処理は意味が違うぞ。
言いたいことはわかるけどなw
877:デフォルトの名無しさん
17/04/15 10:50:24.08 iCdjVYwG.net
>>835
C#のILをJITがマシン語に変換して、更にCPU内部でRISC形式の命令に変換
更に命令の順番を最適化して多重実行をするわけで、ILを見たところでどれが効率高いかなど判断するのは人間業じゃないな
せいぜいキャッシュサイズを意識する程度だろうが、２つのループを同時実行されることまで考慮したらどうすれば良いのやら・・・
878:デフォルトの名無しさん
17/04/15 10:57:05.83 iCdjVYwG.net
>>839
SIMDじゃなくて、通常のオペコードをRISC的な内部オペコードに変換するんだよ
で、１０段とか１５段に細分化されたパイプラインを使って、パイプラインに繋がった演算装置を
複数の実行ユニットが使いまわしをしてトランジスタ増やさずに見かけの同時実行数を５とかに増やす
まあ、それをどうやって実現しているのかさっぱり分からんけどな
879:あ
17/04/15 10:57:43.50 4VXj2s/u.net
>>840
どこが効率悪いかはわからんか？
あー、アンボクシングかかっとるわ、とか、
これのせいでストールしよるな、とか。
880:デフォルトの名無しさん
17/04/15 11:00:42.88 iCdjVYwG.net
>>842
デバッグに使うのは当然なんだが、通常のソースレベルの効率以上の情報をILから探し出すのは至難の業です
最終的な実行環境は俺を含めてハードの素人には手を出せない神の領域かと
881:デフォルトの名無しさん
17/04/15 11:34:57.52 QicJR8ZP.net
>>838
outはそもそも使わないし
TryXxx系はValueTupleよりout varの方がスマート
882:あ
17/04/15 11:39:27.67 4VXj2s/u.net
>>843
コーディング中はそりゃ、あんまりそこに固執すると目的地にたどり着きさえしなくなっちゃうもんな。
コンパイラが賢かったり、JITが地味に賢くなって要らない小技になったのも沢山あるし。
たまに見ると面白いよ。あ、これメモ化しちゃうんだ、とか。
883:デフォルトの名無しさん
17/04/15 11:39:28.67 UPL5S+RA.net
そうそう
pythonでやってたことをc#でもできるようになったものって
実際使ってみてもいまいちなんだよな
めんどくさいから欲しかった機能だけどc#流になるとそれ以上にめんどくさいしスマートじゃない
884:デフォルトの名無しさん
17/04/15 11:44:51.81 eeh5f4V4.net
>>832
ペン2には一言も言及してないのに勝手にそうするキチガイさんですか？ >>839 これも自演でしょ
多分10年以上も前からここで、板が白けきるまで偉そうな事いいながら荒らしまくっていた人なんでしょうけれど。
そろそろ死んでください。
885:デフォルトの名無しさん
17/04/15 11:49:23.70 iCdjVYwG.net
今回の拡張の中で
ref var a = hoge
886:(); と言う、参照戻り値ってのの使い方が難しいわ
887:デフォルトの名無しさん
17/04/15 11:51:55.21 iCdjVYwG.net
>>847
>、機械語命令を別の内部用の命令に一旦変換することで互換を取っている
コレはPen2とかK6辺りから始まりました
２０年前の技術ですね
888:デフォルトの名無しさん
17/04/15 11:52:06.28 mE+AhP/n.net
初心者です
C#はメモリ管理を気にしなくて良いと聞きました
本当でしょうか？
889:デフォルトの名無しさん
17/04/15 11:54:00.80 eeh5f4V4.net
たしかCore2以降は、VILW命令に変換していたと思った。
命令ストリームからVILW命令6スロット分に変換して
6命令ずつ同時実行する事で低クロックでも高速に動作とか。
x86系以外では、スーパースカラの採用も多いみたいだね。
890:デフォルトの名無しさん
17/04/15 11:55:39.30 P11oDSMM.net
本当だよ
2人くらい何か囀ってるように見えるけど、キチガイだから気にしてはいけないよ
891:デフォルトの名無しさん
17/04/15 12:00:32.47 3WGNKYp+.net
>>847
俺、死ぬんか?
892:デフォルトの名無しさん
17/04/15 13:12:21.09 7hkWD0i5.net
>>850
メモリ解放なんかは自動ってことになってるけど
メモリ確保やら初期化やらは気にしないとだめだし「メモリ管理」の内容による
893:デフォルトの名無しさん
17/04/15 13:18:16.99 GC6K0tB8.net
>>823
これ、まともに回答しようと思うとひどく大変なんだが……
823がGCの内部実装を把握しているうえでの指摘にも見えるし、
初心者の思いつきの質問にも見えるし……
初心者向け：
ヒープ確保したら0にクリアされてる
メモリを回収後、再利用されるまでに0クリアする必要があるってこと
把握してる人向け：
メモリコンパクション時にページングの機構使って0クリアしてるのかってことなら、
.NET Core のソースで確認しようと思ったけど
gc.cpp だけでも1.2MBあって挫折した
>>850
初心者のうちは気にしなくていいよ
894:デフォルトの名無しさん
17/04/15 13:43:04.38 5VFPMUgC.net
>>846
C#は式指向のシンタックスを目指してるから、あくまでステートメントに拘るPythonとはだいぶ方向性が違うよ
可能な限り全てのメソッドを式形式で定義する縛りでコーディングしてみたらいい
そうすればC#7の仕様の意図するところは簡単に理解できる
895:デフォルトの名無しさん
17/04/15 14:29:19.96 56TRC7nM.net
みんな詳しすぎ
頭いいんだな
896:デフォルトの名無しさん
17/04/15 14:40:07.25 3WGNKYp+.net
>>842
>>843
思ったけど、あのVTuneってそんな機能あるんかな？
897:デフォルトの名無しさん
17/04/15 15:19:31.88 A0YDVHHt.net
昔Excelを弄ってた時、Excelのオブジェクト解放したはずなのに
単体テストし終わってからタスクマネージャー見るとExcelが一杯残ってた(通称ゾンビ)。
シートやらブックやら解放してから最後にExcel本体解放してってやってたけど
今は一発で解放できるんだよね？
メモリ管理とか気にしないけど、こういうのは気になる。
898:デフォルトの名無しさん
17/04/15 15:29:43.17 8JN0d/j3.net
所謂アンマネージリソースを閉じてないとC#であってもゾンビ化することはたまにある
899:デフォルトの名無しさん
17/04/15 15:39:12.33 eeh5f4V4.net
>>859
Excelは無理だよ、細かくReleaseComObjectしなきゃ駄目だし、しても残る時は残る。
残ってしまう事を前提に組むしかない
900:デフォルトの名無しさん
17/04/15 15:41:12.30 aGMB9daN.net
>>861
しても残る時は残る、はし足りないだけでは。
901:デフォルトの名無しさん
17/04/15 15:43:39.01 eeh5f4V4.net
>>857
自分の書いた内容が正しいという流れになるまでしつこく続ける自演キチガイが一匹いるだけ。
もう相当昔から粘着しているからいい年だと思うんだが、よく生活できてるなって感じだな。
それ以外の人は普通だよ。
902:デフォルトの名無しさん
17/04/15 15:58:16.95 3WGNKYp+.net
ちなみに俺は違うからな
903:デフォルトの名無しさん
17/04/15 16:02:07.82 eeh5f4V4.net
自分が得意じゃないと思う領域は黙っておけ、そして誰か
904:詳しい人がレスするまで その質問を流すなキチガイ あと、自分の得意な領域に引き込もうと変な流れに作り替えるな。 掲示板が機能しなくなる どうせなら死ね とまあそんな所ですな
905:デフォルトの名無しさん
17/04/15 16:06:10.39 OxStzCoo.net
>>863
気づいてないみたいだけど、悪いけど君の態度も相当エキセントリックに見えるよww
少なくとも>>832は文脈的に妥当な反論をしているようにしか見えんけど、
「俺にたてつく奴はいつものキチガイ（って誰だよw）だ！！」って感じでかなり普通じゃない。
余計なお世話だろうけど、いい歳こいてるんだろうからもうちょっと自分を客観的かつ批判的に
見ることを覚えた方がいいんじゃないんだろうか。
906:デフォルトの名無しさん
17/04/15 16:07:40.04 lvAT8XK9.net
>>859
> 昔Excelを弄ってた時、Excelのオブジェクト解放したはずなのに
> 単体テストし終わってからタスクマネージャー見るとExcelが一杯残ってた(通称ゾンビ)。
ちゃんと ReleaseComObject(comObject) 呼んでないだけだろ
なんで IDisposable にして Dispose で解放するようにしなかったのか謎
907:デフォルトの名無しさん
17/04/15 16:09:12.98 eeh5f4V4.net
駄目だな、このキチガイ・・・
はよ死ね
908:デフォルトの名無しさん
17/04/15 16:13:19.25 C33P0hB8.net
デストラクタの動作タイミングが制御できない時点で逆にいろいろ管理できなくなってトラブルの元になってる。
結局のところ欠陥言語なのだ。
909:デフォルトの名無しさん
17/04/15 16:16:13.49 OxStzCoo.net
>>867
根拠があるのかと言われれば正直ないけど、ぶっちゃけ全部のオブジェクトを
いちいちReleaseComObject呼ぶなんてやってられないし、やらなくてもそれで
「ゾンビ」が残ることはないようだから、必要ないんじゃないのかな。
そんなことよりプロパティが返すオブジェクトをメソッドチェーン的に使わない（面倒でもいちいち変数に
入れてから使う）とか、その手の基本が大事だね
910:デフォルトの名無しさん
17/04/15 16:18:04.02 eeh5f4V4.net
Excelのケースは多分デストラクタというより、Excelのスレッドモデルに問題があるんだと思う。
lock方式でもInvoke方式でもない、少々行き当たりばったりな排他制御をしてるようだ。
古いアプリなので今更改められないのだろうね。
911:デフォルトの名無しさん
17/04/15 16:31:33.32 OxStzCoo.net
エンゼルハートって映画あったな
探偵がロバートデニーロに殺人鬼を探すように依頼されるが、探していた
殺人鬼は探偵自身だったってオチ
「いつものキチガイ」も実は言ってる本人自（w
912:デフォルトの名無しさん
17/04/15 16:33:19.87 3WGNKYp+.net
はいはい、俺が悪かったってことで仲直り。
今後はこのスレ貢献に頑張ろう…でいいやん。
な
913:デフォルトの名無しさん
17/04/15 16:33:31.45 nXYdKgHp.net
ExcelCreatorが楽すぎて戻れない
914:デフォルトの名無しさん
17/04/15 16:36:28.32 eeh5f4V4.net
>>873
普通なら、それでOKなんだけどね
この人2000年頃にやってきて、際限なく荒らしまくって誰もいない状態にしやがったから。
たまーに戻って死んだかなとか見ているんだが、ご健在のようです。(はよ死ね
915:デフォルトの名無しさん
17/04/15 16:57:08.88 aGMB9daN.net
>>870
そんな基本は聞いたことが無いのだけど、
プロパティが返すオブジェクトをメソッドチェーン的に使うと、どういう問題があるの。
916:デフォルトの名無しさん
17/04/15 17:07:01.27 mW9XRjOW.net
Disposeされないオブジェクトが量産されてリソースリークするに決まってんだろ
一つプロパティにアクセスしたら結果を変数に入れて礼儀正しくDisposeする
これをすべてのメソッド呼び出しとプロパティ・インデクサーアクセスについて行う
917:デフォルトの名無しさん
17/04/15 17:09:24.07 nXYdKgHp.net
>>877
おもしろい冗談だな
918:デフォルトの名無しさん
17/04/15 17:16:22.23 UPL5S+RA.net
return a,b;で返したのを
こんな感じで受け取れれば楽なんだけどな
a,b=method(c);
919:デフォルトの名無しさん
17/04/15 17:31:49.05 OxStzCoo.net
>>876
ゾンビ
なんだかVBerチックなおまじないのように聞こえるけど
920:そうじゃない。 もっとも、どうしてそうする必要があるのか、詳しい理屈は忘れちゃったけどw 明示的に変数で参照されてないCOMオブジェクトは相互運用アセンブリが適切に破棄できないとかなんとか まあ、変数に入れなきゃReleaseComObjectを呼ぶこともできないよね
921:デフォルトの名無しさん
17/04/15 17:33:16.72 7hkWD0i5.net
excelはC++から使ってもゾンビるよ
922:デフォルトの名無しさん
17/04/15 17:38:17.93 A0YDVHHt.net
>>867
昔の話だよ。
923:デフォルトの名無しさん
17/04/15 17:41:04.42 aGMB9daN.net
>>880
結局ReleaseComObjectは必要なのね。
924:デフォルトの名無しさん
17/04/15 17:47:17.96 jssTx07C.net
>>859
昔のプログラムメンテする必要が有って、丁度それに出くわして同じ方法で対応したわ
結局そのロジック切り捨ててOpenXMLで読み書きしちゃったけど
925:デフォルトの名無しさん
17/04/15 17:54:59.95 OxStzCoo.net
>>883
いやいらんと思うよ
URLﾘﾝｸ(web-beta.archive.org)URLﾘﾝｸ(jeanne.wankuma.com)
↑によるとReleaseComObjectは「保険」らしい
オブジェクトをちゃんと変数につっこんでから使えは一応ソースあった。
「仕様」の一言で、どうしてそうしなきゃらなんのかの理屈は書いてないが
URLﾘﾝｸ(support.microsoft.com)
926:デフォルトの名無しさん
17/04/15 18:00:32.55 OxStzCoo.net
まあVB6みたいに参照カウント見てラッパーオブジェクトの破棄をやってるからってことなのかな
こま切れのレスで申し訳ない
927:デフォルトの名無しさん
17/04/15 18:14:19.64 eeh5f4V4.net
>>885
>ガベージ コレクションを実行して解放することができますが、こちらはあくまでも保険です
読んでみた限り、GCが保険でReleaseComObjectでやれという事に読めますね。
マイクロソフト公式も保証されるわけではないという感じですね。
実際、これはやってみたが上手くいかないケースはちょくちょく発生します。
次善策以上の対策は取れないと思われます。以前サポートに質問した時もそんな感じの回答でした。
928:デフォルトの名無しさん
17/04/15 18:33:54.48 OxStzCoo.net
>>887
あー確かにその通りだねw
適当なこと言ってごめん
929:デフォルトの名無しさん
17/04/15 22:36:26.65 tyUWSBTM.net
>>879
タプルに括弧が必要なのはやむを得ないかな。変数宣言の文法変えるわけにもいかないし。
930:デフォルトの名無しさん
17/04/15 22:56:40.40 lvAT8XK9.net
>>881
ちゃんと作ればゾンビったりしないよ
デストラクタで確実に解放できるからその点だけで言えば C# よりむしろ楽
>>885
> ↑によるとReleaseComObjectは「保険」らしい
それ、それページ書いた人がちゃんと理解してないだけ
そもそもGCはCOMなんて意識してないからCOMの解放なんてしないし
詳しくはここら辺を見て
URLﾘﾝｸ(blogs.msdn.microsoft.com)
931:デフォルトの名無しさん
17/04/15 23:54:44.22 X3IC3wwW.net
ググってもよくわからんのだけど
GetType()+typeof()で型判定と
isでやるのはどっちが速い?
932:デフォルトの名無しさん
17/04/16 00:20:09.43 SqhlDt4o.net
>>891
一時変数に入れたりしないで単純な GetType == typeof の形に限り前者
JITレベルで最適化がかかるみたい
933:デフォルトの名無しさん
17/04/16 01:16:43.35 dwmihMuF.net
>>855
GCのソースを見る気はしないけど0クリアはやってないと思う。
どう考えても時間の無駄。
変数を使用するタイミングで初期化が行われて、ものによってゼロクリアが行われるってだけじゃないんかね。
だから大量な領域をゼロクリアすることはそうそうないと思ってるんだけど。
例えばintの長い配列を確保したときとかくらい。
934:デフォルトの名無しさん
17/04/16 02:15:50.20 UDjczAnn.net
>>893
ヒープのオブジェクトは new した時点で内容が0クリアされてることは仕様
935:デフォルトの名無しさん
17/04/16 06:55:53.07 dwmihMuF.net
>>894
それはメモリ確保後に初期値で初期化されたってことででしょ。どっちにしろGCで大量にゼロクリアが必要にはならないよね。
936:デフォルトの名無しさん
17/04/16 08:00:22.29 uS8rD07o.net
どーせ、一番下でVirtualAlloc走ってんでしょ。そこで0クリアなんじゃね？
937:デフォルトの名無しさん
17/04/16 08:43:50.68 dr2cdwts.net
0クリアをどのタイミングでしているかは知らないが
早めの0クリアがセキュリティーに貢献するであろう事は予想できる。
今そうでなくても、そのうちに使用しなくなったタイミングで可能なら0クリアという形になったとしても驚かない。
938:デフォルトの名無しさん
17/04/16 08:49:20.74 dr2cdwts.net
ちなみに自分はガベコレが効率よく機能してくれるよう、使用しなくなったら0クリアはしている。
巨大なツリー構造を作って大量のヒープを使い始めると、参照を移動するだけでも結構なCPU時間を取られるようなので。
939:デフォルトの名無しさん
17/04/16 09:00:30.49 nOhMz2bP.net
破棄されるメモリへの(読まれない)書き込みを省略する最適化を行うコンパイラもあるし、
一律0クリアって方向にはならないだろうねぇ。
セキュリティ確保のためにわざわざ省略されない0クリアなんて機能を用意するくらいだし。
940:デフォルトの名無しさん
17/04/16 09:02:08.11 H6tmXYoH.net
0クリアとnull代入は別物だぞ
941:デフォルトの名無しさん
17/04/16 10:39:40.78 yhNZe4vR.net
>>897
> 0クリアをどのタイミングでしているかは知らないが
何のためにデバッガがついてると思ってんだ。
942:デフォルトの名無しさん
17/04/16 11:27:43.64 UDjczAnn.net
>>896
あー、それそれ
.NET Core の gc フォルダ内のコードに VirtualAlloc の RESET_MEM で
ゼロクリアしてる箇所がいくつかあった
たぶん、コンパクションした後に残ったゴミ領域を VirtualAlloc で
ゼロクリアしてると思うんだが、そこは探しきれなかった
>>895
初期値(0)で初期化されたってのはゼロクリアなんだが……
URLﾘﾝｸ(ufcpp.net)
お前の言う初期値は別のことを指してるのか？
> どっちにしろGCで大量にゼロクリアが必要にはならないよね。
メモリ確保時のゼロクリアってのはヒープ管理の行うこと
ヒープ管理はGCとは切り離せないの
だから .NET Core のゼロクリアのコードだって gc フォルダ内に配置されてるんだし
943:デフォルトの名無しさん
17/04/16 11:44:56.24 EJt90aDw.net
>>902
横からごめん。無知なので教えて。
・GC って概要として不要になったメモリを解放する機能って理解はあってる？
・メモリ確保時に初期化が実行されるとの理解はあってる？
・一般的な挙動として、メモリ確保と GC は別物との理解に誤りはある？
※実装が GC 時に初期化しているかどうかではなく、GC と言う言葉の定義に初期化が含まれるかと言うこと
自分は上記が正しいと思ってるから、 >>895 の内容に違和感を感じなかったんだ。
944:デフォルトの名無しさん
17/04/16 12:08:09.86 uS8rD07o.net
>>903
君は正しい
945:デフォルトの名無しさん
17/04/16 12:11:25.63 SqhlDt4o.net
>>903
CLRの構造としては、GCはメモリ管理一般を担うコンポーネントである
だからメモリ確保も初期化するのもGC
GCってメモリの使用状況に応じてオブジェクトを動的に再配置したりとか色々裏で頑張ってるから、
単純に 確保/解放 と割り切れるもんじゃないんだよ
946:デフォルトの名無しさん
17/04/16 12:21:18.23 qeC+G70E.net
>>891
前者でもいいけどtypeof(シールクラス)にしないとダメだよ
947:デフォルトの名無しさん
17/04/16 13:21:57.61 UDjczAnn.net
>>903
>・GC って概要として不要になったメモリを解放する機能って理解はあってる？
はい
>・メモリ確保時に初期化が実行されるとの理解はあってる？
正確ではない
ヒープからオブジェクトを確保したら初期化されていることが決まっているだけで、
初期化�