Difference between C# and C++ or Java

[MadHatter]

[java api]=>[jvm]=>[os]

java api does not import kernel level drivers. it uses jvm api's which in turn import kernel level drivers. but as you can see, every .net dll contains some platform driver / dll.

[klintan]

[.net appl] => [CLI implementation, e.g. CLR]=>[OS]

Java libraries such as AWT references kernel32, user32, gdi32, ole32, advapi32 etc. (check depends on AWT.DLL for instance).

If you start a java application one new process is started (java), if you start a .net application also one new process is started, but if CLR is used (as it typically is on .Net) you will actually see the name of the application as the process name. If you run the same .Net application using Mono for instance I guess it might look a bit different.

[MadHatter]

ok. the horse is dead, do we need to keep beating it?

.net does not use a virtual machine at runtime to do anything. to debate that it does is crazy (and ignorant). to claim that Microsoft's .NET uses a virtual machine is ignorant. such a concept was hinted at in the spec, but was not implemented as such in reality. Instead they created a compiler that created the same type of binary that would be generated with any C++ type compiler. there is no assembly in the framework that does not directly load platform api (actually there may be, but I havent found it). it is compiled to a "your hardware", "your specific version of windows" native cpu instruction set before its run. if you install it in the GAC you can pre-compile it so it no longer ever ever ever gets compiled (as long as you use the assembly version you ngend the native image with). ngen.exe is not some "smoke and mirrors" application that is shipped w/ the framework, it compiles exactly the same thing for every assembly that is loaded into memory, and that will look the same kernel32.dll to the cpu. it is not executed in another process as java is when it is run in the jvm.

mono is not .net any more than sharp develop is visual studio. mono uses a "virtual machine" (as would any other implementation non-.net that runs on any other operating system, because to be able to run on both windows and linux you need to abstract out the actual operating system kernel level driver you use), and has (or atleast last time I checked) no native image compiler.

if you want to believe the sun is green, that grass is blue, and .net runs inside a virtual machine, thats fine. such is not the case, but whatever.

fin

[klintan]

Well, C# can run in a VM, maybe CLR not is a VM but other CLI implementations are.

Same with Java, on Windows it runs in a VM but with embedded Java it runs against the hardware.

With Java in Windows there is no extra process - the application runs in the same process as the VM (unless the application is launched from a different program such as Internet Explorer).

In current Windows versions .Net sits on top of them, while I guess in future .Net will be native.

So I guess that C# can run both in VM and non-VM. Whether CLR is a VM or not we can discuss forever. My opinion (and many others) is that it is, your is that it isn't.

A fundamental difference between IL and bytecode is that IL is always compiled, but bytecode may be interpreted. I found one qoute regarding the difference between interpreters and virtual machines: an interpreter is always a VM but not all VMs are interpreters (a VM with JIT doesn't interpret the code).

but, sure, lets end the VM discussion here.

To me, there are similiarities in performance between C# and Java. I would say that the biggest advantage of java is portability (although this is addressed for .Net in things like Mono, personally I would not choose C# and Mono for an application targeted for Unix - if the application is already there, then there is a difference). The advantages I see with .Net is excellent integration with microsoft stuff, support for many languages, and I expect that Microsoft will make it more native and faster in future versions of windows.

[dxfoo]

except that it is compiled to a native image before execution. The IL is not interpreted during runtime.

I'm not disagreeing but I have trouble seeing it fully compiled. MSIL is executed and is compiled to binary (in Java's VM, as neccessary). This allows greater security, web services are safe, and so on. I have some doubts because the garbage collector alone is a runtime checkeroo.

For other bla blas, the term 'CLR' is a cheap way to get out of Java's bad reputation of having a virtual macine for real-time multimedia. Obviously, it is a virtual machine. You computer science people already know that. Take a simple computer organization class and realize there are several virtual machines on the computer - LAYERs of software ontop of the hardware. The CLR is another virtual machine that runs ontop of the operating system's layer. If Microsoft can say we're better than Sun to get even game developer to join in, then the term 'virtual machine' is an immediate bias from multimedia developers. Let's call it CLR so we can give it a fresh new meaning.

[MadHatter]

ngen is used to compile assemblies in the JIT process. now, unless they're flat out lying... IT RUNS A NATIVE IMAGE, not an intrepretation of anything.

A native image is a file containing compiled processor-specific machine code. Note that the native image that Ngen.exe generates cannot be shared across Application Domains. Therefore, you cannot use Ngen.exe in application scenarios that require assemblies to be shared across application domains.

