Datasheet

You should note that the platform independence of .NET is only theoretical at present because, at the time

of writing, a complete implementation of .NET is only available for Windows. However, a partial imple-

mentation is available (see, for example, the Mono project, an effort to create an open source implementation

of .NET, at

www.go-mono.com).

Performance Improvement

Although we previously made comparisons with Java, IL is actually a bit more ambitious than Java byte

code. IL is always Just-in-Time compiled (known as JIT compilation), whereas Java byte code was often

interpreted. One of the disadvantages of Java was that, on execution, the process of translating from Java

byte code to native executable resulted in a loss of performance (with the exception of more recent cases,

where Java is JIT compiled on certain platforms).

Instead of compiling the entire application in one go (which could lead to a slow startup time), the JIT com-

piler simply compiles each portion of code as it is called (just in time). When code has been compiled once,

the resultant native executable is stored until the application exits, so that it does not need to be recompiled the

next time that portion of code is run. Microsoft argues that this process is more efficient than compiling

the entire application code at the start, because of the likelihood that large portions of any application code

will not actually be executed in any given run. Using the JIT compiler, such code will never be compiled.

This explains why we can expect that execution of managed IL code will be almost as fast as executing

native machine code. What it doesn’t explain is why Microsoft expects that we will get a performance

improvement. The reason given for this is that, because the final stage of compilation takes place at runtime,

the JIT compiler will know exactly what processor type the program will run on. This means that it can

optimize the final executable code to take advantage of any features or particular machine code instruc-

tions offered by that particular processor.

Traditional compilers will optimize the code, but they can only perform optimizations that are independ-

ent of the particular processor that the code will run on. This is because traditional compilers compile to

native executable before the software is shipped. This means that the compiler doesn’t know what type

of processor the code will run on beyond basic generalities, such as that it will be an x86-compatible

processor or an Alpha processor. Visual Studio 6, for example, optimizes for a generic Pentium machine,

so the code that it generates cannot take advantage of hardware features of Pentium III processors. On

the other hand, the JIT compiler can do all the optimizations that Visual Studio 6 can, and in addition it

will optimize for the particular processor that the code is running on.

Language Interoperability

The use of IL not only enables platform independence; it also facilitates language interoperability. Simply

put, you can compile to IL from one language, and this compiled code should then be interoperable with

code that has been compiled to IL from another language.

You’re probably now wondering which languages aside from C# are interoperable with .NET, so the fol-

lowing sections briefly discuss how some of the other common languages fit into .NET.

Visual Basic 2005

Visual Basic .NET 2002 underwent a complete revamp from Visual Basic 6 to bring it up to date with the

first version of the .NET Framework. The Visual Basic language itself had dramatically evolved from

VB6, and this meant that VB6 was not a suitable language for running .NET programs. For example, VB6

Chapter 1: .NET Architecture

24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 5