Why Java Will Always Be Slower than C++
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
Good link, Farhan! I enjoyed it :) And also the question ( ;p)! Chris? ------- Nature, to be commanded, must be obeyed. (Francis Bacon) Nature, to be apprehended, must be obeyed. (Ayn Rand)
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
can you shed some light on C# and .NET's standing in this regard? It really depends on the situation. Microsoft posted some benchmarks using the PDC bits that showed managed code vs unmanaged code was somewhere between 40% slower to 5%-10% faster, with the average (I think) around the 10-15% slower. This is from failing memory and also using the PDC bits - which were not even vaguely optimised. You can run a tight inner loop that just adds two numbers together and managed vs unmanaged will be about the same. You could do a whole series of small memory allocations and then a big deallocation and the GC model may be faster. You could then compare a 'standard' application that never bothers with bounds checking or the success of resource allocation from the OS with a managed app that has all this in place automatically, and you might find the unmanaged code faster - but only because it's living on the edge. .NET also has the concept of value and reference types. Value types are allocated on the stack and are used for simple objects like
ints andstructs. This is going to give C# an edge over the equivalent Java code, and bring stack allocations back to be on par with unmanaged C++. C# also hasenumsupport, so again there isn't the need for workarounds for enums as there are in Java. In C# everything is type safe which means the compiler can be more aggresive with it's optimisations. C# is never interpreted - it's always compiled to native. Through JITing (and the processor packs MS will be releasing as newer chips are released) the native code produced by the compilers will be able to target not only the processor it is running on, but also the number of processors it can take advantage of. By taking advantage of reduced instruction sets a JIT compiler may be able to produce a smaller exe size resulting in less paging, and high performance. C# also allows you to pass parameters by reference, instead of forcing you to pass by value (as Java does). C# allows pointers using the unsafe keyword. If you really want to get funky then C# will let you. So the short answer as to whether C# will be slower than C++? 'It depends'. It depends on how the C++ code was written, which processor it targets, if it does all the range and resource allocation checks that should be done, but hardly anyone ever does, and in the end the type of application. Benchmarks can be setup that will show C# is faster than C++ and others that show C++ is faster than C#. cheers, Chris M -
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
I agree that Java will always be slower than C++. That being said, I don't think it really matters for 99% of the users out there. Todays processors are so fast, and memory is so cheap that nobody is going to care if a java version is 20% slower than a c++ version. Java's real threat to C++ is its simplicity. Companys will end up going with Java (or C#) because programmer will get more done faster. Personally I found that I can code 3x faster in Java than I can in C++. Java programmers should also be cheaper than C++ programmers, since Java can be mastered an order of magnitude faster than C++. Chris Hafey
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
Hello, the codegurus around the world. A couple of years ago, I had one experiment between AWT and Swing GUI library. I put ListBox of both AWT and Swing on the frame. I found that ListBox of AWT displayed faster by 2 seconds than ListBox of Swing.:(( I said to myself, "What did Sun Microsystem do to GUI library!":mad: Swing makes Java GUI the pigs. X| (However, Swing gives Java developer much benefit.) I guess that some Jave development company still only uses AWT, not Swing.:eek: Have a nice day! -Masaaki Onishi-
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
If anybody wants to know how much slower Java is than C++, then you only need to look at an application like PVCS. A few years ago I was using it with a Pentium 166 and it screamed, now with version 6.7 written totally in Java it crawls on a Pentium III 600. Our company is moving our main application to the web and rewriting it in Java. I can see why people would write these kind of applications with Java that are web intinsive. But a tool such as a version control system that developers use, give me a break. :mad: Wayne
-
can you shed some light on C# and .NET's standing in this regard? It really depends on the situation. Microsoft posted some benchmarks using the PDC bits that showed managed code vs unmanaged code was somewhere between 40% slower to 5%-10% faster, with the average (I think) around the 10-15% slower. This is from failing memory and also using the PDC bits - which were not even vaguely optimised. You can run a tight inner loop that just adds two numbers together and managed vs unmanaged will be about the same. You could do a whole series of small memory allocations and then a big deallocation and the GC model may be faster. You could then compare a 'standard' application that never bothers with bounds checking or the success of resource allocation from the OS with a managed app that has all this in place automatically, and you might find the unmanaged code faster - but only because it's living on the edge. .NET also has the concept of value and reference types. Value types are allocated on the stack and are used for simple objects like
ints andstructs. This is going to give C# an edge over the equivalent Java code, and bring stack allocations back to be on par with unmanaged C++. C# also hasenumsupport, so again there isn't the need for workarounds for enums as there are in Java. In C# everything is type safe which means the compiler can be more aggresive with it's optimisations. C# is never interpreted - it's always compiled to native. Through JITing (and the processor packs MS will be releasing as newer chips are released) the native code produced by the compilers will be able to target not only the processor it is running on, but also the number of processors it can take advantage of. By taking advantage of reduced instruction sets a JIT compiler may be able to produce a smaller exe size resulting in less paging, and high performance. C# also allows you to pass parameters by reference, instead of forcing you to pass by value (as Java does). C# allows pointers using the unsafe keyword. If you really want to get funky then C# will let you. So the short answer as to whether C# will be slower than C++? 'It depends'. It depends on how the C++ code was written, which processor it targets, if it does all the range and resource allocation checks that should be done, but hardly anyone ever does, and in the end the type of application. Benchmarks can be setup that will show C# is faster than C++ and others that show C++ is faster than C#. cheers, Chris MWe'll still have to wait for the final release of Visual Studio, but I'm willing to bet C# is not compiled. I'm also willing to bet a well written C++ windows application (non-MFC) will always beat a well written C# application. Don't forget C#'s API call the win32 API. Which results in more overhead. (Of course the same could be said for MFC). But Microsoft has been able to pull a few rabbits out of their hat, so we'll just have to see. -Ric
-
If anybody wants to know how much slower Java is than C++, then you only need to look at an application like PVCS. A few years ago I was using it with a Pentium 166 and it screamed, now with version 6.7 written totally in Java it crawls on a Pentium III 600. Our company is moving our main application to the web and rewriting it in Java. I can see why people would write these kind of applications with Java that are web intinsive. But a tool such as a version control system that developers use, give me a break. :mad: Wayne
I did a test not too long ago on populating a AVL tree (auto-balancing binary tree) in Sun and IBM Java and comparing it with my C++ versions. The Java version ran _14x slower._ Well, come to find out it was the portion that read my input file instead of actually populating the tree that was slow. In fact, with just populating the tree, IBM Java actually beat C++ Builder. (Well, I was shocked anyway.) After doing some mods to the I/O (using BufferedInputStream) I cut the I/O difference down to about 6-7 times slower than C++. Amazing. Unbounded I/O was the problem (i.e. reading data while testing for EOF). I suspect Java has these pockets of slowness in the API that cause the whole thing to seem sluggish in real world apps.
-
We'll still have to wait for the final release of Visual Studio, but I'm willing to bet C# is not compiled. I'm also willing to bet a well written C++ windows application (non-MFC) will always beat a well written C# application. Don't forget C#'s API call the win32 API. Which results in more overhead. (Of course the same could be said for MFC). But Microsoft has been able to pull a few rabbits out of their hat, so we'll just have to see. -Ric
but I'm willing to bet C# is not compiled eh? All .NET languages get compiled to MSIL and then to native before they run (or compiled to native at install time). The .NET runtime isn't an interpreter. cheers, Chris Maunder
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
Hello! >> No matter how good the JITs get, Java will always be slower than C++. << OK. But same thing I could say about assembler and C++. Code written in C++ will allways be slower that code written in assembler. But who care today about this and write your code in assembler (or even in machine code)? Real programmers? I think, we should allways try find best solution for specific problem. For example, if I can write solution in short time in C# (or in Java, or even in VBScript) and my customer is satisfied with it, then I do this in such way and who will care if some operations in this solution took 10ms or 80ms. Of course, if customer complain that this solution is slow, then I can re-write this in C++... Have technically prefect solution, fastest in the world, is fine, but there are other factors (like time to deliver, feature set, cost of resources, ...) that may be very important, too. Of course, if you writing something as your hobby, in your spare time, or as GPL'ed open source project (no offense), maybe your first priority can be "fastest code in the world", but this is not situation of most of us. Just my HO. SlavoF "I hear and I forget. I see and I remember. I do and I understand." --Confucius
-
I agree that Java will always be slower than C++. That being said, I don't think it really matters for 99% of the users out there. Todays processors are so fast, and memory is so cheap that nobody is going to care if a java version is 20% slower than a c++ version. Java's real threat to C++ is its simplicity. Companys will end up going with Java (or C#) because programmer will get more done faster. Personally I found that I can code 3x faster in Java than I can in C++. Java programmers should also be cheaper than C++ programmers, since Java can be mastered an order of magnitude faster than C++. Chris Hafey
I've found that certainly here in the UK there is a stigma about Java applications being too slow. "The GUI's are great, but it's too slow". Despite the actual performance characteristics and any advantages Java has, people tend to discard it as a viable option. However, much as I hate to admit it (because I actually like Java), the Java app.s I've had anything to do with have seemed slow, like Together Control Center (used to be much faster) and Star Office.:(
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
I recently made the mistake of volunteering to be the Information officer for my son's local Little League baseball league. This involved keeping team rosters, scores, etc. updated on the MyTeam web site. MyTeam is completely written in Java. It has to be the most poorly written, slowest piece of crap I have ever had to contend with. If that is an example of a Internet-Java application, I want nothing more to do with them in the future!.
-
but I'm willing to bet C# is not compiled eh? All .NET languages get compiled to MSIL and then to native before they run (or compiled to native at install time). The .NET runtime isn't an interpreter. cheers, Chris Maunder
Sorry I meant I'm willing to bet C# is not compiled to native code. As for .NET runtime not being an interpreter, we'll just have to see. I'm really skeptical about the whole converted to native code at install time, but if anyone can do this, it's Microsoft. -Ric
-
I have always been saying this to my friends and colleagues that No matter how good the JITs get, Java will always be slower than C++. See whole article at Java Lobby And also read readers' comments and tell me what do you think? :) ;) ;P :-D :cool: And Chris, you have worked with C# and .NET, can you shed some light on C# and .NET's standing in this regard? Farhan
Having recently moved from an Oracle 7 to Oracle 8 environment, I was initially delighted to see that the client admin tools looked really cool and quite flashy. Unfortunately, I next began to realize that they ran like snails. Every single admin tool was completely re-written in Java and the Win32 apps were dropped. The performance was worse than slow and so I now do all my admin stuff using the command line tools instead. I have no idea what Oracle used to do their testing and QA on before they ever released these products, but on a 300 MHz PC with 256 MB of memory, they do not provide anything close to acceptable performance. Just my 2 cents. Chris
-
Sorry I meant I'm willing to bet C# is not compiled to native code. As for .NET runtime not being an interpreter, we'll just have to see. I'm really skeptical about the whole converted to native code at install time, but if anyone can do this, it's Microsoft. -Ric
Output from all dotnet languages is MSIL. MSIL is compiled to *native* code by the JIT compiler before running - the code is *never* interpreted. You can preJIT (for example, at install time) using NGEN tool. NGEN stands for Native Image Generator. Tomasz Sowinski -- http://www.shooltz.com.pl
-
can you shed some light on C# and .NET's standing in this regard? It really depends on the situation. Microsoft posted some benchmarks using the PDC bits that showed managed code vs unmanaged code was somewhere between 40% slower to 5%-10% faster, with the average (I think) around the 10-15% slower. This is from failing memory and also using the PDC bits - which were not even vaguely optimised. You can run a tight inner loop that just adds two numbers together and managed vs unmanaged will be about the same. You could do a whole series of small memory allocations and then a big deallocation and the GC model may be faster. You could then compare a 'standard' application that never bothers with bounds checking or the success of resource allocation from the OS with a managed app that has all this in place automatically, and you might find the unmanaged code faster - but only because it's living on the edge. .NET also has the concept of value and reference types. Value types are allocated on the stack and are used for simple objects like
ints andstructs. This is going to give C# an edge over the equivalent Java code, and bring stack allocations back to be on par with unmanaged C++. C# also hasenumsupport, so again there isn't the need for workarounds for enums as there are in Java. In C# everything is type safe which means the compiler can be more aggresive with it's optimisations. C# is never interpreted - it's always compiled to native. Through JITing (and the processor packs MS will be releasing as newer chips are released) the native code produced by the compilers will be able to target not only the processor it is running on, but also the number of processors it can take advantage of. By taking advantage of reduced instruction sets a JIT compiler may be able to produce a smaller exe size resulting in less paging, and high performance. C# also allows you to pass parameters by reference, instead of forcing you to pass by value (as Java does). C# allows pointers using the unsafe keyword. If you really want to get funky then C# will let you. So the short answer as to whether C# will be slower than C++? 'It depends'. It depends on how the C++ code was written, which processor it targets, if it does all the range and resource allocation checks that should be done, but hardly anyone ever does, and in the end the type of application. Benchmarks can be setup that will show C# is faster than C++ and others that show C++ is faster than C#. cheers, Chris MThanks a lot for a detailed answer, Chris. :) I liked the way you put it, depends on how the C++ code was written, which processor it targets, if it does all the range and resource allocation checks that should be done, but hardly anyone ever does, and in the end the type of application. Benchmarks can be setup that will show C# is faster than C++ and others that show C++ is faster than C#. But I found your asnwer to be more of pro-C# ;P :-D. Never mind. Cheers to you as well. Farhan