Whidbey brings 64-bit .NET
One of the often overlooked advantages of the .NET platform when compared to traditional compiled code is that JIT-ed code can be optimized at run time, vs. compile time.
For example, let’s say I write a new program, we’ll call it super-notepad. I make two versions of it, one in C++, and another in any .NET capable language. We’ll call the two programs NativeNotePad and .NETnotePad.
With Native Notepad, I can only take advantage of CPU specific optimizations that my specific compiler currently supports. Why is this important?
The 64 bit platform is in the near future. Instead of spending a lot of time spelunking through code to re-engineer my memory manipulation, and any pointer arithmetic I wasn’t CPU-agnostic in writing, I can compile once, run on any Windows platform. It doesn't quite meet Java's promise of platform agnostication, but it's a big step.
With JIT code, the vendor (Sun or Microsoft) makes an implicit promise that your code is portable into the future. While Microsoft may promise that your native 32 bit applications still run on a 64 bit platform, they will normally still have to hit a ‘thunking’ layer, with the associated steep performance impact. Anyone still working with 16 bit applications and the NTVDM will completely understand. With .NET, there should be no such thunking. I would expect that .NET applications will run far faster than 32-bit apps in 64 bit land. We’ll find out soon, as .NET 64 bit support will be available in Whidbey.
Sometimes I really wonder why more windows desktop developers aren’t working in .NET. It will certainly save a world of work porting their old applications to a new CPU architecture.
.NETnotePad means not as much as even a recompile. It’s Microsoft’s job to make certain that 64 bit .NET “just works”.