ふらっと C#,C♯,C＃（初心者用） Part145

2019/10/07(月) 20:16:17.93

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2019/11/12(火) 12:34:30.29

>>627
もちろんレイヤー化はするし、機能配置はしっかり設計するよ。
ユーザーはコード見なくていいって時代じゃないんでね。

2019/11/12(火) 12:56:06.79

真っ赤なガイジ一歩手前

2019/11/12(火) 13:00:05.39

ごめんガイジに触っちゃっま

2019/11/12(火) 13:53:14.21

>>630,631
業務ユーザが LINQ to Entities に手を突っ込むの、ガイジだよなぁ、わかるぞ。
だがね、人のやらないことを先鞭をつけてやらねばならない場合もあるのだよ。

ひととおり技術評価した結果、本格的に導入するのは時期尚早という判断で別の技術つかうことにした。.NET 5 以降に期待してる。

2019/11/12(火) 17:44:24.07

え、業務アプリで普通にLINQ to Entities使ってるけどなんかマズい問題でもあるの？
単純に手軽で使いやすいと思ったから使ってるんだけど・・・・

2019/11/12(火) 17:50:33.05

>>633
問題ない。Dapper開発元のStackOverflowでさえEntityFramework Coreを併用してる。

2019/11/12(火) 18:29:22.62

LINQのmaxやminで最大最小が求められるけど
最大、最小の値を持つオブジェクトを取得する方法はないのかな？

2019/11/12(火) 18:44:22.60

MaxBy、MinByでググれ

2019/11/12(火) 18:46:28.43

散々上で話題に出てたやんｗ

2019/11/12(火) 19:49:03.77

>>635
new {
Max = src.Max(),
Min = src.Min()
}

2019/11/12(火) 20:14:31.68

>>628
それらを区別することがはたしてLINQの目指すべき理想なのかね

2019/11/12(火) 21:23:28.30

>>639
それらってどれのことだろう？
LINQ to Object と Entities のことかな？

両者の設計はよく考えられたシームレスで美しいデザインだと個人的には思うよ、違いをしっかり理解できた後ならね。違いが分かりにくいというのは言語設計の問題ではなく、MS Docs などガイドの問題だと思う。

何が理想的な設計かは人によって感じ方が違うのではないかな。

あ、EF4, 5, 6, Core と進化する間に名前空間や正規関数などがコロコロ変わっているあたりは、場当たり的で汚いと思う。何か制約があって実装をやり直した、その苦労の跡が垣間見える。Core から後方互換を捨てて綺麗に作り直そう感があるから、.NET 5 に期待している。

2019/11/12(火) 21:44:06.09

ごめんちょっと話が横に反れちゃうけど、このスレ見たり書き込んだりしてる人って
MicrosoftDocsって日本語/英語どっちを見てるの？
当たり前のように原文ですらすらと読んで理解してるものなの？
MSDNが廃止されてDocsになったはいいけど特にAPIリファレンスとか日本語訳の品質が酷すぎて辛い
自分は英語ほとんど読めないんで、Chromeで日本語版、FireFoxで英語版＋Google翻訳をそれぞれ表示して
３タブ切り替えながら読み進めてくなんて効率の悪いことをやってるんだけど、みんなはどうしてるのか気になった

MSの一次ソースに当たるのも↑の理由でしんどいんだよね・・・
もう潤沢な日本語訳が提供されるような時代じゃなくなったんで英語のできないPGは退場せざるをえないのか

2019/11/12(火) 21:45:38.20

docsは辞書的に使うことがほとんどだしそれぐらいなら英語で十分

2019/11/12(火) 21:46:46.04

>>641
もちろん英語

2019/11/12(火) 22:25:29.03

>>641
調べる目的によるかな。

