Ian Carmichael: The History and Future of the CLR

Posted By: Charles | Jun 9th @ 9:18 AM | 37,906 Views | 16 Comments
Ian Carmichael has been working on the CLR team since before Microsoft came up with the .NET branding for our managed platform and the virtual machine that powers it all, the Common Language Runtime. Well, we're getting close to the third major release of the CLR, CLR 4 (V3 was really a service or minor release, but who's counting?).

Back in the good old days prior to V1, Ian was an engineer and a peer of Chris Brumme, Vance Morrison and other top of the line engineers working through the architecture, design and implementation of the CLR. Now, Ian is the GM of CLR and he's at the helm plotting out the course for CLR's future. Necessarily, we had to sit down with him to pick his brain about CLR then, now and tomorrow. Tune in. Get a glimpse into the past and future of the CLR from somebody who's been deeply involved with the advent and evolution of Microsoft's now ubiquitous managed runtime.
Rating:
2
0
#Jun 9th @ 3:09 PM
littleguru
littleguru
<3 Seattle

Nice interview. These kind of chats are also fun. It's great to get a overview about what has happened and what is going to happen. Smiley

#Jun 9th @ 3:34 PM
rhm
rhm

I'm not convinced by Ian's claim that IL is necessary for a common language interop. You can create an ABI that works between languages - indeed you can link C/C++/Fortran and other languages on many platforms, even though they are compiled to binary in one step.

There are however many other good reasons for CIL (and similar bytecode systems):-

  • Allows a single assembly to be compiled to different native machine architectures. This is important even for Windows since you have 32 and 64 bit runtimes now.
  • Provides a nice 'forking point' for the common infrastructure used by multiple languages. You realistically wouldn't write a complete source-to-binary compiler for most languages, you re-use a lot of stuff. So you have to have an interface at some level of the stack. Taking the GNU Compiler Collection as an example, they have multiple language front-ends that generate an intermediate form called RTL which is them turned into machine code for different platforms by a common backend. CIL exposes that level of interface more widely to the programmer. Which is greate because it's not just rocket scientist compiler guys that have a need to generate code.
  • It's makes code verification very much easier. In theory you can verify machine code for safety if the compiler obeys some very specific rules, but it's a lot harder than verifying something like CIL
#Jun 9th @ 4:07 PM
stevo_
stevo_
Human after all

I think the original argument was that you would just go from source to native cpu instructions.. because he (the v8 guy) was talking in context of javascript.. to me its an obsurd misunderstanding of .net if you expect to write pure source and jit straight to native in one swoop.. it might be do'able but why the hell would you (at least, why would you want to move everything to that, there was a good argument that dynamic langs could benefit from skipping the IL state (seems problematic))?

#Jun 9th @ 4:19 PM
Charles
Charles
Welcome Change

For JavaScript (or any singular language framework), syntax to cpu instructions makes perfect sense if your aim is to eek out as much performance as you can. It's because of byte codes, for example, that the CLR and JVM support multiple languages. The goal of the CLR has always been to enable n number of languages that get compiled down to a single form that is readily reasonable at runtime. This has benefits for multiple language project, debugging and runtime optimization. There's more the JIT could do in the future. I think some of the naysayers just don't like MSIL, specifically. The folks I've talked to about it believe that MSIL is too closely related to C# and is not as generalized as we claim. That's not an area where I can chime in since I have nothing to do with MSIL design and do not have the knowledge to present Microsoft's formal opinion on the matter... Still, I like to hear what others think. Opens up the box.

Debating is a very important part of learning and assimilating information, distilling it into working knowledge. I want more debate, not less. I wish I could get Lars Bak together with Vance Morrison and let the games begin! Smiley Lars is a brilliant guy. It's unfortunate I didn't capture his stance in the completeness it deserves. Still, I am a big fan of IL/bytecodes. There's just so much possibility for reasoning and adaptation in runtime context. So much so, that we've barely even scratched the surface of what's possible, especially as processing power becomes astronomical...

The future is bright, but you have to look into the light, not away from it.

C

#Jun 9th @ 4:35 PM
stevo_
stevo_
Human after all

Heh charles I'm certainly not set in my ways.. but what lars basically said was he thought people should just write c#, vb, f#, ironpython -whatever-... and what .net should be is an array of runtime compilers (like v8) for EACH language.. that just completely ignores the reasons why .net has IL in the first place... like Ian says.. there are places in .net where being able to go from source to native without IL would be useful.. and that would be for scripting languages, where compilation is done (or at least mostly so) at runtime.. in which case theres no reason to go to IL..

But here's the thing.. whilst .NET has two compilation steps:

Source -> IL -> Native

And perceiveably, javascript has one step:

Source -> Native

Thats not the reality... Source -> IL happens at compile time so the runtime then comes down to:

IL -> Native

vs.

Source -> Native

I'm no language designer or compiler guru, but I would expect that IL (which is built by a machine).. is much faster to compile to native than source (written by a human, complicated syntax to make it friendly for the human to write).. and therefore his argument really stuck out to me as ignorance..

#Jun 9th @ 5:00 PM
Charles
Charles
Welcome Change

MSIL is source. That's the point. MSIL is a human-readable form of the higher level syntax used to construct it. But, yes. The JIT is fine tuned to blaze through IL. It comes down to the usual suspect: relative philosophy. Lars is a machine guy. He doesn't like the notion of intermediate steps on the path to x86. That's his perogative. Classifying this as ignorance on his part is probably out of scope. His position is based on several years of writing virtual machines. However, you're right in that he has little experience with .NET. Smiley

C

#Jun 9th @ 6:48 PM
joechung
joechung

Another problem with MSIL is that it has no abstractions for vector instructions in CPU's (and modern GPGPU's) that could be useful for exploiting data parallelism in large-scale (and not so large-scale) scientific computing problems.  The Mono team has a Mono.SIMD assembly in the works for this.  I'm hoping the CLR/CIL folks are working on something similar.

#Jun 9th @ 7:01 PM
joechung
joechung

I didn't get the impression from watching Charles and Eric's interview with Lars here on C9 and the videos of his Google I/O talks on YouTube that Lars was espousing a naive source-to-assembly conversion.  I suggest watching his talks again to get a clear understanding how V8 actually works.

http://code.google.com/events/io/sessions/V8BuildingHighPerfJavascriptEngine.html

#Jun 9th @ 11:44 PM
DouglasH
DouglasH
Just Causual

I am hopeing that is what was implied when Ian stated the math/science area.  There are a lot of areas where performance and be explicitly improved with SSE and GPGPU support.  I don't believe there would be much involved to add that support, the JIT engine would have to be smart enough to understand the underlying hardware that is available to choose level of sse support for example or go the safe way and choose the lowest common denominator between amd and intel.

GPGPU gets more interesting, dx11 introduces compute shaders, but to be honest, it is a subset of what is available in the GPGPU area on both nvidia and amd, and then you have Intel embedded video which throws an interesting aspect to that area. (or the other video card oem's) Open CL imo is a more robust platform on the outset but I don't see dx resting on its morals going forward either.

The question then becomes how to support on downlevel machines?? Talking cells phones etc.

Microsoft Communities