Christopher Brumme - What is the future of the CLR? | TheChannel9Team

Christopher Brumme is an architect on .NET's Common Language Runtime, aka CLR, team.

His weblog is famous for 11,000 word highly technical posts. That makes sense. The .NET CLR is at the center of Microsoft's future platform strategy. He tells us he'll get to his weblog again sometime, but he's just been very busy working on the next version of Windows, code-named Longhorn.

You'll get to know Christopher more over the next couple of weeks, but we thought it'd be fun to start with this clip where he talks about what the future of the CLR will be.

What would you like to see in the CLR?

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

Frank Hileman VG.net

Jun 24, 2004 at 6:06 PM

This sounds great, but what exactly is this non-traditional execution Christopher is speaking of? AOP or a derivitive?

I see there is a great deal of power at that level, but I am not sure what might be done there.

One thing I would like to see is method tracing. Selectively turn on a trace-log using regular expressions matching member names, and type/namespace filtering, with indenting according to call depth, and possibly logging argument values as well. I am used to using this type of tracing in older object oriented environments.
raptor3676

Jun 25, 2004 at 11:28 AM

Well there are a couple of things I'd like to see in the CLR. First that assemblies can be compiled directly to Native code without having to go to the GAC (that is skipping the Just-In-Time Compiler) and Second, that some how the GC were hardware based.

This way there would be no reason (besides array/memory checking and reflection) for .NET programs not to run at same speed as Win32 executables.
raptor3676

Jun 25, 2004 at 11:29 AM

Sorry I forgot a Third feature...

Reduced memory footprint for executables
slicertool A box! I saw a box just a little while ago!

Jun 25, 2004 at 1:27 PM

Frank Hileman wrote:

This sounds great, but what exactly is this non-traditional execution Christopher is speaking of? AOP or a derivitive?

The traditional execution includes taking an application image and tossing it into memory as is. With an interface like the CLR and CLI, there might be the future possibility of optimizing an application at run-time as opposed to design-time. This would allow the application to get the most out of whatever that machine can give it. The only problem with this idea is that it takes too long to do it on today's hardware and using today's methodology. This is one of those features that you should keep your eye out for in the future.
dkangel

Jul 08, 2004 at 8:51 AM

Raptor 3676 ever hear of NGEN? It does just what you ask with respect to Native Code precompilation.

DKangel
Bryan Young

Jul 12, 2004 at 1:29 PM

You wouldn't want to compile the code before it reaches the machine. That would cost the extra performance gains of the particular machine. One of the advantages of the CLR (even if MS won't market it this way) is platform independence. JIT allows for optimization down to the specific processor without compatibility issues. In the future this will give chip makers the ability to worry less about compatibility and more about performance.

One solution might be to compile the IL to native code at install time, but that would prevent future runtime optimizations. For GUI apps, we would most likely benefit from pre-compiling, but very repetitive apps (data crunching apps, and server side apps) will benefit from runtime optimizations (I don't know the state of runtime optimizing in .NET, but HP, and Sun have made some advancements here over the last few years).
Charles Welcome Change

Oct 13, 2005 at 3:40 PM

I'm bumping this thread because I've made my first Clipster clip from this interview and wanted to initiate some discussion re the future of execution. Very interesting stuff.
C