Don’t assume the worst, .NET vs. native C++ STL

Rico Mariano took a C++ STL sample created by Raymond Chen and converted it to .NET. When comparing the performance of the line by line converted .NET to the original C++ version .NET won!
 
Raymond made improvements and was able to make the C++ application outperform .NET but at quite some cost by rewriting slow functionality in the STL.
 
Don’t assume the worst just because .NET is a platform compiled to IL and then JIT’ed to native before beeing run. Microsoft probably has far more resources working on making the .NET platform run as fast as possible compared to what anyone else has to optimize a native C++ application.

Don’t assume the worst, trust the compiler

I am interested in security so when I saw a link on MSDN to a interview with Michael Howard on Port 25 I saw it as a nice opportunity to learn more about security in Vista.
 
Around 16:48 into it he mentions not to assume the worst and tells about an example on overflow issue and how the CPU knows it can happen so the code can check on it with the carry/overflow flags. He wrote an implementation in assembly, 560 byte. David LeBlanc co-authored a C++ template that weighed in at around 50k.
 
They ended up measuring the difference and the C++ template is faster!
 
When Michael asked some on the the reply back was that he was a moron. 🙂
 
What is the explanation? The C++ compiler has many years of work to make it compile into great optimized code, if is quite difficult to beat the experience and knowledge that are in the compiler and its optimizer.
 
Don’t assume the worst and start optimizing too early. When in doubt, stop and test, measure and compare different approaches.
 
Check out the interview.

Floating point artithmetic and optimized .NET assemblies.

If you are familiar with floating point arithmetic you are aware that the number you set it to is most likely not stored as exactly what you set it to but a number very close to it. It will not be good for exact calculations like financial but might be suitable for others.
 
If you are familiar with the MS C++ compiler you might know about the /fp compiler option.This lets you control the compilers optimization when it comes to floating point arithmetic. They might differ and you are most likely aware of it as you can control it.
 
If you use C# compiler you basically have a single compiler option to optimize or not. In the remarks you will note:
/optimize also tells the common language runtime to optimize code at runtime.
 
What this does to the JIT is to use same optimizations as /fp:strict (or precise) when it is not an optimized build and /fp:fast when optimized.
 
For specified C# floating point arithmetic both not optimized and optimized compile generates the same immediate language assembler but the JIT will choose different paths dending on the optimize flag.
 
Apparantly this is by design in the .NET/JIT side and is just something you need to be aware of.

Why I beta test Windows Vista

I recently installed Windows Vista as my only installed operating system. As a developer I want to get heads up on things and as soon as it was a public beta I started to backup all data to prepare to install.
 
It took me two installations to get it working so I could use it. I removed a network card that I wasn’t using anyway. It works well. I had some issues that both the nVidia and windows driver confuser the connected TV with my monitor but I seem to have worked around that issue by using the DVI output with an adapter instead of the VGA output.
 
At first I was really feeling that the user interface was not really for me. It took me a few years to start using the default XP UI even though I have used it since 2001 with the Win2K interface. The reason I want to get used to the default settings is that I want to be able to reinstall a computer and not have to spend hours tweaking it back to what I want.
 
I choose to beta test Vista as I most likely will upgrade and if I can catch issues and give feedback to microsoft now I might help me and others to get a better finished product.