GrantRi's WebLog [MS] : C# Language

Not-so-new C# Compiler Features

grantri — Thu, 17 Mar 2005 18:24:00 GMT

So a while back somebody asked what new compiler features were coming out for Whidbey that weren't part of new language features. Well you've already heard about Edit and Continue. There's also the really cool Refactoring built into the IDE and built off of the compiler's source-code analysis. As an attempt to improve the debugging experience for those of you with 500+ default.aspx files in your solution, they've added some hashes to the PDB files and improved file lookups to the debugger. Partly to improve E&C but also to improve the overall debugging experience, the compiler has done some 'de-optimization' to the code (basically adding NOPs and storing more temporaries to locals). Don't worry none of this should impact the performance of your relase code as long as you remember to use /optimize+.

This does bring me to another question that somebody asked: what optimizations does the C# compiler do? The answer is very few. Most of them would fall into the category of flow-graph optimizations: remove branches to next, short circuit branches to branches, remove dead code, invert conditionals to eliminate branches around unconditional branches, etc. It also does very basic constant folding, although you can easily thwart this by reordering the math (e.g. "4 + 5 + a" folds to "9 + a", but "4 + a + 5" stays the same).

You might ask why the compielr doesn't do more. Well I can see 2 reasons: if the compiler optimizes too much it will make the JIT work harder to perform its optimizations and any optimization that applies ot the C# compiler should be written in a way that all compilers targeting MSIL could share. For the second reason most people prefer to put the optimization into the JIT. My personal optinion is that this was a bad choice. Why reoptimize stuff every time the code is run? NGEN helps, but wouldn't be nicer to just have a simple MSIL optimizer that performed classic dragon-book style machine independent optimizations?

Mike Montwill wrote a nice piece about the exact optimizations with real examples here.

Well enough for this post. I'm still looking for things to write about.

--Grant

[Edit: Added link to Mike's aritcle]

Some of my opinions on Generics

grantri — Fri, 31 Dec 2004 22:04:00 GMT

Disclaimer: These are all my opinions, so don't take them to mean anything more than the futile thoughts of an insignificant bystander who happened to be fortunate enough to listen to a few of the C# language design meetings and occasionally interact with some of the designers.

John and a few others have compared the CLR's generics (hereafter referred to as simply 'Generics') to C++'s templates ('Templates'). In some ways I think this is beneficial, but in other ways I think it is like comparing apples and oranges. This is my attempt to compare and contrast them and explain why I think certain comparisons are invalid.

They both allow polymorphism in a second dimension. In addition to inheritance, you now also have instantiation.
They both facilitate code reuse by allowing the programmer to write type-agnostic algorithms, while in most cases preserving the type-safety and performance of type-specific algorithms.
Templates are a compile-time mechanism, while Generics are instantiated at runtime. Along this vein, I like to think of Templates as compile-time macros on steroids. All the C++ compilers I'm aware of implement Templates entirely in the front-end, very similarly to how the preprocessor implements macros. Because of this templates can be used and abused in many ways that Generics can't.

I think most everybody will agree with me at this point. So the next major question is why did the CLR people decide to go with the 'limited' functionality of Generics instead of Templates? Well for starters, the CLR as a platform does not preclude C++ or any other language from incorporating Templates since that all happens at compile time and require no help from the CLR. Now granted there is no metadata to express templates that would make them cross-language, but as far as I know, there has never been any cross-language Templates.

John stated, "Generics seem to really answer the freshman CS collections problems while missing some of the more expressive power of C++ templates." I agree mostly with his statement. I disagree with the implied statement that Generics don't solve/answer the 'bigger real world problems that real programmers face'. First off we must remember from our CS theory classes that all computer languages are functionally equivalent. That is to say if you can do it in one of them, you can do it in all the others, but it might be significantly harder or require more work on the part of the programmer, but it is not impossible. So what are the real situations that real programmers face that Templates make easier but Generics don't (or at least not as easy)? I'm sure there are a few. The biggest one that springs to my mind is constants. I've written a few templates that take as a parameter the initial size or the size to grow. With Generics you're forced to use a readonly field to store such information. Not quite as elegant, but close enough for me until a performance test proves otherwise (in which case I'll probably look at changing algorithms first).

I personally would contend that being able to write type-agnostic collections and algorithms, that are still type-specific to the consumer really is the 90% case. Hence Generics that are really just trying to solve the freshman CS problem are solving most of the real problems. At least for now, I'm sure in a few years that will all change.

BTW John, you and I took many of the same freshman classes, and I don't remember any stuff about collections, type safety, templates or that sort of thing until at least my sophomore or junior year. Are there any colleges out there that teach that sort of stuff to first year CS students?

--Grant

More Info on Base Addresses

grantri — Thu, 30 Dec 2004 00:37:00 GMT

