1

Topic: Stupid compiler MSVC 15.5.5

Optimization on a maximum. Like / permissive-/GS/GL / analyze-/W3/Gy/Zc:wchar_t/Zi/Gm/Ox/Ob2/sdl/Fd "Release\vc141.pdb"/Zc:inline/fp:fast/D "WIN32"/D "NDEBUG"/D "_WINDOWS"/D "_CRT_SECURE_NO_DEPRECATE"/D "TBAL_HORIZONTAL"/D "_USE_MATH_DEFINES"/errorReport:prompt/GT / WX-/Zc:forScope/arch:IA32/Gd / Oy-/Oi/MD/Fa "Release \"/nologo/Fo "Release \"/Ot/Fp "Release\Rounds.pch"/diagnostics:classic the filling Code: template <typename F> void FastFill (F&& f, Context3d& context, int x1, int y1, int x2, int y2, int16_t z, tbal:: Color color) {tbal:: Bitmap:: Line l = context.bitmap [y1]; ZBuffer:: Line lz = context.zbuffer [y1]; HZBuffer:: Line lhz = context.hzbuffer [y1>> HZSHIFT]; for (int j=y1; j <y2; ++ j) {for (int i=x1; i <x2; ++ i) {if (f (lz [i])) {l [i] = color; lz [i] = z; - lhz [i>> HZSHIFT];} } context.bitmap. ProcessLine (l); context.zbuffer. ProcessLine (lz); if ((j& (HZSIZE-1)) == HZSIZE-1) {context.hzbuffer. ProcessLine (lhz);}}} the Exterior code causing this filling: if (context.zorder) {FastFill ([] (int16_t curz) {return curz <0;}, context, x1, y1, x2, y2, 0x7fff-int16_t (1000.0f/midz), cube.color);} else {FastFill ([] (int16_t curz) {return curz> 0;}, context, x1, y1, x2, y2, int16_t (1000.0f/midz)-0x7fff, cube.color);} I launch, I come in  to look at a beloved inner loop. I find a place which very similar, simply I know that HZSHIFT it is 3, therefore sar eax, 3 hints. Besides it is used to make dec to the address. Well  it it. 009C5DC7 cmp word ptr [esi+ebx*2], 0 009C5DCC jge DrawCube+1C8h (09C5DF8h) 009C5DCE fld st (0) 009C5DD0 mov dword ptr [eax+ebx*4], ecx 009C5DD3 fdiv st, st (2) 009C5DD5 call _ftol2_sse (09C9D70h) 009C5DDA mov edx, dword ptr [x2] 009C5DDD mov ecx, 7FFFh 009C5DE2 sub cx, ax 009C5DE5 mov eax, ebx 009C5DE7 sar eax, 3 009C5DEA mov word ptr [esi+ebx*2], cx 009C5DEE mov ecx, dword ptr [ebp-58h] 009C5DF1 dec word ptr [edi+eax*2] 009C5DF5 mov eax, dword ptr [ebp-4Ch] 009C5DF8 inc ebx 009C5DF9 cmp ebx, edx 009C5DFB jl DrawCube+197h (09C5DC7h) THAT?! It calculation of the argument made from the outside of function, thrust directly  an internal cycle?! WHAT?! WHAT IS IT?!?!?!

2

Re: Stupid compiler MSVC 15.5.5

Well  and what should not?

3

Re: Stupid compiler MSVC 15.5.5

Hello, reversecode, you wrote: R> well  and what should not? It calculation of the argument made from the outside of function, thrust directly  an internal cycle! It not "well ". A difference you feel?

4

Re: Stupid compiler MSVC 15.5.5

Hello, T4r4sB, you wrote: TB> Optimization on a maximum. Like/Ox replace on/O2 the Maximum speed here these flags:/GA / GS-/fp:fast/O2/GF/GL/Gw In /LTCG/OPT:REF/OPT:ICF=3 in the end it is possible to try to replace Triple on 4 and even on 5. Compile time grows very abruptly, but he will search more variants. And that that at you there is written - nonsense any.

5

Re: Stupid compiler MSVC 15.5.5

Hello, rean, you wrote: R> Hello, T4r4sB, you wrote: TB>> Optimization on a maximum. Like R>/Ox replace on/O2 Yes, with/O2 such trick is not present. That is "Full optimization" actually on speed is worse, than "Optimize speed"?

6

Re: Stupid compiler MSVC 15.5.5

R>>/Ox replace on/O2 TB> Yes, with/O2 such trick is not present. That is "Full optimization" actually on speed is worse, than "Optimize speed"? Full means balance of speed with code size. That you also watch. To make  the code it and optimized it For MS/O2 - absolute speed.

7

Re: Stupid compiler MSVC 15.5.5

Hello, rean, you wrote: R>>>/Ox replace on/O2 TB>> Yes, with/O2 such trick is not present. That is "Full optimization" actually on speed is worse, than "Optimize speed"? R> Full means balance of speed with code size. That you also watch. To make  the code it and optimized it R> For MS/O2 - absolute speed. In a pancake, did not know. All right, it I stupid.

