Christopher Brumme - What is the future of the CLR?

Sign in to queue


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?





Download this episode

The Discussion

  • User profile image
    Frank Hileman
    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.
  • User profile image
    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.
  • User profile image
    Sorry I forgot a Third feature...

    Reduced memory footprint for executables
  • User profile image
    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.
  • User profile image
    Raptor 3676 ever hear of NGEN? It does just what you ask with respect to Native Code precompilation.

  • User profile image
    Bryan Young

    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). 

  • User profile image
    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.

Add Your 2 Cents