引数の順番とかオーバーロードとかうろ覚えの確認程度なら、検索して最初に出てきた方。
初出のロジックを書くためにコンセプトや基礎設計からじっくり考えつつ API を調査するなら、まず日本語でざっくり理解、重要なポイントが和訳で怪しいなら英語で精緻化。
LINQ なんかは集合論や数学に近く、これらは概念が同じなら分野跨いで英単語が同一だったりして英語の方が理解が早いから英語のみ、とか。
LINQ to Entities の場合、一次二次併せてそもそもの情報量が少ないから、英語日本語関係なくとにかく漁る。(そして英語の Q&A でほのめかされているヒントに辿り着き、一次ソース原文を当たったりする。)

2019/11/12(火) 23:03:23.32

俺も英語は苦手だけどdocsは基本英語
どういうメソッドあったっけ？で見ることが多いから多少の単語がわかればほぼ理解できる
動作が知りたいときでよくわからん英語の言い回しがあったときは日本語にして読んでみる
けど、そういうときは日本語にしても大抵理解できない
デフォを英語にするようにしとけばプログラムで頻出する英単語が徐々に覚えられるようになるから英語をオススメする

2019/11/12(火) 23:37:52.61

>>641
日本語が読めたもんじゃないから英語に切り替えることが多い
機械翻訳かける時は、最近のグーグル翻訳は使い物にならないから、みらい翻訳のお試し翻訳使ってる

2019/11/12(火) 23:53:04.67

ありがと、自分もdocs英語派に転向するよう頑張ってみる
比較的翻訳が整ってる基礎説明みたいなページでもいちいち
「角度」⇒「Angular.js」、「反応」⇒「React.js」みたいな脳内逆翻訳をかますよりは
苦手でも最初っから英語版を読み解くほうがやっぱりマシなんだよな・・・

自分はFirefoxのアドオンで
・Simple Translate （右クリックでGoogle翻訳結果をポップアップ表示）
・MouseDictionary （マウスを乗せた英単語の日本語意味をリアルタイム表示）
を入れてる
みらい翻訳はいちいち英文をCopy&Pasteするのが面倒で常用断念

2019/11/13(水) 00:34:44.18

とりあえず日本語でぱっと見て意味が取れるならそれで良し
んん？ってなったときに原文に当たる
これが一番効率良いと思うよ

2019/11/13(水) 00:57:11.68

>>648
意味が取れたと思って試してみたら挙動がおかしくて、原文見たら真反対の意味でショック受けた記憶がある。

2019/11/13(水) 01:05:25.68

アホやなあ

2019/11/13(水) 01:08:43.01

まあジャパニーズITドカタの世界じゃ専門卒の英語アレルギーな連中に扱えないようなものが普及することは決してないから、
業界から脱出するつもりがないんなら英語はハナから捨てたほうが賢明だよ
だって業務では永遠に使えないんだから

2019/11/13(水) 01:13:25.17

どこの底辺業界の業務だよ

2019/11/13(水) 01:22:20.09

いや英語棄てるとか絶対無理。
日本語訳がアテにならないのが分かってから原文しか読んでない。

2019/11/13(水) 02:18:49.03

自分は英語が苦手
でもMSの自動翻訳はイマイチなのでgoogle翻訳の自動翻訳を使う
それでもよく分からない時はgoogle 翻訳のサイトにコピペして翻訳する

2019/11/13(水) 02:34:13.53

>>654
コピペする労力を惜しまないなら
みらい翻訳の方がましな日本語になるからお勧め

2019/11/13(水) 03:12:16.84

翻訳ソフトを多用するから英語読む力が身につかないんやで
まともな辞書を使って単語帳をつけて定期的に復習するのが大事
翻訳ソフトは最後の手段

マウスオーバーで引ける辞書も便利だけど
便利すぎて辞書ナシで文やパラグラフを読む努力をしなくなると英語力は向上しない

2019/11/13(水) 11:53:32.61

英語力向上が目的じゃないから。
あくまで目的は正しい情報を入手すること。
もう数年後にはかなりの精度の自動翻訳ができるようになってると予想する。

2019/11/13(水) 12:16:37.65

