Elysian Shadows

dandymcgee wrote:

GyroVorbis wrote:I'm sorry, but Java, C#, and JIT compiled languages are never going to fully replace C/++, just as C/++ will never (and cannot possibly) completely replace assembly.

I have no doubt that Java/C# will continue to become more popular for a portion of the market than C/++ (as they already have), but replace? You aren't ever going to see a JIT compiled language catching on with embedded platforms, drivers, operating systems, or anything of the like. People said the same thing about C++ "completely" replacing C. Most drivers and OSs to this day are STILL written in C (not even C++).

Until JIT compilers literally run in hardware, I cannot foresee, C, C++, or assembly ever not having a place in the market, and I believe that saying they will be "replaced" is neglecting a large portion of the market geared towards low-level development and software-hardware integration.

Well said.

+1

MrDeathNote wrote:

dandymcgee wrote:

GyroVorbis wrote:I'm sorry, but Java, C#, and JIT compiled languages are never going to fully replace C/++, just as C/++ will never (and cannot possibly) completely replace assembly.

I have no doubt that Java/C# will continue to become more popular for a portion of the market than C/++ (as they already have), but replace? You aren't ever going to see a JIT compiled language catching on with embedded platforms, drivers, operating systems, or anything of the like. People said the same thing about C++ "completely" replacing C. Most drivers and OSs to this day are STILL written in C (not even C++).

Until JIT compilers literally run in hardware, I cannot foresee, C, C++, or assembly ever not having a place in the market, and I believe that saying they will be "replaced" is neglecting a large portion of the market geared towards low-level development and software-hardware integration.

Well said.

+1

+2

I'm sorry, but Java, C#, and JIT compiled languages are never going to fully replace C/++, just as C/++ will never (and cannot possibly) completely replace assembly.

No, it never will fully replace. However, Java/C# are going to become the next "general purpose" language of choice, and will become the common language everyone knows/uses. Schools already have replaced teaching C/C++ with Java for programming classes, and so we can assume that's what the programs of tomorrow will be using.

I have no doubt that Java/C# will continue to become more popular for a portion of the market than C/++ (as they already have), but replace?

If you want to be nit-picky, then no, it won't fully replace C/C++. I doubt anything will for several more decades.

I just don't see that hapening. A computer CANNOT run java bytecode as fast as precompiled c/c++.

In theory, compiled code will always run faster than JIT bytecode, I agree, but average programmers aren't going to be spending hours optimizing every single line of code, and Java/C++ has a big advantage here. Writing performance-based programs is a marathon, not as sprint, and since 95% of optimization is about high-level ideas it doesn't really matter if Java/C# lacks low-level features.

Anyway, Java/C# do have some features which can make them run faster than average C/C++ code:

1. Most c/c++ programs are compiled to support LCD of computers. Good thing about bytecode is that it can be compiled to use every feature the computer has, and also make optimizations during run-time.

2. C/C++ was not designed with multi-threading/networking in mind, Java/C# was. Computers are going to get more and more cores, and the higher-level of the newer languages is going to end up with better threaded programs.

3. Any gains in C/C++ compilers will benefit newer languages, as they run on C/C++.

4. Computer vendors are going to push their processors to running Java/C# faster. I will say this is similar to how processors have been directed by C++ - such as optimizing virtual function calls.

5. Java/C# code becomes obsolete slower than C/C++,and especially assembly. If I write the most optimized program in assembly, it won't be the best for long as new processors come out and assembly optimization tricks change. In C/C++, your code will last longer, but low level code style does change, and you will have to rethink optimizations every few years or so. Because Java is higher-level and JIT, it stays "fresh" for very long time.

6. Java is inherently easier to optimize than C++. C++ is just too complex, and a large portion of optimization tricks require non-standard extensions.

Currently, these things aren't making Java/C# faster than C/C++, but the gap will close as time goes by.

P.S.
People suck at predicting future of technology, and so I may be entirely wrong. Just keep in mind that this is all speculation and we won't know until the future arrives.

Frankly, the simple fact that C++ has dependable destructors makes it far more useful to me than C# or Java. Once they bring that feature back, I'll consider using them.

bnpph wrote: 5. Java/C# code becomes obsolete slower than C/C++,and especially assembly. If I write the most optimized program in assembly, it won't be the best for long as new processors come out and assembly optimization tricks change. In C/C++, your code will last longer, but low level code style does change, and you will have to rethink optimizations every few years or so. Because Java is higher-level and JIT, it stays "fresh" for very long time.

Utterly ridiculous, I wasn't going to post a reply because I at least half agree with most of your points but this is just wrong. Java/c# code becomes obsolete faster because they are proprietary. They are updated fairly regularly which can make code in previous versions unsafe eg when generics and type safe collections where introduced now pre java 5 code is unsafe if it uses collections. If you look at C/C++ code from 10 years ago, if it was written well at the time it's still perfectly usable today, you can't say the same for Java.

Utterly ridiculous, I wasn't going to post a reply because I at least half agree with most of your points but this is just wrong. Java/c# code becomes obsolete faster because they are proprietary. They are updated fairly regularly which can make code in previous versions unsafe eg when generics and type safe collections where introduced now pre java 5 code is unsafe if it uses collections. If you look at C/C++ code from 10 years ago, if it was written well at the time it's still perfectly usable today, you can't say the same for Java.

Yeah, that point I made was pretty stupid, but I'd wait until java/c# is finalized and the language stops changing. C++ changed quite a bit in it's early days too. What I was really trying to say was that high-level ideas stay around much longer than low-level ones.

Except that Java or C# require that C++ be faster than them. Ever notice the JVM is written in C++? Yeah, some of the JIT might make it almost the same speed, but because of the nature of a VM, C++ must execute faster than the language it's interpreting.

