Lambda the Ultimate

inactiveTopic Don's Favorite Aspects of the CLR
started 1/4/2002; 3:42:24 AM - last post 1/6/2002; 2:17:09 AM
Dejan Jelovic - Don's Favorite Aspects of the CLR  blueArrow
1/4/2002; 3:42:24 AM (reads: 2034, responses: 3)
Don's Favorite Aspects of the CLR

This is just a short page on which Don Box, of the COM fame, lists the things that he likes about the Common Language Runtime.

Posted to cross-language-runtimes by Dejan Jelovic on 1/4/02; 3:44:53 AM

Ehud Lamm - Re: Don's Favorite Aspects of the CLR  blueArrow
1/4/2002; 5:02:58 AM (reads: 898, responses: 0)
I don't know much about .Net, but items 8 and 9 look interesting. Can anyone give some more details for the clueless?

Dejan Jelovic - Re: Don's Favorite Aspects of the CLR  blueArrow
1/4/2002; 10:14:59 AM (reads: 923, responses: 0)

Point 8: RealProxy is a .NET class that provides pretty much the same functionality as Java's dynamic proxies. It provides an "invisible" way to convert function calls into messages.

Point 9: NGEN.EXE translates an assembly (== code package) into native code and installs it into the local machine's native code cache. This is a way to pre-compile the code instead of waiting for JIT to do it.

Dan Shappir - Re: Don's Favorite Aspects of the CLR  blueArrow
1/6/2002; 2:17:09 AM (reads: 843, responses: 0)

With regard to point 8: component frameworks such as CORBA and COM (DCOM) provided a means to extend intra-process programming techniques and conventions beyond process boundary (even across the network.) This was accomplished by providing (amongst other things) an infrastructure for converting standard stack-based method invocations into message-based protocols (where the messages could be sent over the wire.)

These frameworks exhorted a price for the conveniences they provided. Basically, you had to program for them. That is, a C++ program written for COM or CORBA looks (and works) differently than a standard C++ application. There was a lot of overhead: writing an IDL, lots of API calls for setting up the system, etc.

Java with RMI showed how easily this type of thing could be done when the environment provides the appropriate facilities, built on a thorough reflection API (see items 2 and 3 in Don's list.) .NET uses the same model and extends it in several notable aspects:

  1. The remoting API is open and documented. This means that .NET remoting can (and probably will) be extended to support additional wire protocols.
  2. Using this API, .NET comes with several built-in remoting services, e.g. TCP and SOAP.
  3. Speaking of SOAP, .NET automates much of the process of building and using web services. It provides remoting services that work with the various SOAP protocols such as WSDL and UDDI.
The third point cannot be overstated as SOAP is currently the only means to extend .NET applications beyond the Windows platform.

With regard to point 9: .NET allows the byte code to be JIT-ed, compiled to native on install, or at build time. Pre-compiling can obviously improve performance but I don't share Don's enthusiasm over this technology:

  • Most apps spend most of their time in very restricted sections of their code. These sections will be JIT-ed only once and then executed many time throughout the app’s lifecycle.
  • .NET's overhead compared to C++ (even with COM) is not limited to the JIT overhead. For good and bad C++ lets you work much closer to the metal, thus providing much finer control over performance related issues (e.g. custom memory allocators for STL vs. .NET GC.)
  • It's all about the algorithms anyway ;)
Basically what I see NGEN providing is improved load times rather than significant performance gains throughout an app's lifecycle.