Re: Why does activex control run 3x+ faster in vb5 than .net?

Tech-Archive recommends: Fix windows errors by optimizing your registry

Spam Catcher wrote:
"Robert" <no@xxxxxxxx> wrote in
news:uq4aNSd$GHA.1224@xxxxxxxxxxxxxxxxxxxx:

Funny how you trimmed your original post where you mentioned VB is
compiled but .net is not...

I did not say .NET does not compile code. I said .NET does not compile NATIVE code.

True, it compiles MSIL, as mentioned tons of times in this thread.


Also, FYI, VB1-VB6 all had interpreters. VB5, and VB6 were the only
ones with
compilers, so saying VB was compiled, is technically, ummm, WRONG.

AFAIK, VB5 & 6 provided an option to compile code into native CPU code. The OP was using VB5 hence I said VB was natively compiled in context of VB5 (and the OP's project).

The compile option of VB5 & 6 gave a max of 20% performance boost compared to the interpreted versions. Looks like a good interpreter works almost as fast as a bad compiler.


Do you claim that the JIT'er is not part of .Net?

I never mentioned JIT in my original post. Native code and MSIL compiled code is not the same thing - Native code can be more or less be directly executed on the CPU while MSIL requires the extra step of gothrough the JIT. Hence the code is not native.

So I don't get where I went wrong?


here: JIT compiling is the same as normal compiling. The only difference is that with a "normal" compiler, the complete application is compiled before it is run for the first time and with JIT compiling, a method is compiled when it is first run. After a method has been JITted, it will not be compiled again - it is native code.
So the only performance hit JIT is giving, is that the methods are compiled at the first time they are called. All calls after this first one do not have this performance hit.

Anyways at the crux of our debate is whether or not .NET generates native cpu code right? AFAIK, it generates MSIL NOT native CPU code.

Regardless of what you want to say - MSIL is NOT native code. Managed ..NET code perhaps - but definately NOT native code.

I don't get where I went wrong with that interpretation.


You went wrong with the assumption that it doesn't run as native code.
There is never any MSIL executed. There is also no interpreter that executes .net. There is only a just in time COMPILER that compiles the code to NATIVE code at the moment that it is first needed.

.

Relevant Pages

  • Re: Why does activex control run 3x+ faster in vb5 than .net?
    ... it generates MSIL NOT native CPU code. ... of what you want to say - MSIL is NOT native code. ... I don't get where I went wrong with that interpretation. ... There is only a just in time COMPILER that compiles the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: optimized code
    ... > loop invariants are handled by the JIT not by the compiler fron-ends. ... generates the best optimized MSIL of any of the .NET languages. ... standard native code optimizations on MSIL code. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why does vb 6 seem to be getting more expensive?
    ... Native code the first time it is executed at runtime - for the rest of the ... then it passes it off to the JIT compiler. ... when the method is called execution jumps directly to the ... The point is that .NET apps are NOT interpreted. ...
    (microsoft.public.vb.general.discussion)
  • Re: VB6, VB2005, or Something Else?
    ... The compiler generates the name mangling under the hood, or if you export these functions in a DLL. ... However you cannot use them safely from another language or other compiler vendors. ... As soon as you update to the new compiler it would either break compatibility or would have 2 name mangling hierarchies - internal and COM name mangling - which surely would lead to let's say interface mangling hell - in analogy to the DLL hell. ... E.g. the C++ compiler will emit native code, where it's not possible to generate IL code. ...
    (microsoft.public.vb.general.discussion)
  • Re: any JIT compilers for Prolog?
    ... to WAM bytecode and saves it in a file.wic ... in it were further compiled to native code (on Sparc ... I wouldn't name the above JIT: it is just a staged compiler whose last ...
    (comp.lang.prolog)