8

Re: Stupid compiler MSVC 15.5.5

Hello, T4r4sB, you wrote: TB> THAT?! It calculation of the argument made from the outside of function, thrust directly  an internal cycle?! WHAT?! WHAT IS IT?!?!?! A problem not in that that it stupid, and that it with the closed source codes. Be at you such problem with the normal compiler (llvm, gcc) it would be possible to look and explain to you that there as, especially if there is a simple playback. And so it is necessary to eat a cactus. Well, did not carry out an invariant, .

9

Re: Stupid compiler MSVC 15.5.5

Hello, Tilir, you wrote: T> Well, did not carry out an invariant, . You did not understand. It not "did not carry out" an invariant. It BROUGHT it. Look, at me in the code the variable is considered number outside of a cycle, in a cycle only!

10

Re: Stupid compiler MSVC 15.5.5

Hello, rean, you wrote: R> Full means balance of speed with code size. That you also watch. To make  the code it and optimized it R> For MS/O2 - absolute speed. It is not true:/Ox is:/Og/Oi/Ot/Oy/Ob2/02 is:/Og/Oi/Ot/Oy/Ob2/Gs/GF/Gy Where:/Gs controls stack checking calls/GF eliminates duplicate strings/Gy does function level linking MSDN Thus/Ox - potentially faster

11

Re: Stupid compiler MSVC 15.5.5

Calculation all normally is brought in a cycle, and the external variable is transferred from out of a panic at all I do not understand as though the first time  look

12

Re: Stupid compiler MSVC 15.5.5

Hello, reversecode, you wrote: R> all is normal R> calculation It is brought in a cycle lawfully? I understand, old compilers were not able to carry out repeating calculation outside. Then there were the compilers, which steels it to carry out. But that already hands the carried out calculation to push reversely inside? _

13

Re: Stupid compiler MSVC 15.5.5

It  function arguments in  generally  for a long time was in a msec rarely saw and since recent time already and for lambdas such probably attribute __ forceinline the lambda too should leave in  inside https://developercommunity.visualstudio … sions.html

14

Re: Stupid compiler MSVC 15.5.5

Hello, reversecode, you wrote: R> it  function arguments And unless this word is called not creation separate  functions, if some arguments - known compilers of a constant? R> in  generally  for a long time was R> in a msec rarely saw R> and since recent time already and for lambdas such probably R> attribute __ forceinline the lambda too should leave in  inside R> https://developercommunity.visualstudio … sions.html And what relation has  lambdas to  calculations to expression in a cycle?

15

Re: Stupid compiler MSVC 15.5.5

R>> Full means balance of speed with code size. That you also watch. To make  the code it and optimized it R>> For MS/O2 - absolute speed. V> it is not true: V>/Ox is:/Og/Oi/Ot/Oy/Ob2 V>/02 is:/Og/Oi/Ot/Oy/Ob2/Gs/GF/Gy V> Where: V>/Gs controls stack checking calls V>/GF eliminates duplicate strings V>/Gy does function level linking V> MSDN V> Thus/Ox - potentially faster Just,/O2 potentially faster. In the first,/O2 it is better to do with / GS - that deletes stack checking and all remaining superfluous checks. In the second, attentively read that do remaining keys, thanking it it turns out faster./GF allows to hold identical lines in one place, i.e. pointers will turn out on the same place in storage that refines productivity for the account potentially more compact pool which it is possible, goes in in  the processor. It is good for the code, in what heap of small lines where often they are compared./Gy allows to place in the output object file separate functions entirely that then on a phase  it is better optimized for the account  at a stage  with /LTCG and/OPT:ICF with high value of parameter that I and recommended. In a case/Ox the compiler optimizes them once at a stage of compilation of one file and all. It turns out more compactly than when  will know about all functions. After all in case of optimization at  one function can  in others differently, all will depend on received assembly representation. Can be will to cause more favourably separately, can be will to build in more favourably. In a case with/O2 the code turns out more in size, but the finite code turn out more optimally as a result. It is very good in cases when the code part is repeatedly used some times. Therefore, in aggregate,/O2 - faster/Ox. It is necessary to look simply not in narrow area of optimization, and at all compile process and  entirely. Updates: wrote more clearly and corrected misprints.

16

Re: Stupid compiler MSVC 15.5.5

Let's return to the beginning the compiler has the right to do all that he wants if it does not break algorithm of operation of the code if breaks is a bug at you breaks? Is not present include in release the debug information and launch in studio look that as it is generated on source codes - if there is a desire to study what yes as

17

Re: Stupid compiler MSVC 15.5.5

Hello, rean, you wrote: R> In the first,/O2 it is better to do with / GS - that deletes stack checking and all remaining superfluous checks. Well here adjusted for / GS - - the difference between keys starts to aspire to zero R> In the second, attentively read that do remaining keys, thanking it it turns out faster. I read attentively, and I think, with/GF/Gy it is necessary to look attentively, already, in each specific case - the effect is not obvious. In here/O2 without / GS - it is unambiguous more slowly/Ox.