Re: optimized code

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:%23du0Hvz%23FHA.1336@xxxxxxxxxxxxxxxxxxxxxxx
> All depends on what exactly you are measuring , how you are comparing and
> what you are expecting.
> But suppose we are talking about code generated by MSFT VS2005 C#, C++ and
> C++/CLI, first, you should understand that you are basically using the
> same math library (the CRT library) for all three. That means that the
> results should be comparable for both C# and C++/CLI, and that C++ should
> take advantage of the back-end optimizer which can do a better job than
> the JIT compiler.
> Anyway what I have measured so far using VS2005, is a slight advantage (<
> 5%) for C++/CLI over C# and a larger advantage (<20%) for C++ oner C#.
>
> The difference between C# and C++/CLI is due to a better optimized IL
> produced by the C++ compiler, when enabling max. optimizations (enables
> the fastest FP unit mode).
> The difference between managed and unmanaged C++ is due to the extra
> redirection (through the CLR) between managed code(well, JIT'd ) and the
> math library.
> Note that your mileage may vary, therefore, I would suggest you do your
> homework, run some benchmarks, compare and make a language decision. Note
> however, that performance should never be the only criterion to select a
> development language (or platform). Remember faster is not always better,
> especially when talking about FP arithmetics.

I'd think inner-loop FP code could win even more if branch reduction due to
loop unrolling and other factors, and better register allocation, was able
to reduce the time between calls, keeping the integer and FP piplelines as
full as possible. But I guess the new processors do a reasonable job of
magically looking ahead and doing many things at once too, so at some point
further front-end opimizations may not help at all.

>
>
> Willy.
>
>
> "Fred Mellender" <nospamPlease_fredm@xxxxxxxxxxxxxxx> wrote in message
> news:YTxlf.702$EE4.354@xxxxxxxxxxxxxxxx
>> Can anyone comment on C# vs. C++ for floating point performance with V2?
>>
>> In
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
>> we
>> read:
>>
>> "Floating Point-The v1 JIT does not currently perform all the FP-specific
>> optimizations that the VC++ backend does, making floating point
>> operations more expensive for now. "
>>
>> Has this been improved? Can anyone quantify the difference in
>> performance. I have a highly computation-intensive program written in C#
>> and wonder what the difference would be if I were to rewrite in C++.
>>
>> "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
>> news:uhWpH9r%23FHA.2472@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>>> "Daniel O'Connell [C# MVP]" <onyxkirx@xxxxxxxxxxxxxxxxxxxxx> wrote in
>>> message news:eNZ5Ljq%23FHA.1676@xxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> "Mike" <vimakefile@xxxxxxxxx> wrote in message
>>>> news:Oj7acNp%23FHA.2424@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Is it still true that the managed C++ compiler will produce much
>>>>> better opimizations than the C# compiler, or have some of the more
>>>>> global/aggressive opimizations been rolled into the 2005 compiler?
>>>>>
>>>>
>>>> Yes, the Managed C++ compiler should still be better. the C# compiler
>>>> still doesn't go very far as far as optimizations go, AFAIK anyway.
>>>> They are left to the JIT.
>>>>
>>>>
>>> The same applies to the "managed C++" compiler, common sub-expressions
>>> and loop invariants are handled by the JIT not by the compiler
>>> fron-ends.
>>> The managed C++ compiler generates IL, sometimes it does a better job,
>>> but I've seen IL code that was better optimized by the C# compiler.
>>> Anyway the differences are < 5% (both sides), MS said that they will
>>> focus on the JIT to further optimize, not in the C++ front-end.
>>>
>>>
>>> Willy.
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)
  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: [EGN] Numerical Accuracy
    ... which has been pointed out to you before in this forum. ... The capabilities of the optimizer are not so ... I suspect your own compiler can't do it either, ... first year programming courses teach students to not place ...
    (comp.programming)
  • Now rather OT: Assembler etc... [Was Re: Put out to Pasture ?]
    ... Checkout compiler in 1970. ... prefixes IEL and IEN that had once been allocated to the PL/I and compilers. ... was a subset that was replaced by the DOS Optimizer. ... Actually, I suspect that the Assembler that you are referring to, while it has an 'H' in the acronym is actually the "High Level Assembler" not an 'H-Level' Assembler. ...
    (comp.lang.pl1)
  • Re: Pedants
    ... However Jacob publishes only his binaries. ... I would be interested to see what you think you are comparing against ... were compiled by the same compiler program and with identical compiler ... PUSH ...
    (comp.lang.c)