翻訳精度の向上ってもう10年以上言われ続けてるよねｗ
こないだgoogleだかどっかが文脈を考慮した翻訳どうのこうのってリリース出してたけどどこまで伸びるかねぇ

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-y5kd) · 2019/11/13(水) 12:22:25.68

>>656
目的をはき違えてる

2019/11/13(水) 13:18:54.28

既に英語-日本語は十分な翻訳精度になってない？
MSDNのようなオフィシャルな場はもうほぼ完璧だし、そこら辺の外人フォーラムなんかでも一応意は汲める
中学英語程度の基礎があれば読みに関してはもう不自由しない

2019/11/13(水) 13:36:03.37

>>657
超短期的な目的でしょそれ
翻訳ソフト使わないと読めないままで良いと思ってるんなら別にいいんだけどさ

技術的な調査能力だったり新しい技術を身につける速度に顕著に差が出るよ

2019/11/13(水) 14:39:59.45

現状で完璧なんて口が裂けても言えないと思うけど…
msdnみたいな同じ言い回しが頻出するようなところは個別の対応もしやすいし、そもそも単調な事実だけを述べるだけの文章なんで誤訳は少ない
そんな環境でも真逆の意味に訳されてしまっているケースすら存在する
こないだdoとdo notが逆に翻訳されててちょっと燃えたよね
補助として使う分には十分なレベルではあると思うが翻訳能力自体はまだまだ伸びて欲しいと思うよ

2019/11/13(水) 14:49:33.50

>>661
俺たちは英語のマスターが目的じゃないの
しつこいよ

2019/11/13(水) 14:52:44.04

まともな大学出てるエンジニアなら英語さえ話せれば外資に転職して軽く一千万以上貰える
必死こいてEFCoreとか覚えるより本気で英語を勉強した方が遥かに効率的だぞ

2019/11/13(水) 17:03:16.58

時々機械翻訳が真逆の時あったけどどこをどう解釈したのか痕跡も判らない

2019/11/13(水) 18:13:13.40

質問です
ジェネリッククラスにおいて型Tがクラスのときとstructのときで全く挙動を変えたいのですが、
同名の2つのジェネリッククラスに異なる型制約をつけることは可能でしょうか

2019/11/13(水) 18:27:16.02

できないんじゃないかな
別のクラス名にして
インターフェースを被せてやるんじゃダメなの？

2019/11/13(水) 18:54:26.13

ん？where T classでの制約の話じゃないの？

2019/11/13(水) 18:54:57.26

>>667
ありがとうございます試してみます

2019/11/13(水) 18:55:58.02

>>664
EFCore使うのに必死になる必要なんてない

2019/11/13(水) 18:57:22.33

>>668
class A<T> where T class と
class A<T> where T struct とを同時に作れないか、という疑問でした

2019/11/13(水) 20:12:00.42

こんばんは
質問させてください

LINQのGroupByでデータテーブルの複数のカラムを指定しvar変数に格納後、
格納したデータをCopyToDataTableメソッドでデータテーブルに変換しようとしても、
CopyToメソッドしか候補に表示されないのですがVisual Studioのバグですか？

2019/11/13(水) 20:36:20.89

フォームアプリ作っていてデバッグ中です。

フォームのクラスから呼び出したクラスにブレークポイントを設定しているのですが、
止まってくれません。

フォームのクラス上に設定したブレークポイントでは止まってくれます。
これって仕様なのでしょうか？

2019/11/13(水) 20:54:49.74

なんかプロジェクト内でブレークポイントで止まるクラスと止まらないクラスがある。
前はどこに設定しても止まっていたのに・・・。
一体何が原因なんでしょうか？

2019/11/13(水) 20:55:42.59

ブレークポイントを通ってないから止まらないだけだろう

2019/11/13(水) 20:58:47.78

>>674
設定のチェックを外したらOKになりました。
自己解決しました。
おさがわせしてすいません。

2019/11/13(水) 22:19:14.93

>>672
変数名の上にマウス持ってったら型が表示される
その型は想定しているものになっていますか？

2019/11/13(水) 22:20:10.28

>>672
変数の型を確認すべし