bnpph wrote:I'd wait until java/c# is finalized and the language stops changing.

Don't hold your breath.

The day Java stops changing is the day Java dies.

Except that Java or C# require that C++ be faster than them. Ever notice the JVM is written in C++? Yeah, some of the JIT might make it almost the same speed, but because of the nature of a VM, C++ must execute faster than the language it's interpreting.

That's not exactly true, as JIT is not interpreting.

Anyways, personally I'm not a fan of Java/C#, I just think you guys are underestimating it. I wish there was a perfect language somewhere between C++, Java, and C#. Maybe someday.

bnpph wrote:

Except that Java or C# require that C++ be faster than them. Ever notice the JVM is written in C++? Yeah, some of the JIT might make it almost the same speed, but because of the nature of a VM, C++ must execute faster than the language it's interpreting.

That's not exactly true, as JIT is not interpreting.

Anyways, personally I'm not a fan of Java/C#, I just think you guys are underestimating it. I wish there was a perfect language somewhere between C++, Java, and C#. Maybe someday.

It's called D. It's a great language with little to no support. So that language exists, but it really isn't ever used, or even thought about. A win for everyone isn't it?

it's generally accepted in computer science that hand written assembly is almost always worse, and further, that it in fact we will reach a point where it cannot possibly be done better than machine optimised code.

What you're arguing about is current generation technology.

Anything that can be done in a static compiler can be done in a JIT compiler.

The main difference between the C++ static compilation strategy and a dynamic compiler such as Java is that the dynamic compiler strategy can use more information to make decisions about what optimisations to do. It can use the program source like C++ but it can also use current runtime properties such as hot code paths and actual machine architecture (which cannot always be known up-front with static compilation).

There are also other differences between C++ and Java which are not relevant to this distinction but which do affect current runtime performance.

Arguing that static compilation will not ever be completely replaced by dynamic compilation is like saying horse and cart will never be completely replaced by cars. It is technically true but despite what may have one time been seen as a neck-and-neck race, there is no competition and no debate about superior performance.

Of course, getting to that point may require a few more decades of advances.

christo wrote:it's generally accepted in computer science that hand written assembly is almost always worse, and further, that it in fact we will reach a point where it cannot possibly be done better than machine optimised code.

What you're arguing about is current generation technology.

Anything that can be done in a static compiler can be done in a JIT compiler.

The main difference between the C++ static compilation strategy and a dynamic compiler such as Java is that the dynamic compiler strategy can use more information to make decisions about what optimisations to do. It can use the program source like C++ but it can also use current runtime properties such as hot code paths and actual machine architecture (which cannot always be known up-front with static compilation).

There are also other differences between C++ and Java which are not relevant to this distinction but which do affect current runtime performance.

Arguing that static compilation will not ever be completely replaced by dynamic compilation is like saying horse and cart will never be completely replaced by cars. It is technically true but despite what may have one time been seen as a neck-and-neck race, there is no competition and no debate about superior performance.

Of course, getting to that point may require a few more decades of advances.

Right. The JVM can do things that a static compiler can't do. For example, it can inline virtual method calls. Sun's HotSpot JVM does this, among other dynamic optimizations.

For example, suppose you have a collection of objects of type A, B, and C, where B and C are subclasses of A. If you're looping over the collection and calling someMethod on each object, HotSpot will watch and see that the object in question is of type C 90% of the time. It will then put in a fast check, and inline C's someMethod.

It also annoys me when people say that the Java garbage collector is slow. Java's garbage collector is extremely efficient. Rich HIckey notes (in his talk here: http://blip.tv/file/1313398 at 38:00) that he ran his multi-threaded Clojure ant colony simulation on one of Azul's Java machines with 600 cores, and it maxed out all of the cores. It was churning 20GB of garbage per second, and the garbage collector only used 7% of the CPU.

Praise the GC all you want. All I know is that when I play 3D Java games it is *obvious* when the GC starts up.

Plus, 7% of 600 cores? You're saying that's a small amount? LOL

TheBuzzSaw wrote:Praise the GC all you want. All I know is that when I play 3D Java games it is *obvious* when the GC starts up.

Plus, 7% of 600 cores? You're saying that's a small amount? LOL

To collect 20GB of garbage per second? Yes. Calling malloc() and free() isn't especially cheap either. And have fun writing a C++ program to efficiently use 600 cores. To be able to efficiently share state between threads, you pretty much need persistent immutable data structures, which would be a nightmare to implement without GC.

I don't know of people saying the GC is slow in Java.

The problem about GC (which I wasn't talking about but hey) is that the decision of when to do the collection is automated and some programmers believe they can do a better job of deciding when to free memory.

For games and other near real time applications, scheduling and maximum wait time of GC is more important than the pure speed of the GC. That's why different GC models are available. The parallel GC for example is slower overall in terms of bytes per second but it happens without stopping the world. Also, tuning GC properties like the maximum heap size (not too big so that you get monster collection events) and increasing the aggressiveness of GC, specifying eden and tenured generation sizes so that short-lived garbage and long-lived garbage don't get mixed up in the same collection events, all these things dramatially affect the impacts of GC on the timing of events in the system.

The main point of this is that there are completely different strategies to solve runtime peformance at work here and saying that managed runtimes and JIT compilers cannot in principle be faster than the simple explicit memory management and static compilation is just ignorant.

If you play high performance games on current generation managed runtimes like Java and you don't get the same performance as C++ well that doesn't surprise me. It's like comparing a race horse to a model T Ford. Which is faster? The race horse.

Plenty of people used to think that cars would never become faster than horses.

Of course they're all dead now