about the Just-In-Time(JIT) compiler

[Tony Johansson]

Hello!

I just wonder when the JIT compiler is processing to native code which
occurrs when the code is accessed is this native code saved somewhere. Or is
it doing some kind of interpretation from the MSIL to native code every time
you access the code.

The exe file that is used by the JIT is in MSIL.

//Tony

 

[Cor Ligthert[MVP]]

Why?

It should not botter us.

I cannot assume that .Net is a old time verhicle that first tries to compile
the intermidiate language.
Does 2 instructions and then stops because that was the only thing that had
to be executed that time.

AFAIK is .Net always compiling Just In Time

Cor

 

[Hans Kesting]

Tony Johansson explained on 9-4-2009 :

Hello!

I just wonder when the JIT compiler is processing to native code which
occurrs when the code is accessed is this native code saved somewhere. Or is
it doing some kind of interpretation from the MSIL to native code every time
you access the code.

The exe file that is used by the JIT is in MSIL.

//Tony

As far as I understand, the JIT is used the first time a method is
called. The result (native code) is stored "somewhere" and used the
next time that method is called.

But I think the native code is only stored for this particular instance
of the application, if you start the application again the JIT may need
to compile it again. Code that is stored in the GAC may work
differently in this respect.

Hans Kesting

 

[Ben Voigt [C++ MVP]]

As far as I understand, the JIT is used the first time a method is

called. The result (native code) is stored "somewhere" and used the
next time that method is called.

But I think the native code is only stored for this particular
instance of the application, if you start the application again the
JIT may need to compile it again. Code that is stored in the GAC may
work differently in this respect.

The JIT-compiled native code is never persisted. But there is a tool called
"ngen" which compiles MSIL to native code and saves the result to disk,
saving the JIT step on subsequent execution.

 

[Göran Andersson]

Hello!

I just wonder when the JIT compiler is processing to native code which
occurrs when the code is accessed is this native code saved somewhere. Or is
it doing some kind of interpretation from the MSIL to native code every time
you access the code.

The exe file that is used by the JIT is in MSIL.

//Tony

If the JIT compiler would create code that would be possible to save
anywhere, it would have to create linkable code, and we would need a JIT
linker also...

 

[Michael B. Trausch]

The JIT-compiled native code is never persisted. But there is a tool
called "ngen" which compiles MSIL to native code and saves the result
to disk, saving the JIT step on subsequent execution.

Yes, but doesn't NGEN create "safer" binaries; that is, the AOT process
used by NGEN provides far less aggressive optimizations than the JIT
will on the same system? Obviously, this would be more true over an
extended time, if the user upgrades processor families or whatever,
than it would be otherwise, but it seems that it's just fine to use the
JIT; I certainly don't suffer any performance issues using it. But if
you NGEN an assembly on a system, and upgrade the processor to
something newer that the JIT can generate more efficient instructions
for at run-time, don't you lose the benefits of NGEN?

--- Mike

 

[Ben Voigt [C++ MVP]]

Yes, but doesn't NGEN create "safer" binaries; that is, the AOT process
used by NGEN provides far less aggressive optimizations than the JIT
will on the same system? Obviously, this would be more true over an
extended time, if the user upgrades processor families or whatever,
than it would be otherwise, but it seems that it's just fine to use the
JIT; I certainly don't suffer any performance issues using it. But if
you NGEN an assembly on a system, and upgrade the processor to
something newer that the JIT can generate more efficient instructions
for at run-time, don't you lose the benefits of NGEN?

Theoretically some optimizations are available to the JIT that aren't
available to NGEN. But NGEN also doesn't need to run as often or as
quickly, so it can do a lot deeper code analysis.

Practically speaking, I think the JIT and NGEN use the same set of
optimizations, fast and not using processor-specific tuning. Of course
that's subject to change in future versions.

 

[Michael B. Trausch]

Practically speaking, I think the JIT and NGEN use the same set of
optimizations, fast and not using processor-specific tuning. Of
course that's subject to change in future versions.