Another Microsoftie, Josh Williams follows my blogs and pointed out another case where a base address matters: NGEN. When you NGEN your assemblies, the new images are loaded at the same base address as the original binaries. As Josh pointed out to me, NGEN images do have significantly more relocations (similar to a real native image), and on 64-bit platforms may end up using an extra jump stub when they get rebased far away from the call targets (i.e. when a 32-bit offset no longer works). The relocations will affect load time, but the jump stubs will affect runtime performance.

--Grant

More Q&A - Why No Generic Attributes?

grantri — Wed, 22 Dec 2004 22:15:00 GMT

Question from Wes Haggard:

A while back I posted http://weblogs.asp.net/whaggard/archive/2004/10/12/241476.aspx about having a generic type inherit from Attribute. Do you know why this is prohibited in C#?

My attempted response:

I used to think it wasa a CLI restriction, but now I've scoured the docs and can't find anything like that. So, you'll have to settle for a big fat "I don't know".

More Q&A - C# Project settings

grantri — Wed, 22 Dec 2004 21:05:00 GMT

Question from Eric Wilson:

Could you do a post on what the settings on the Advanced Tab in Visual Studio.Net for C# projects are for and when you should use them?

My lame response:

I've only occasionally had to deal with the project-system guys that more or less own that 'Tab", so I can't even remember what's on it. Going off of the online MSDN: Visual C# Reference Advanced, Configuration Properties, <Projectname> Property Pages Dialog Box, I see 4 settings:

Incremental Build - don't use it unless you absolutely need to. It's getting removed in future versions. It was a buggy attempt at trying to only recompile changed code and thus speed up compilation.
Base Address - For Class Libraries (DLLs) you can get a small speedup in load times if the OS doesn't have to relocate your DLL from it's preferred base address. This is a big thing for native DLLs which typically have hundreds of relocations. For managed DLLs there's at most one: the import of mscoree.dll!_CorDllMain. As such this isn't really a huge win, but possibly still measurable. It will also impact working-set across multiple processes. Of course most big software houses don't use this setting, instead they run a tool like rebase.exe as a post-build step that lays out all of the DLLs so they all get unique addresses. [More info in a new post]
File Alignment - For certain binaries, this enables you to save a little extra file space. The 2 most common values are 4096, and 512. I think the default is 4096. By setting it to 512 you can potentially reduce the ammount of file padding, but this can hurt performance in other scenarios because now each section is not aligned the same as a memory page. As with all performance issues, the best advice is to try it out and measure. I expect this would have a bigger impact on the Compact Frameworks than on desktop applications.
Do not Use Mscorlib - The C# compiler automatically includes a reference to the mscorlib.dll that is installed with the current runtime. If you want to use a different mscorlib.dll, you need to us this setting to disable the automatic reference, otherwise the 2 will conflict. The most common use would be the Compact Frameworks.

--Grant

[12/29/04 - added link to new post on base addresses]

Why can't I do XYZ in C#?

grantri — Wed, 08 Dec 2004 00:16:00 GMT

First off I'm not a language lawyer, or an expert. I am only sharing some of the impressions I've gotten from working with the real language designers.

Eric Wilson asked why C# doesn't allow you to call static methods using instance pointers. My answer would be two-fold:

C# is very explicit. There's generally one and only one way to do a lot of things that in C/C++ had many ways. Likewise whenever there was a C/C++ language construct that was often mis-used, misunderstood, or just confusing, the language guys tried very hard to make C# impossible to mis-use, misunderstand, or get confused. This is such an example, see reason #2.
This is confusing to someone who reads the code. If they don't have the definition of the method nearby, they won't know it's static and thus doesn't need a valid instance pointer (which Eric's sample code lacks). Likewise some readers might try and assume that some sort of polymorphic virtual call might happen if the instance pointer is actually some sub class.

Orangy asked why he can't derive from Delegates. The short answer here is that it's a runtime restriction. The runtime deals very intimately with delegates, and as such has some heavy requirements on them. However, you can accomplish the same semantics with a little extra coding. Basically create an intermediate class that holds a weak reference (this is not new in v2, just new to me, thanks Dmitriy) to the real delegate, then pass the intermediate delegate to the real event:

// warning untested pseudo code sealed class WeakDelegate { public EventHandler MakeWeakDelegate(EventHandler realDelegate) { return new EventHandler(new WeakDelegate(realDelegate).WeakInvoke); } private volatile WeakReference realDelegate; // volatile so it is thread safe private WeakDelegate(EventHandler realDelegate) { this.realDelegate = new WeakReference(realDelegate); } private void WeakInvoke(object sender, EventArgs args) { EventHandler eh = this.realDelegate.Target as EventHandler; if (eh != null) { eh.Target(sender, args); } } }

That's all for today.

--Grant

[Corrected the code and some comments in response to Dmitriy's criticism]