Re: Can you write code directly in CIL ???

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


"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1e1c4beb9854708598cbf0@xxxxxxxxxxxxxxxxxxxxxxx
> Peter Olcott <olcott@xxxxxxx> wrote:
>> > How much more performance do you need? Have you tried doing the
>> > conversion and seeing how it performs *without* tweaking?
>>
>> The fastest algorithm with the best compilation just barely meets my target.
>> This is with MS Visual C++ 6.0. The project requirements call for a .NET
>> component. If I could double the speed of this I would be very pleased. In
>> any
>> case more recent compilers do not meet my target even with the best
>> algorithm,
>> so I must do at least as well as the best compiler. This should only be a
>> matter
>> of translating the generated assembly language from the best unmanaged code
>> into
>> CIL.
>
> No - because CIL looks pretty different from assembly language, and
> even if you generated similar-looking CIL somehow, there's no guarantee
> that would then be JITted to the same assembly code.
>
> The performance improvement you'll get from this step, if any, is
> likely to be tiny (don't hang on to the idea of doubling the speed -
> that was a very particular case) and an awful lot of work. I'd do the
> initial conversion to C# and benchmark that *first*.

Well of course I would do that first. The only reason that I am considering this
step is because with the unmanaged C++ compilers the change between 6.0 to 7.0
resulting in doubling of the time. In other words the newer compiler produces
code that is only half as fast as the older compiler. The code that I am talking
about doesn't have any OS calls or memory management. It is just comparisons,
branches and movement of integers. The tweaking that I am talking about would
merely be to shorten the lengths of the execution paths. Fewer instructions in
the execution paths would have to result in at least somewhat faster code. If I
could cut down the weighted average length of the execution paths in half, this
would result in doubling of the speed. Most every simple instruction only takes
a single clock. Some instructions can now be paired to execute concurrently. I
will probably look into this sort of optimization as well. This would only
involve changing the order of some instructions. I figure that in the worst case
scenario I will be able to achieve the same speed as the best compiler. For
example if the best compiler is VC++ 6.0, unmanaged code, and if 2005 C#
compiler produces code that takes 500% longer to execute, I can force the .NET
code to execute just as fast as the VC++ 6.0 unmanaged code. I would only bother
to do this for this critical 100 line function. I actually expect to be able to
do better than this. I would expect to improve performance at least 50%.
>
> --
> Jon Skeet - <skeet@xxxxxxxxx>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too


.

Relevant Pages

  • Re: Warning to newbies
    ... compiler to detect. ... Probably a better approach would be a constraint specification ... It would require defining "all possible execution paths", ... A compiler could omit the abort() ...
    (comp.lang.c)
  • Re: Register keyword and "as if" rule...
    ... to bother with register is that modern compilers are far better at deciding what to put into registers than the vast majority of programmers. ... I would rather the compiler honor the request when made so that the careful programmer has the opportunity to improve his generated code. ... the relative frequency of execution paths, which may be important for choosing the proper register allocation. ...
    (comp.lang.c)
  • Re: Simple stack problem
    ... In that case the effects of the faulty code may only exhibits itself after something (OS, compiler, compiler settings, seemingly unrelated code, new library version...etc) has changed. ... Recently we had code that ran fine on Linux and passed all unit tests, but a debug build of the same code crashed on Windows. ... With the Windows debug library free operation overwrites the freed memory with a certain pattern, ... Covering all execution paths is near impossible for non-trivial code, unless one resorts to advanced static code analysis tooling like Coverity. ...
    (comp.arch.embedded)
  • Re: IntToStr B&V v0.4 on attachments
    ... it seems like that to the compiler). ... >From the compiler POV there are possible execution paths in which rp is ... which results in the warning. ... preferable to have the contestants compile with no warnings. ...
    (borland.public.delphi.language.basm)
  • Re: optimation, a black art?
    ... RISC is no less problematic - the MIPS architecture almost failed ... initially because it depended too much on the compiler for scheduling ... instructions regardless of whether the branch was taken. ... blocks and scheduled execution. ...
    (comp.lang.lisp)