Steve McConnell [Microsoft Press] seems to think that the .NET
framework optimizes for each CPU. I don't personally know about
Microsoft's implementation of the CLR, but I *do* know that Mono's JIT
takes the processor family into account when generating code and
optimizing. The JIT will create very different code for my CPU than
for an early-model Intel Pentium 4, even if my CPU were running in
32-bit mode. In some cases, it's even possible for programs being run
under JIT to run faster than statically optimized C programs written
and compiled with GCC (which is quite impressive, IMHO).

I did some benchmarks once upon a time, though I seriously need to
update that with the current software. I'd be interested to see
how runtime performance on .NET's JIT compares with AOT compilation
there. That said, I'd actually need to borrow my girlfriend's laptop
for that, she's the only person I know first-hand who still runs
Windows...

--- Mike

 

[Ben Voigt [C++ MVP]]

Practically speaking, I think the JIT and NGEN use the same set of
optimizations, fast and not using processor-specific tuning. Of
course that's subject to change in future versions.

Steve McConnell [Microsoft Press] seems to think that the .NET
framework optimizes for each CPU. I don't personally know about

I always thought that was just "things enabled by managed code execution
environments" rather than a description of the deployed CLR. But I could be
wrong.

Anyway, there's no reason for NGEN not to do those same processor-specific
optimizations. After all, you always have the MSIL available, so if it did
get moved to a different CPU (or one of the dependencies has a version
mismatch), you can just ignore the native image and let the JIT do its
thing. There's no reason that precompilation of managed code should ever
generate code inferior to the JIT. Even things like speculative inlining
can be done, knowing that there's a JIT available to fix it if the
assumptions were wrong (and record a profile for use the next time NGEN is
run).

 

[Arne Vajhøj]

Yes, but doesn't NGEN create "safer" binaries; that is, the AOT process
used by NGEN provides far less aggressive optimizations than the JIT
will on the same system?

Usually less optimization means fewer bugs.

But given the high quality of the .NET CLR, then I don't think
there is much need to hold back on optimization.

Arne

 

[Michael B. Trausch]

Usually less optimization means fewer bugs.

But given the high quality of the .NET CLR, then I don't think
there is much need to hold back on optimization.

Rarely have I found automatic optimizations to be troublesome WRT buggy
behavior, although they _do_ make debugging issues hard. It's
extremely difficult to figure things out when a program is built
natively and many variables are optimized out.

I haven't actually run Microsoft's CLR implementation regularly, since
I don't have access to it, but I'd wager that the Mono CLR is pretty
well on par in terms of quality; it's very hard to tell the difference
between CLR applications and native ones in terms of performance and
responsiveness. The only obvious indication that an application is
running in the CLR (if it isn't using GTK#, that is), is that WinForms
look like WinForms.

--- Mike

 

[Arne Vajhøj]

Practically speaking, I think the JIT and NGEN use the same set of
optimizations, fast and not using processor-specific tuning. Of
course that's subject to change in future versions.

Steve McConnell [Microsoft Press] seems to think that the .NET
framework optimizes for each CPU. I don't personally know about

I always thought that was just "things enabled by managed code execution
environments" rather than a description of the deployed CLR. But I
could be wrong.

Anyway, there's no reason for NGEN not to do those same
processor-specific optimizations. After all, you always have the MSIL
available, so if it did get moved to a different CPU (or one of the
dependencies has a version mismatch), you can just ignore the native
image and let the JIT do its thing. There's no reason that
precompilation of managed code should ever generate code inferior to the
JIT. Even things like speculative inlining can be done, knowing that
there's a JIT available to fix it if the assumptions were wrong (and
record a profile for use the next time NGEN is run).

It could.

But if the magic trick for AOT is to be able to fall back
to JIT then ...

Arne

 

[Arne Vajhøj]

Rarely have I found automatic optimizations to be troublesome WRT buggy
behavior, although they _do_ make debugging issues hard. It's
extremely difficult to figure things out when a program is built
natively and many variables are optimized out.