2019/11/13(水) 22:20:40.60

やべ、超かぶった

2019/11/13(水) 22:24:28.57

>>672
IGroupingはキーを列挙するものだよ？
キーは通常DataRowじゃないからそりゃ出ないよ
グループごとにChildrenをDataTableにしたいのか、Childrenをキー順に並んだ１つのDataTableにしたいのかによって書き方は変わる

2019/11/13(水) 22:25:44.66

>>663
マスターww

辞書使う前にとにかく翻訳ソフト使うやつは
リファレンス見ずにQiita見てコピペしようとするやつと同じ思考回路なんだよね
いつまでもスキルが身につかない原因を自分が作り出してることに気が付かないとすぐに淘汰されるよ

2019/11/13(水) 22:33:54.95

>>677-678>>680
助言をいただきありがとうございます！
もう一度よく確認してみます

2019/11/13(水) 22:43:58.27

前にも居たけどなんですぐにVSのバグを疑うんだろうね？

2019/11/13(水) 22:46:52.14

まあ最近のVSの最新版はガチでバグだらけだけどな

2019/11/13(水) 23:45:26.05

複数のスレッドから１つのコンソールにLOGを吐きつづけられますか？
Parallel.Forで

2019/11/13(水) 23:50:53.72

できるよ

2019/11/13(水) 23:53:58.04

>>686
Invokeとかlockとかしなくても大丈夫ですか？

2019/11/13(水) 23:54:59.91

>>685
コンソールに出力するためのスレッド作ってそこにみんな投げればいいがParallel.Forの意味がわからん

2019/11/14(木) 00:06:39.08

昔はよく非同期処理の理解のためにコンソールに出力したんだけど今は市内の？

2019/11/14(木) 00:25:46.71

>>685
https://docs.microsoft.com/en-us/dotnet/api/system.console の一番下に
「Thread Safety This type is thread safe.」と保証されているので複数スレッドから吐いても全く問題ない

2019/11/14(木) 11:25:27.19

複数あるスレッドが分割して１行の文字列を作ってると間に別スレッドの文字列が割り込むけどな。

2019/11/14(木) 11:34:27.42

>>671
実験してないんで動かなかったらごめんなんだけど
default(T) == null
ならclassとして処理する
で実現できたりしないかな
nullableだったら無理だけど

2019/11/14(木) 11:45:28.52

WPFだとスレッドからLabel.Textや
Textbox.Text、CheckBox.Checkedにアクセスできるもの？
できなければできるように拡張したりできないものかな

2019/11/14(木) 12:17:18.58

>>692
クラスではなくメソッドについて struct/class 制約の共通化をやろうとした経験から言うと ...

Nullable 含めて内部判定することはできるけど、判定・分岐があちこちに発生することになり、かなりめんどくさいし、読みにくくなる。
だったらクラス分けて、誰かが言った通り interface (か abstract base class) で共通化図る方が楽と思われる。

2019/11/14(木) 12:33:48.96

>>693
無⭐︎理

2019/11/14(木) 12:59:54.31

>>671
やりたいことの意図を誤解してるかもしれんけど、

static class A
{
　　public static A<T> OfStruct<T>() where T : struct
　　{
　　　　....
　　}

　　public static A<T> OfClass<T>() where T : class
　　{
　　　　....
　　}
}

class A<T>
{
}

こんなのとか...
っていうか、ジェネリッククラスのスタティックメソッドってTを使ってなくてもいちいち型パラメータ
指定しないと呼び出せないのかw

2019/11/14(木) 13:09:24.35

>>693
WPFだと一般的にはMVVM使う
で、MVVMなら直接ViewにアクセスしないでVM経由になる
VMの値はスレッド越しに取得設定できる
コレクションの操作については事前に同期オブジェクト渡すとかする必要があるけど

2019/11/14(木) 13:27:31.68

こっちの方がマシか
class A<T>
{
　　protected A() { }
}

class AOfStruct<T>:A<T> where T:struct
{
}