Pre-compiling assemblies with Ngen.exe can improve the startup time for applications, because much of the work required to execute code has been done in advance. Therefore, it is more appropriate to use Ngen.exe for client-side applications where you have determined that the CPU cycles consumed by JIT compilation cause slower performance.

'clr' means a common language runtime. which means that multiple languages compile to the same IL. you can write something in managed C++, python, vb, C#, java or a bunch of other languages, making the IL language a "common language" that they all use.


dont go around repeating what others say, because you'll end up looking as ignorant as they do.


once and for all, I challenge anyone, I mean anyone, to show me the binary machine disassembly code where mscorlib.dll or any other ".net" dll (assembly or dll or exe) maps .net IL instructions into cpu specific instructions at runtime.

no such thing exists. it uses a compiler to compile an executable before the application runs.

here's a link of what happens when your .net assembly is run: http://msdn2.microsoft.com/en-us/library/k5532s8a.aspx

Before you can run Microsoft intermediate language (MSIL), it must be converted by a .NET Framework just-in-time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture as the JIT compiler.

seeing as how you can ngen (pre-compile) the entire executable and all the referenced assemblies into a native image (this is what dynamically happens when you run your executable anyway) so that the jit compile does not happen at runtime, it seems kind of silly to have a crappier implementation that would do anything else.

there is not one reference to an application that runs your application (other than your application).

[klintan]

once and for all, I challenge anyone, I mean anyone, to show me the binary machine disassembly code where mscorlib.dll or any other ".net" dll (assembly or dll or exe) maps .net IL instructions into cpu specific instructions at runtime.

I think this is shown here: http://msdn.microsoft.com/msdnmag/is...5/JITCompiler/

In addition, even with NGEN, Jit may still be used, look here: http://msdn2.microsoft.com/en-us/library/6t9t5wcf.aspx , at the section "Native Images and JIT Compilation".

The CLR does JITting on a per-method basis, this means that the entire code not is compiled before the application runs. Just the parts needed are.

[MadHatter]

thats still not emulating anything. like I said it is a runtime, just not with a process that emulates simulates or otherwise intreprets IL instruction into machine operation instructions. Its a compilier that compiles native code when needed (whether at application start up, or during runtime) is a compiler. if that "compilier" intreprets IL instruction continuously during runtime to provide hardware or software abstraction, then its a vm, otherwise its a runtime that dynamically compiles things as needed.

if you use ngen it will compile everything. if the JIT process is the one invoking ngen then it will not compile everything (which makes sense).

[klintan]

So basically what you are saying is since CLR uses JIT it is not a VM? To be a VM it must be an interpreter?

According to Microsoft documentation NGEN does not always compile everything:

"Native Images and JIT Compilation
If Ngen.exe encounters any methods in an assembly that it cannot generate, it excludes them from the native image. When the runtime executes this assembly, it reverts to JIT compilation for the methods that were not included in the native image.

In addition, native images are not used if the assembly has been upgraded, or if the image has been invalidated for any reason."

[MadHatter]

to be a virtual machine, you need to virtualize something. what does dynamic compilation virtualize?

[Dmorley]

lol - this one still going!! I actually agree with a few different points in this discussion...

Some interesting reading here ... .Net vs Java

From the above link...
VES - Virtual Execution System

Virtual Execution System (VES), is more or less equivalent to the JVM (Java Virtual Machine).

VES loads, links and runs the programs written for Common Language Infrastructure contained in Portable Executable (PE) files.

Virtual Execution System (VES) fulfills it's loader function by using information contained in the metadata and uses late binding (or linking) to integrate modules compiled separately, which may even be written in different languages.

And again...
JIT Compilation

Before Intermediate Language (IL) can be executed, it must be converted by a .NET Framework Just In Time (JIT) compiler to native code, which is CPU specific code that runs on the same computer architecture that the JIT compiler is running on.

Microsoft's designers insist that the runtime never interprets any language, it always executes native code, only conversion to native form may be deferred. Even the scripting languages like VBScript are now compiled and executed!


So yes - MadHatter is right in that CLR doesn't interpret anything in the way the JVM does. I can totally understand the technical argument you are making...

But, to be honest - they have enough in common for me to not split hairs about (Garbage collection, JIT, yada yada).

[MadHatter]

to me, their commonalities come from the fact that they both use advanced programming techniques (as you've mentioned) rather than sharing the common execution architecture (speaking to non-jitted java) of a VM.