I haven't actually run Microsoft's CLR implementation regularly, since
I don't have access to it, but I'd wager that the Mono CLR is pretty
well on par in terms of quality; it's very hard to tell the difference
between CLR applications and native ones in terms of performance and
responsiveness.

At least on Windows the performance on Mono is way behind MS .NET !

Arne

 

[Michael B. Trausch]

At least on Windows the performance on Mono is way behind MS .NET !

Have you tried with the latest release of Mono, which includes a better
JIT than the 2.0 version (and I think 2.2 version) did? I don't run
the 32-bit JIT since I run an x86-64 system, so in theory there are
differences possible. Also, I suppose there may be differences in the
OS, since Mono does use POSIX at a lower level... I don't know how much
of that is conditionally compiled with more efficient Win32 API calls
or perhaps emulated.

--- Mike

 

[Arne Vajhøj]

Have you tried with the latest release of Mono, which includes a better
JIT than the 2.0 version (and I think 2.2 version) did?

Tested with 2.4.

I don't run
the 32-bit JIT since I run an x86-64 system, so in theory there are
differences possible. Also, I suppose there may be differences in the
OS, since Mono does use POSIX at a lower level... I don't know how much
of that is conditionally compiled with more efficient Win32 API calls
or perhaps emulated.

The code was strictly number crunching no system calls at all.

Arne

 

[Michael B. Trausch]

Tested with 2.4.


The code was strictly number crunching no system calls at all.

Interesting. Will have to re-run some of my Euler tests that I did
once upon a time... I compared Mono 2.0 to gcc (GNU C compiler) and it
was pretty fast at least on Linux. I can't test on Windows though.
That said, should I get the chance... what's the standard C compiler
for Windows, and is it part of any freely available SDKs?

--- Mike

 

[Ben Voigt [C++ MVP]]

Interesting. Will have to re-run some of my Euler tests that I did
once upon a time... I compared Mono 2.0 to gcc (GNU C compiler) and it
was pretty fast at least on Linux. I can't test on Windows though.
That said, should I get the chance... what's the standard C compiler
for Windows, and is it part of any freely available SDKs?

Microsoft Visual C++ now in version 2008 (there's a free "Express Edition")
GCC is also available for Windows.

 

[Arne Vajhøj]

Interesting. Will have to re-run some of my Euler tests that I did
once upon a time... I compared Mono 2.0 to gcc (GNU C compiler) and it
was pretty fast at least on Linux.

With proper optimization options?

GCC does not optimize that hard default.

I can't test on Windows though.
That said, should I get the chance... what's the standard C compiler
for Windows, and is it part of any freely available SDKs?

You can get GCC for Windows. In two flavors: MingW for pure Windows
programming, Cygwin for *nix emulation (it comes with bash and so on).

MS .NET (and the framework itself is free) comes with all the
compilers incl. C/C++. The Visual C++ Express Edition is also
free.

Arne

 

[Michael B. Trausch]

Microsoft Visual C++ now in version 2008 (there's a free "Express
Edition") GCC is also available for Windows.

Is that the command line compiler? And I assume that, despite the
name, it has a C99 mode?

--- Mike

 

[Michael B. Trausch]

With proper optimization options?

GCC does not optimize that hard default.

Aye, I compared standard Mono JIT optimizations to standard GCC
optimizations (and when I say "standard", I mean -O2, as that is what
most distributions use; -O3 and above is considered to be not
recommended and unsafe, and -Os isn't frequently used except in special
circumstances).

You can get GCC for Windows. In two flavors: MingW for pure Windows
programming, Cygwin for *nix emulation (it comes with bash and so on).

MS .NET (and the framework itself is free) comes with all the
compilers incl. C/C++. The Visual C++ Express Edition is also
free.

If I were going to do the test on Windows, I would be testing the CLR
vs. the dominant compiler for the platform. I think it would be nice,
though, to compare Mono on Win32 with gcc on Win32, Mono on Win32 with
Mono on Linux, Mono on Win32 with Microsoft's C99 compiler, and then
all the Win32 ones for Microsoft's CLR. Perhaps at some point...

--- Mike