class AOfClass<T>:A<T> where T:class
{
}

2019/11/14(木) 15:03:19.73

型制約は正直あんまり役に立たない微妙な機能な気がしている

2019/11/14(木) 15:23:48.31

ジェネリックなメンバアクセスには、最近は構造的部分型を使うのが流行りだね
構造的部分型ベースの型システムを持つTypeScriptやGoでは利用する側でアドホックにinterfaceを定義できるから、
利用シーンを先読みして型階層を設計するという人間には困難な芸当なしで柔軟に型制約のようなことができる

2019/11/14(木) 15:51:06.76

>>700
よくわからん
コードで例えてくれ

2019/11/14(木) 20:42:53.07

質問させてください

ASP.NET
C#
SQL Server
を使用しています

SQLにByte型で保存したバイナリデータが保存されています
そのバイナリデータをASP.NET側でLISTで受け取り、フォルダに保存したいです
LISTで受け取った後にフォルダに保存するところの書き方を教えてください

よろしくお願いします

2019/11/14(木) 21:07:50.31

BinaryWriterを使えばいい

2019/11/14(木) 21:23:37.38

LISTというのが何なのかは知らんが
配列で読み取ってFile.WriteAllBytesだけでよくね　何百MBとかならアレだが

2019/11/15(金) 12:38:58.70

普通にストリーミングで吐いた方が安パイ

2019/11/15(金) 18:28:40.04

保存ってのはクライアント側なのかサーバ側なのか

**デフォルトの名無しさん** (ｽﾌｯ Sda2-zeRf) · 2019/11/15(金) 21:26:03.41

>>702
みんなLISTが疑問符だ
そこちょぅと詳しく

2019/11/15(金) 23:36:35.15

static int UnitStep1(int x) => x >= 0 ? 1 : 0;
static int UnitStep2(int x) => (x >> 31) + 1;

上のような２つの関数を最適化ありでコンパイルして
ランダムな100万個の値に対して実行すると、
①どちらも同じ値が返ってくる
②UnitStep1の方がUnitStep2よりも10倍近く時間がかかる
という実験結果が得られました。

①と②の理由を考察しないといけないのですが、
①は分かったものの、②がさっぱり分かりません。
というか、どう考えてもUnitStep2の方が
無駄な処理をしているように思えます。

分かる方がいたら教えていただけないでしょうか？
よろしくお願いします。

2019/11/15(金) 23:45:14.55

三項演算子で比較するよりビットシフトのほうが圧倒的に早いから
cpuが得意とする処理と人間が理解しやすい処理は一致しない
どうしても納得行かないならILを見て各ステップでどういう命令がされるか確認するしか無いかな？

2019/11/16(土) 00:11:47.33

>>709
ありがとうございます。とりあえずILについて調べて、
下のようなページを表示させるところまで行き着きました。
https://sharplab.io/#v2:C4LglgNgPgAgzAAhgJgQYQQbwLACgEFICMAbAmAHbAICqFYwAysAKYAORAFJdQB4CUCALwA+BLwQihCAAwIA/AiIIQsgNx5CxMj1r0mrNsm5Vxg0Qk4SRYuEUEBqJWoR4AvkA===

これから書いてある内容の理解に挑戦してみようと思います。

2019/11/16(土) 00:31:35.36

そのILをぱっと見る限り、実行されるアセンブラまで調べに行く必要あるのかも
命令数は変わらんし
そこまで行ったらもう環境依存な気もする
てか最適化ありなら最適化されたIL見ないとだめかな

2019/11/16(土) 00:37:54.66

>>708
大昔にアセンブリやっていた経験からの推測だけど...

①の >= は左辺引く右辺の減算をして符号判定をしており、右辺の 0 を引くという演算が最適化ありでも外れず無駄な演算をしている可能性がまず一つ。でもこれは②に対して圧倒的に不利になる要素ではない。

