Printable View
Hi,
I am not sure when C# came into existence or when and who in microsoft started it but i do not understand the difference between c# or Java or C++ as they are all object oriented languages or in fact they are used to write object oriented programs.
Can anybody suggest me about this doubt.
I came to existence somewhere around year 2000 and was standarized by ECMA in 2003.Quote:
Originally Posted by arnabsom
AFAIK it was a project by Microsoft, HP and Intel.Quote:
Originally Posted by arnabsom
Well, the are all OO languages with somewhat similar syntax, but they're all different flavours. There are many more OO languages as well. One notable difference between C#/Java and C++ is that C# and Java was designed for running on virtual machines, whereas C++ (build somewhat on top of C) is compiled into platform dependent machine code.Quote:
Originally Posted by arnabsom
- petter
except C# doesnt run on a virtual machine.
... its uses the "Common Language Runtime" (CLR) instead, which has more or less the same purpose as the virtual machines used by for example Smalltalk and Java.Quote:
except C# doesnt run on a virtual machine.
http://en.wikipedia.org/wiki/Common_Language_Runtime
except that it is compiled to a native image before execution. The IL is not interpreted during runtime.
Are you using NGen?Quote:
except that it is compiled to a native image before execution. The IL is not interpreted during runtime.
http://www.codeguru.com/Csharp/.NET/...cle.php/c4651/
ngen creates a "permanent" (albeit a very fragile) version of what gets generated at runtime.
Known as JIT (Just-in-time) compilations... Java does that aswell.Quote:
Originally Posted by MadHatter
- petter
I was under the impression that their jitc still included dynamic translation durning runtime.
I'm sure it's a mix of both, but how does that differ from a C# application containing a mix of Early-Bound, Late-Bound and Lightweight Code Generation?Quote:
Originally Posted by MadHatter
- petter
one interprets byte code and the other doesnt. afaik .net does not use the concept of a "virtual machine" in the same sence as early java apps do. code generation, compilation of an assembly and execution of that image is different than dynamic translation of bytecode to cpu instruction. personally I wouldnt call .net's bootstrap executable that loads up the .net assembly and compiles it a virtual machine, because it doesnt emulate hardware at runtime, but instead compiles source code to a native instruction set.
I agree if were talking pre-JIT, but it's a long time since JIT was introduced.Quote:
Originally Posted by MadHatter
But it doesn't do that with late-bound code. AFAIK that is 'translated' on the fly. Or am I totally wrong here?Quote:
Originally Posted by MadHatter
- petter
I have never seen a single document to suggest that il is ever interpreted.
I have however read documentation on how assemblies are loaded (whether bound at application start up or later on) as well as changes in .net architecture between .net 1.1 to 2.0 in matters of reflection. for instance under 1.1 reflection info was laid out in unmanaged space. When you'd call GetMethod("Foo") that it loaded every single method of that type in to unmanaged memory and would do so at every request. in 2.0 thats been pulled into the managed heap and lazily initialized (and privy to the GC). that would suggest to me that even late bound code--while assembly meta data is used for inspection--is fully compiled and loaded / executed like any other native library compiled to a native image.
if there is any documentation (or somebody can show that this is the case) on the matter, I'd love to see it, but everything I've ever read on .net said that assemblies are completely compiled at start up, and are executed as any other non-.net assembly after that.
Is there a online source available (preferably an independent source) that compares the speed between C# and Java (preferably a late model JDK) when they run the same programs?
of course it does.. all apps run in a virtual machine. take your thinking out of the box for a moment, and consider what electrons, the cpu, bios, hal, operating system, .net framework actually are..Quote:
Originally Posted by MadHatter
I'd only question (in this) your notion of a virtual machine. If we defined a virtual machine as a well formed and specified interface to a particular computer cpu architecture, then the VMs only job is to get whatever code it reads in, into the architecture to do something useful.. ergo whatever part of the framework is responsible for "compiling assemblies at startup and [running them on the cpu]" is a virtual machine.. it may differ in modus operandi to the jvm, but its the same goal; a well formed language A is translated to well formed language B which is suitable for execution by the cpu.. both VMsQuote:
Originally Posted by MadHatter
a virtual machine is something that emulates its environment. Java's does so because its run across huge hardware and software differences.
.net simply does not do this. It runs on one platform, one instruction set, and is not in any way shape or form intrepreted in a "virtual" anything. Each assembly is loaded up into a runtime host which controls memory allocation and manages type and assembly resolution. that does not emulate anything. that contains no level of hardware or software abstraction and as far as I'm concerned cannot in any situation be considered a "machine" virtual or otherwise.
System.Windows.Control directly invokes Win32 code. System.IO.Stream calls the same platform api's in an object oriented manner. there is absolutely no "virtual" anything executing here, which is why a normally compiled C++ application may use managed extentions. what happens in that instance? is .NET pervasive enough to wrap all that native code in some sort of managed world? no, it doesnt. end of discussion.
C# and Java are compared quite often because they are the most recent programming languages, from 2 of the world superpowers in computing. Java's claim to fame is the ability to run a single code base on any computer. microsoft's has no such claim, nor vision. the bottom line is that people have no clue what they are using. .NET is similar to java in the same way that anyother C family of language is. because a comparison is made, and because .NET requires additional OS features to operate, people ignorantly jump to the conclusion that .NET is doing the same thing that Java does with respect to a virtual machine, running a layer above the hardware and softare, but the bottom line is that it doesnt.
.NET is no more a virtual machine than COM.
and if it is, please let me know how.
From the book "Programming Microsoft .Net":
"The CLR sits atop the operating system and provides a virtual environment for hosting managed applications."
The CLR is Microsoft's implementation of CLI (Common Language Infrastructure), an Ecma Standard (http://www.ecma-international.org/pu.../Ecma-335.htm), that defines "...the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments."
The Mono project implements CLI so that .Net applications can run on different unix flavors.
To me this looks like a virtual machine.
Back to the original question: C# and Java are similar in syntax, at a conceptual level, and in performance (from figures I have seen doing comparisons between C#, Java, and C++). C# and Java compiles to IL/Bytecode, which later gets interpreted to machine code by JIT-compilation. With C# (and Java too I think) you can also compile directly to machine code, but then the code generated is for a specific platform and version of the .Net framework.
C++ is a superset of C, and it contains both OO and non-OO constructs. In C++, you have much more control of memory etc so you can write faster code - but this comes at a price, it is difficult, takes time, and is error-prone to code in C++.
Even though C# in theory is portable to Unix platforms, I would mainly consider C# for applications targeted for the windows platform. I have not used Java for a long time, but I know that it is being used for many different platforms including mobile phones. I would only use C++ for really performance critical applications. In most cases, performance is an issue of overall design, and much time spent by an application is in code outside of the application anyway (e.g. db, network, file system etc.).
a "virtual environment" is not a "virtual machine"
I can't see how this is so confusing. you can host managed applications inside the clr, but this is not a "hardware" or "software" "Machine" abstraction. it is a system, or environment for managing allocation of system resources. Its the very same concept that you use in every other programming language (except .net does not strictly rely on the OS to provide everything it needs like other languages do). It is executed as a machine specific set of instructions.
in contrast, Java, while providing similar functionality, runs on top of the operating system, but intreprets the bl into machine code.
run a .net app. then run a java app.
here's an example:
zend studio (written in Java):
http://sanity-free.org/misc/zend.gif
bindmaker (an app I wrote in .net)
http://sanity-free.org/misc/czbm_proc.gif
notice that zend needs javaw to run. bindmaker does not. it is not "launched" with another application, "intrepreted" by another application, nor under the framework that it is written under "watched" by another application. It is not "run" by anything.
explain how you run something in a virtual machine when there is no virtual machine running when you run your .net application.
Well, if I look at the nice picture in this article I see the runtime on top of the operating system and hardware. So it is a virtual machine for me. Maybe you want it call abstraction layer but it means the same. You do not have direct access to the hardware and you do not have direct access to the operation system. So where is the difference?
Your screenshots of the running processes do not proving if it is a virtual machine or not. It is only prove that the .NET runtime is maybe started in the same thread like the .exe file. So starting the runtime and the application in one thread or many threads is not the question and not the answer. If I build an empty Windows application with one form and a label which says "Hello world!" the application takes 15 MB of memory. If I build the same in C++ it only needs a few kBytes. So to all appearances the runtime is included and will be executed too.
No difference to Java in my mind.
you could draw a similar picture for every programming technology in existance today (they all interface the OS directly, unless you're writing firmware).
it seems folks get "runtime" and "virtual machine" confused.
a virtual machine (like vmware, virtual pc, and jvm) allows code for one machine to be run on another. It uses hardare abstraction to interpolate one machine instruction to another.
windowing:
java: has to be able to window in X, windows, (whatever mobile devices use), and so forth
.net: directly wraps Win32 and GDI.
file system:
java: again, has to be able to use ntfs, nfs, fat, and all the million other file system types used throughout the unix / linux / windows worlds.
.net: the framework directly calls Windows Platform api's.
break out reflector and dig through the source code (or download it from microsoft).
anything that ran in a virtual world should not directly call **any** machine specific api's. that's the responsibility of a virtual machine. If you're running Vista on window 98 via vmware, what is happening when the operating system is reading or writing to a "physical device?" vmware emulates the hardware and passes those commands on through to the physical hardware.
do you honestly think java's source code implementation of stream would import kernel32.dll to read a file?
.net does. so how then does that work? does .net's vm intercept all these calls and re/write them into whatever OS they happen to be on?
.net does not use a "virtual machine". dont get this confused with a "runtime"
According to this page: http://en.wikipedia.org/wiki/Virtual_machine the CLR is an application virtual machine.
According to Portable .Net and Mono project respectively, they both implement CLI virtual machines to allow .Net programs written in C# or other .Net languages to run on a number of different OS's.
According to Peter Golde the CLR can be considered to be a virtual machine (see http://msdn.microsoft.com/library/de...netconvers.asp, 6th Q and A)
According to Microsoft, Ecma 335 defines CLI - virtual machine (see: http://msdn.microsoft.com/netframework/ecma/), in the actual spec the term virtual execution system is used though.
So I would say that both Java and C# can run in virtual machines. The main difference is that the CLR VM can run different languages. (But I think I have heard about Ada compilers that generated Java byte code so that ada programs can run in a Java VM).
If I were creating a programming language, I could not call it a "virtual machine" if I directly invoked platform specific api.
the fact that parts of the framework only work on windows, not all of it works in the compact framework is a testiment to that.
IMO if it walks like a duck, and talks like a duck, then it must be a duck.
you can quote people all day long, but a language that can emit direct, specific assembly code, a language that directly invokes platform specific code from kernel libraries, cannot be considered a virtual machine.
so quote away, but the fact remains 1. that it does not emulate hardware, and 2. it directly executes platform api's (and not in imulation).
Ok, so i took this rather silly java application:
and attach my debugger to it. This is what i saw:Code:public static void main(String[] args)
{
int i = 0;
int j = 0;
while (true)
{
i += j;
i ^= 1;
i ^= j;
i |= 1;
}
}
And these instructions looks very similar to what a compiled C++ (and probably C#) application would look like. It is not interpreted by some virtual machine, it's compiled to platform dependent machine language... but still I would say that the JVM is a Virtual Machine, and the same goes for the CLR.Code:00AE3F9C mov edi,edx //
00AE3F9E add ebx,edi // ebx += edx (i += j)
00AE3FA0 xor ebx,1 // ebx ^= 1 (i ^= 1)
00AE3FA3 xor ebx,edx // ebx ^= edx (i ^= j)
00AE3FA5 or ebx,1 // ebx |= 1 (i |= 1)
00AE3FA8 test dword ptr ds:[820100h],eax
00AE3FAE jmp 00AE3F9C // loop back...
- petter
obviously.
if it didnt get intrepreted into machine lanugage then it couldnt run.
I can do pretty much the same thing with php (and you know thats intrepreted). never underestimate the power of a debugger.
lets look at the terms:
virtual: (right off the top) Having the power of acting or of invisible efficacy without the agency of the material or sensible part.
machine (I dont think we need a definition here): the computer (hardware, software, & peripherals).
the power of java's vm is to not require the physical / logical machine to run the java application. platform specific bindings are implemented in the intrepreter.
1. .net does not have an intrepreter (it has a compiler that generates a native machine language image. the fact that java may be able to produce native images is irrelevant)
2. .net does contain OS specific bindings (as the end all of how things are implemented)
when you're bound to physical / logical OS specific libraries IN your code base, you no longer have the abliity to bind to anything else (and if you're emulating, simulating, or pretending you're working on something that may or may not exist, or whatever those def.'s of virtual are, how do you get around this?). am I wrong?
here's are the references of a few .net libraries. I can did deeper and show how they are referenced in the inner implementation (as anyone w/ reflector can).
CLR
http://sanity-free.org/misc/clr1.gif
Windows
http://sanity-free.org/misc/clr2.gif
Web
http://sanity-free.org/misc/clr3.gif
Drawing
http://sanity-free.org/misc/clr4.gif
System
http://sanity-free.org/misc/clr5.gif
Services
http://sanity-free.org/misc/clr6.gif
if there is a similar tool for java, do the same thing and see if they have platform specific bindings. Though I havent done it I very seriously doubt that they do (because it would limit the hardware that java can run on), and you'd have to download a new version of java for ever piece of hardware that you want to install your app (which you do, but you're getting the virtual machine, not the library implementation).
now. please somebody show me how .net could be remotely considered a "virtual" machine. I dont need quotes from microsoft propaganda, unless it gives specifics on how the .net implementation is abstracted out, intrepreted / emulated / simulated, or virtualized on the machine.
Actually .NET is a JITted language i.e. it is compiled at runtime into the machine language for whichever platform it is designed for.
By my understanding the original versions of Java were interpreted - and probably still are for web browser back ends but I wouldn't know about that.
When you compile a .NET application it compiles to an intermediate language (IL) which is very quick to be compiled at run time.
Once a piece of code is compiled it is held in memory in its compiled (i.e. machine language) form so that if it's used again then it doesn't need to be compiled twice.
C++ is ALWAYS compiled to machine language for whichever machine it is targetting (e.g. PC, Mac, Sun, Silicon Graphics etc).
However a major difference between Java and .NET between C++ (native C++ of course - there is C++/CLI which is a .NET managed language) is in memory handling.
In C++ you have to allocate and deallocate the memory you need yourself. If you don't do this it leads to memory leaks which (certainly in server applications) will build up over time and cause your application (or even your entire OS) to crash.
With managed languages such as Java and .NET memory is managed by a seperate process - in .NET it's the Garbage Collector.
There are other differences (reflection in .NET is an example) but I think that's enough from me for now. My apologies if I've covered topics which have already been dealt with.
As to whether these things run on a 'virtual machine' or not - who cares ? It's the philosophy of each of these languages which makes up their advantages and disadvantages and ultimately effects which language you use to write a particular piece of software.
But to be accurate I would say that .NET doesn't work on top of a 'virtual machine' but more of an 'invisible compiler'.
I'm not making any statements about Java - I know very little about it.
Oh and WildFrog - I'm interested in the 'test' statement in that machine language because I would have thought the Java JIT compiler would be clever enough to recognise that it wasn't necessary. :D
Darwen.
I found that abit odd myself. I did a test with C# and there was a couple of bad optimizations there aswell. Like this one:Quote:
Originally Posted by darwen
Coming from a VC++ environment I would assume that everything was optimized away, but the JIT actually produced this:Code:static void Main(string[] args)
{
for (int i = 0; i < int.MaxValue; i++)
for (int j = 0; j < int.MaxValue; j++)
{
// do nothing
}
}
One thing I found as a positive surprise (atleast to me) was that it inlines and optimizes functions residing in different assemblies.Code:00C90070 33 D2 xor edx,edx
00C90072 33 C0 xor eax,eax
00C90074 83 C0 03 add eax,1
00C90077 3D FF FF FF 7F cmp eax,7FFFFFFFh
00C9007C 7C F6 jl 00C90074
00C9007E 83 C2 02 add edx,1
00C90081 81 FA FF FF FF 7F cmp edx,7FFFFFFFh
00C90087 7C E9 jl 00C90072
00C90089 C3 ret
- petter
optimizations are not typically done in debug build so that you can step through along w/ the disassembled code. release mode builds do.
Yes, it was release mode. I started it from command line and then attached my debugger to it (with no knowledge of any IL or source code).
- petter
Well of course the CLR has platform specific bindings, any virtual machine would, wouldn't it?
[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.
[.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.
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
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.
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.Quote:
Originally Posted by MadHatter
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.
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.
'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.Quote:
Originally Posted by the link above
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
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.Quote:
Originally Posted by again from the link above
there is not one reference to an application that runs your application (other than your application).
I think this is shown here: http://msdn.microsoft.com/msdnmag/is...5/JITCompiler/Quote:
Originally Posted by MadHatter
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.
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).
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."
to be a virtual machine, you need to virtualize something. what does dynamic compilation virtualize?
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).
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.