[過去ﾛｸﾞ] Visual Studio 2008 Part 22 (314ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
271: 2018/09/17(月)01:24 ID:yaPtorLJ(3/7) AAS
>>257
>なおILSpy、グダグダ言わずに試してみたが、
>当たり前だがmanaged code だとILが出る(x86ではない）ので、
>俺って根本的に間違ってたかも？
>今までx86のアセンブラで議論してたけど、これって .NET アプリには同梱されていないというオチ？
やはり、managed code部分は、x86命令では無く、ILにコンパイルされていて、
普通のC++とは違ってたんだ。
272: 2018/09/17(月)01:30 ID:yaPtorLJ(4/7) AAS
>calc_norm_and_regulateをunmanaged関数にすると、違いはなくなる。
>(Releaseビルドの｀をコマンドプロンプトで起動した際にも、****ddの結果となる）
やはり。
unmanaged関数の場合は、CIL(MSIL)ではなく、exeの段階で既に
x86マシン語に直されたものが格納されるんだろう。だとすると、起動方法に
関係なく、少なくともその部分に関しては、x87 fpu命令の使われ方が
全く同じになる。callしたsqrt()関数の中は除いて。
273(1): 2018/09/17(月)01:37 ID:dj7qSZnZ(1/17) AAS
>>259-260のｺｰﾄﾞも>>262-263
も同じ条件でﾃﾞﾌｫﾙﾄでｺﾝﾊﾟｲﾙしてる
ｺﾚは間違いない
一行ｺﾒﾝﾄはずしてｺﾝﾊﾟｲﾙしなおすだけだからな
で、>>261、>>264みたいな結果になる
>>264の実行結果はDebugﾋﾞﾙﾄﾞとまったく同じになる
そのまんま
274: 2018/09/17(月)02:03 ID:yaPtorLJ(5/7) AAS
はっきり書いてある。managed code は、起動時にJITコンパイルされる。
だから、どんなマシン語に置き換わるかが、コンパイルしただけでは
まだ完全には決定されてない。
外部ﾘﾝｸ:en.wikipedia.org
Drawbacks include slower startup speed (the managed code must be JIT
compiled by the VM) and generally increased use of system resources
on any machine that is executing the code.
managed code は、VMによって、JIT コンパイルされないといけないので、
起動速度が遅くなり、かつ、一般的に、システム・リソースの使用が増える。
275: 2018/09/17(月)02:49 ID:dj7qSZnZ(2/17) AAS
普通のｺﾝｿｰﾙｱﾌﾟﾘｹｰｼｮﾝ(CLRじゃないほう)でも
同じｺｰﾄﾞで普通にまったく同じように再現するﾜｹだが
ﾎﾝﾄなｷﾐﾗはなにを頭悪いことばっかりいってんの？
実行結果だけははっといてやるが
276(1): 2018/09/17(月)02:50 ID:dj7qSZnZ(3/17) AAS
AA省
277(1): 2018/09/17(月)02:50 ID:dj7qSZnZ(4/17) AAS
AA省
278(1): 2018/09/17(月)02:51 ID:dj7qSZnZ(5/17) AAS
?-1 ﾃﾞﾌｫﾙﾄ設定（Release） 【実行結果】
↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ
外部ﾘﾝｸ:ideone.com
[1]0x0007F2C44DFFF8F2:1.1053482540585106e-308
[2]0x1FF68DDFB62221DE:1.051355436595308e-154
279(1): 2018/09/17(月)02:51 ID:dj7qSZnZ(6/17) AAS
AA省
280(1): 2018/09/17(月)02:52 ID:dj7qSZnZ(7/17) AAS
AA省
281(1): 2018/09/17(月)02:52 ID:dj7qSZnZ(8/17) AAS
?-2 ﾃﾞﾌｫﾙﾄ設定（Release） 【実行結果】
↓このｺｰﾄﾞの逆ｱｾﾝﾌﾞﾙｺｰﾄﾞ
外部ﾘﾝｸ:ideone.com
↓実行結果を書き込めないからこっちに書き込んどいた
外部ﾘﾝｸ:ideone.com
[1]0x0007F2C44DFFF8F1:1.1053482540585101e-308
[2]0x1FF68DDFB62221DD:1.0513554365953078e-154
282(2): 2018/09/17(月)02:53 ID:dj7qSZnZ(9/17) AAS
AA省
283: 2018/09/17(月)02:54 ID:dj7qSZnZ(10/17) AAS
（正）>>282
（誤）>>279
284(1): 2018/09/17(月)02:57 ID:dj7qSZnZ(11/17) AAS
>>276-277のｺｰﾄﾞも>>282,280のｺｰﾄﾞも
も同じ条件でﾃﾞﾌｫﾙﾄでｺﾝﾊﾟｲﾙしてる
一行ｺﾒﾝﾄはずしてｺﾝﾊﾟｲﾙしなおすだけだからな
で、>>278、>>281みたいな結果になる
>>281の実行結果はDebugﾋﾞﾙﾄﾞとまったく同じになる
そのまんま
CLRのとき（>>273）の動作とまったく同じ
ｷﾐﾗはずーっとなにやってるわけ？
285: 2018/09/17(月)09:44 ID:yu1Dprt2(1) AAS
>>284
同一のreleaseをコンソールで実行するかデバッガで実行するかで結果が異なるのはなぜだろう。
という話をしていたのであって、
debug/releaseで別の結果になることを問題にしているのではないです。
286(1): 2018/09/17(月)10:25 ID:+dwRu2dr(3/8) AAS
>>191がコンソール起動とIDE起動で挙動が異なる理由は分かりました。
ありがとう。
結論はつまり以下だ。
> JIT の最適化とデバッグ（抜粋）
> マネージ アプリケーションをデバッグするとき、Visual Studio では、既定で、
> ジャスト イン タイム (JIT: Just-In-Time) コードの最適化が省略されています。
> 最適化されたコードをデバッグするのは困難であるため、
> 最適化されたコードで発生するバグが、非最適化バージョンでは再現しないときにのみお勧めします。
> JIT 最適化は、Visual Studio の [モジュールの読み込み中に JIT 最適化を抑制する] オプションで制御されます。
> 実行中のプロセスにアタッチする場合、既に読み込まれ、JIT でコンパイルされ、
省4
287: 2018/09/17(月)10:25 ID:+dwRu2dr(4/8) AAS
その他諸々、話を整理すると、以下となる。（ソースは>>191参照）
1. managedコードではMSILが出力され、x86コードは含まれていない。
2. 起動時、MSILはJITされ、x86コードに落とされる。
3. このため、mainの1行目でブレークポイントで止め、calc_norm_and_regulateの逆アセンブルを見ようとしても、
IDE上で「逆アセンブルを表示できません。式がまだネイティブ マシン コードに翻訳されていません。」と出る。
これはmainの1行目に System::Diagnostics::Debugger::Launch(); を入れたときも同様。
4. そしてこのJITに関して、上記IDE中の 『[モジュールの読み込み中に JIT 最適化を抑制する] オプション』 が効いてくる。
規定ではオフ、つまり、ReleaseビルドでもIDE起動ならJIT最適化は抑制される。
これがfld/fmul/fadd/fstpのループコードになる理由。
これをオンにすれば、確かにReleaseビルドIDE起動でも、
省12
288(1): 2018/09/17(月)10:28 ID:dj7qSZnZ(12/17) AAS
同じﾘﾘｰｽﾋﾞﾙﾄﾞで
結果がかわってんのになにいってんの？
fprintf入れるだけで
ﾘﾘｰｽﾋﾞﾙﾄﾞで結果が変わる
289: 2018/09/17(月)10:31 ID:dj7qSZnZ(13/17) AAS
やはり低学歴知恵遅れは
結果が意味するところが分かってないわ。。。
290: 2018/09/17(月)10:32 ID:dj7qSZnZ(14/17) AAS
ちなみにｵﾚがあげた結果は
すべてﾘﾘｰｽﾋﾞﾙﾄﾞの結果だからな
ﾃﾞﾊﾞｯｸﾞﾋﾞﾙﾄﾞの結果なんかあげても
意味ないからな
291: 2018/09/17(月)10:38 ID:dj7qSZnZ(15/17) AAS
CLRのｹｰｽもCLRでない普通のexeのｹｰｽでも
結果はまったく同じだからな
しかもすべてﾘﾘｰｽﾋﾞﾙﾄﾞで
おきてる誤差までぴったり一致してる
292(1): 2018/09/17(月)10:52 ID:+dwRu2dr(5/8) AAS
>>288
お前は相変わらず理解してないな。
80bit（拡張倍精度）と64bit(倍精度)の演算で桁落ちが異なり、結果が異なるのは当然なんだよ。
問題は同じバイナリの癖に何故起動方法によって異なるのか？だったんだ。
理由はMSILだからだ。
MSILはCLR上でJITされ、x86コードに落とされる。
このときにJIT最適化がかかれば、拡張倍精度（を保ったまま）のコードになるし、
最適化がかからず毎回メモリに書き戻していれば、倍精度のコードになる。
.NETにおける同一バイナリってのは、同一MSILという意味であって、同一x86機械語という意味ではない。
だから、確かに同一バイナリを掴んでいたが、起動方法によって結果が異なっていたんだよ。
省9
293: 2018/09/17(月)10:54 ID:+dwRu2dr(6/8) AAS
× fprint
○ printf
まあ、分かると思いますが
294: 2018/09/17(月)10:57 ID:dj7qSZnZ(16/17) AAS
で、最適化されてるかされてないかすら
いまのいままで気付くことすらできない
そして気付く方法すらわからなかったわけか
うあわ
頭わるう。。。
ｷﾐ、ﾌﾟﾛｸﾞﾗﾑくむの向いてないわ
295: 2018/09/17(月)10:58 ID:dj7qSZnZ(17/17) AAS
問題の切り分けができない人は
ﾌﾟﾛｸﾞﾗﾑはくめない
ｺﾚは定説だからな
296: 2018/09/17(月)11:09 ID:ivGPGa/P(1) AAS
>>286
なるほど面白いね。
レスが膨大過ぎて最初の方しか読んでなかったけど、ネイティブコードの話と思い込んでたら
.NETの話だったのかw
297: 2018/09/17(月)12:34 ID:yaPtorLJ(6/7) AAS
個人的には、C++やx87 FPUは割と知識があったけど、.NET関連は余り追いかけてなかったので、気づくのが遅れた。
managedコード、unmanagedコードについて、今回初めて調べてみたくらいだし。
298: 2018/09/17(月)12:53 ID:yaPtorLJ(7/7) AAS
>>292
「ID:dj7qSZnZ」の人は理解していないね。
彼は人の事馬鹿にしてるけど・・・。
299: 2018/09/17(月)13:39 ID:F2vzl5VC(1) AAS
最初に指摘されたことだろうに。
アセンブラレベルで精度や効率に介入したきゃ.netなんて使うな、なんて分かりきったこと。
300(1): 2018/09/17(月)14:58 ID:zCVYDMXL(1/2) AAS
エディタ使ってるとたまに Intellisense機能が効かないときがあるんだが
あれなんなの？
中間ファイルとか消せば直るの？
上下前次1-新書関写板覧索設栞歴
あと 14 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s