もう一つのよりありそうな可能性は、三項演算子がコンパイルで if ステートメントになり、分岐先ブロックでパイプライン先読み実行していたステップが、分岐先読みの失敗により、ロールバックするコストが高くついているのではないかと。
確率 50% の分岐なら、2回に1回はロールバックすることになるため、コストが最悪になる。if else ブロックのどちらが実現確率が高いか、コンパイラが判断・制御できていない。
それに対して②はパイプライン処理を乱す要素がない。

どう中間コンパイルされ、どう IL が動くのか、最近の低レイヤーの処理は全く知らないため、見当外れかもしれないが。

2019/11/16(土) 00:46:48.34

条件分岐は遅い
一方ビットシフトと加減はCPUが最も得意な処理
そのレベルのことを考慮するような処理にC#はあまり向いてないと思うが

2019/11/16(土) 00:59:24.83

パイプライン処理の詳細は Wiki で調べて、命令パイプライン、パイプラインハザード、制御ハザードの節あたりを参照しておくれ。

条件分岐がなぜ遅いかわかる。確率考えてアセンブリレベルで制御しないと速くならないよ。

2019/11/16(土) 01:04:27.12

あ、ごめん。よく読んだらランダムな値に対してって書いてあった。確率 50% の先読み最悪ケースになるね。アセンブリレベルでも最適化は無理。

2019/11/16(土) 01:07:09.62

>>711
ありがとうございます。
アセンブラというのはSharpLabのページの
ResultsをJIT Asmにしたときに表示されるものと考えて正しいですか？
IL命令について色々と調べていたのですが、
JIT Asmのほうが書いてあることが少ないので先にこちらに挑戦してみようと思います。

あと最適化されたILというのは、ResultsをILにして、
一番右上の選択肢をReleaseにしたときに表示されるものと考えて正しいですか？

>>712
ありがとうございます。UnitStep?(int x)のxはプラスとマイナスが50%ずつになるように
ランダムに決めているので、確かに分岐の確率は50%です。
まだパイプラインについて完全に理解できていないので見当外れかもしれませんが、
試しにプラスとマイナスの割合を変えてどうなるかについても検証してみようと思います。

>>713
>>714
ありがとうございます。やはりハードウェアについてしっかりと理解しないといけないのですね。
ひとまず、>>714に書いていただいたキーワードについて調べてみたいと思います。

2019/11/16(土) 01:19:12.81

もしパイプライン処理がビンゴだったら IL 見ててもわからないよ。

CPU の fetch, decode, exec という内部処理の流れを理解しないと。

質問の書きぶりから大学かなんかの課題に見えるんだけど、高級言語ばかり見ていて低レイヤーのこと知らないとハマることあるかもよって警告するためのお題なのかもね。

2019/11/16(土) 01:26:24.15

C#で考えるべき速度は計算量まで
メモリレベルの最適化を考えるならCで書くべきだし
CPUレベルでの最適化がしたいならアセンブラを覚えるべき

2019/11/16(土) 01:33:47.48

分岐先読み失敗って言ったって
x >= 0 ? 1 : 0
さすがにこんなのゼロコストじゃないの？

単純に機械語レベルの命令数の差を反映しているだけのような気が
知らんけど

2019/11/16(土) 01:41:11.97

>>718
いいインサイトですね。勉強になります。

>>716
もし true ? 1 : 0 の速さが②にかなり近くなって false ? 1 : 0 の速さが①よりさらに悪くなる、(あるいはその逆) ならパイプライン処理が原因だと考えて間違いないと思う。

2019/11/16(土) 01:50:49.22

>>719
機械語レベルの命令数に差があるように見える？
①②どちらも 2, 3 ステップだよ。

先読み失敗リカバリーはものすごくコスト高いよ。
パイプライン上の仕掛かりを全部クリアしなければならないんだから。その 2, 3 ステップの 1.5 ～ 3 倍くらいのクロックサイクルを無駄にすると思う。

2019/11/16(土) 02:00:02.51

>>719
ごめん、言い過ぎた。
IL わからんから、中間コンパイル通したらなんとも言えない。機械語の命令数が膨らむ可能性もありうる。
721 はネイティブコンパイルしたら、という仮定の話。

2019/11/16(土) 02:19:10.34

不勉強で今時のCPUのアーキテクチャーさっぱり分からんが、
ググってみると、投機的実行は予測が当たれば儲け、はずれても損なしだからこそ意味があると書いてある

コインの裏が出たら損をするなら意味がないと思うんだけど

2019/11/16(土) 02:28:53.52

>>715
>>720
ありがとうございます。
xのプラスとマイナスの割合を変えて実験してみたところ、
UnitStep2では処理時間はほとんど変わりませんでしたが、
UnitStep1では、50:50のときが一番遅くてUnitStep2の10倍程度、
75:20と25:75はどちらも少し速くなってUnitStep2の6倍程度、
100:0と0:100はどちらもさらに速くなってUnitStep2の2倍程度になりました。
やっぱりパイプライン処理が原因っぽいですよね？

>>717
ありがとうございます。勉強になります。
高級言語では計算量までしか考える価値がなくて、
しかし計算量さえ小さければあとはマシンパワーでなんとでもなる。
だからこそ高級言語が今の時代に合っているということでしょうか。

>>719
ありがとうございます。
機械語レベルの命令＝JIT Asmの命令だとすれば、
UnitStep1とUnitStep2では6命令と4命令で確かに差はあるものの、
単純計算なら10倍もの違いはないようです。

2019/11/16(土) 02:35:13.39

>>723
それ出典教えてもらえる？
外れても損なし、だったらいいなっていう理想を言っているのではないのかな。

ランダムデータには弱いけど、正常系と異常系の分岐はたいてい正常系の発生確率が高いためこちらに賭けるのよ。で、ロジックの多くはこの手の分岐でしょ、っていうことを想定して先読みのアーキテクチャになっている。

ということをその文献も (独特の表現で) 言いたいのではないかと思うのだが。

もれも最近の CPU がわかっているわけではない。80286 ～ 386 時代でアップデート止まってる。

2019/11/16(土) 02:40:12.76

>>720
>>724の75:20というのは間違いで、正しくは75:25でした。失礼しました。

ところで、ランダムに50:50ではなくプラスとマイナスを交互にしたら
もっと遅くなるかと思いきや、むしろ75:25よりも少し早いくらいになりました。
（ランダムの場合も交互の場合もあらかじめ入力データを配列に格納してから
　計測を開始しているので、入力データの作成コストは結果に影響していないはずです）

どんな仕組みで先読みをしてるのかさっぱり分かりませんが、
とにかく予測ができないのが遅くなる一番の原因のようです。

2019/11/16(土) 02:46:49.96

>>724
そうですね、データ依存なんでパイプラインと先読みが原因だと個人的には思います。

そういえば思い出しましたが、if else ブロックの片方に固定的に賭けると必要以上に大負けすることがあるため、条件分岐を何度か通ったところで学習し、勝てる見込みのより高い方へ賭けるアーキ設計だったような気がします。

true : false = 100 : 0 or 0 : 100 に片方が大負けせず、同じ性能になったのはこの学習効果ではないかと。

モダン言語の進化の方向の一つに高級化があるのは、仰るとおり。低レイヤーの最適化はコンパイラと進化したハードウェアに任せ、コードは人間にわかりやすくして開発生産性を高めようということです。

もう一つの進化方向は Rust とか Go とか、低レイヤー向け言語を C++ よりわかりやすく、より安全にしようというものだと思います。

2019/11/16(土) 03:34:45.34

>>725
失礼、例えばここにそんなことが書いてある
http://e-words.jp/w/%E6%8A%95%E6%A9%9F%E7%9A%84%E5%AE%9F%E8%A1%8C.html

でもこの通りだとしても>>723は的外れだねすんません。
「損はない」というのは並列ではなくシーケンシャルに実行した場合のコストを
上回ることはないって意味だと思う。

同じ100ステップでも素直に並列化できる部分が大きい100ステップの方が
低コストなのは当たり前の話でした