C++ versus Java

[Dy7SLyTq]

the biggest problem of java for me is the fact that a) its jit compiled, making it slower than equivalent c++ program b) everything has to be an object (which is why i dont like ruby)

[Cheraphy]

The thing about java is it's compilers can do optimizations that C++ compilers are only recently catching up to. JIT compilation doesn't mean it's always going to be slower than equivalent C++ programs. And if you're using C++ instead of C, and you're not using it for the Object Oriented aspect, you may as well be using C.

[N36fSL3A]

I think he means that he doesn't want EVERYTHING being an object.

In C++ everything isn't an object.

[Dy7SLyTq]

The thing about java is it's compilers can do optimizations that C++ compilers are only recently catching up to. JIT compilation doesn't mean it's always going to be slower than equivalent C++ programs.

interesting could you please expand on that?

I think he means that he doesn't want EVERYTHING being an object.

correct. in java i cant write a single program without using a class ie the one that contains main. i can however use a combination of data structures and functions in c++ without being forced to have them in a class

[Cheraphy]

I wouldn't be able to, but rapidcoder definitely can.

[chrisname]

@DTSCode
One reason is that Java can do platform-specific optimisations at runtime because it recompiles code from an intermediate form (Java bytecode) to native code, and it knows the exact processor that the native code is running on. C++ compilers, for comparison, only know the target architecture (e.g. x86, x86-64, ARM, MIPS, etc.). The code that a C++ compiler generates has to run on any processor in that architecture, which limits the assumptions it can make and thus the performance of the code it can generate. The dynamic recompiler that most JVMs have can detect the exact processor and tailor its output to it. Of course, you can do some amount of processor-specific optimisation with C++ compilers; g++ has some processor-specific flags as well as flags to enable things like SSE which can produce extremely efficient code. The advantage of Java is that the VM can do that optimisation at runtime without the risk of generating unsupported opcodes because it can detect whether the platform will support those opcodes beforehand. Of course, that does increase the startup time, but for a CPU-bound program that runs for a long time, like a video game, the extra overhead would be nothing compared to the performance gain achieved. Of course, few or no compiler optimisations can do much with an I/O-bound process. Using asynchronous I/O with events can help if the program doesn't need the I/O to complete before it can do something else (using asynchronous I/O would be pointless if you then had to wait for it to complete before moving on to the next thing).

I think another reason might be that because bytecode is a high-level machine language, it is more flexible than native code and more simple than C++, so it can be re-ordered more. It's easier for the (re)compiler to figure out what's going on.

[Dy7SLyTq]

thanks for that explanation. that makes more sense that what i thought jit compilation was in my head

[rodiongork]

I'm a professional C/C++ developer who migrated to java almost three years ago. I had a lot of fun reading this thread, thanks :)

I don't want to argue, but only to add one thing which was forgotten about java - and it is a great advantage.

Java have http://maven.apache.org/ and it is really cool. Project build tool can download necessary libraries for you from central repository and you need not kick around forums and at first seek for some library to implement some functionality - and then to tune it to your project and compiler.

Maven has its problems of course, but it is anyway level above all build tools like make, ant etc - mainly due to existence of central repo which is used by all of the world. This really boosts opensource code reusing, and development of important tools, libraries and frameworks.

Besides this maven can download plugins from the same repo which could be used for automated testing, running servers, checking style, deploying to production etc. Plugins are developed in the same way as libraries, so there are a lot of advantages in such an approach.

[rapidcoder]

@chrisname - right, RAII and move semantics are also very, very cool features of C++, although I wouldn't say RAII is close to GC. As long as I can't create an efficient persistent map with it, it is not.

@Cubbit The nice thing about RTSJ is you need to do those special things only in the realtime parts of the code, which is often just a tiny piece of code. All the rest runs with GC and standard Java. If you write a realtime C++ app, you have to do all those special things as well. Note that in C++ memory management is not realtime without special actions taken by the programmer (using a realtime allocator on top of realtime OS is not enough).

BTW: G1 or C4 collectors allow for writing single ms latency apps with GB sized heaps. It is for sure not enough for HFT, but just fine for games, video, simulations, etc.

[Dy7SLyTq]

can i derail for a second? i have another question about jit compillers. how does one generate byte code? is it like their own made up machine code that is then translated to actual machine code? is there formalized byte code? if so, is there a site where i can learn it?

[chrisname]

DTSCode wrote:

how does one generate byte code?

The same way one generates native code.

is it like their own made up machine code that is then translated to actual machine code

That's exactly what it is. One noticeable difference is that virtual machine languages tend to be stack-based instead of register-based, because where hardware registers are part of the CPU (and thus much faster to access than variables in system memory), virtual registers are in memory, so accessing them is no faster than accessing a virtual stack, which is easier to implement and to use. In code, the difference looks like this:

Register based:

mov a, 2
mov b, 2
add b ; add b to a
; a = 4

Stack based:

push 2
push 2
add
pop my_variable ; my_variable = 4

is there formalized byte code?

Yes. Java has one (Java bytecode), the .Net framework (C#, VB.Net, etc.) has one (CIL [Common Intermediate Language], pronounced "sil") and Python has one (Python bytecode).

is there a site where i can learn it?

Also yes:
* Java bytecode basics: http://www.javaworld.com/jw-09-1996/jw-09-bytecodes.html
* CIL tutorial: http://www.dontbreakthebuild.com/2012/02/16/learning-cil-series-part-1/
* Python bytecode: http://docs.python.org/2.4/lib/bytecodes.html [old]

CIL is my favourite because it doesn't look like an assembly language at all:

.assembly Hello {}
.assembly extern mscorlib {}
.method static void Main()
{
    .entrypoint
    .maxstack 1
    ldstr "Hello, world!"
    call void [mscorlib]System.Console::WriteLine(string)
    ret
}

[Dy7SLyTq]

thanks chrisname!

[Cheraphy]

I program exclusively in bytcode for a ternary virtual machine. </malbolge>

[chrisname]

@Cheraphy
That's nothing, I program exclusively in bytecode for a quantum virtual machine that I invented. Here's a "hello world" sample:

.def msg "Hello, world\0" // Define variable 'msg'
create in                 // Create new qbit to use as input
create out                // Create qbit to use as output
set in, msg               // Set input qbit to point to message
entangle out, r1          // Entangle input and output qbits
call writeline            // Write the message 

[VitaDev]

@rodiongork

You should check out Gradle, it's poised to replace Maven (which, imo, is just completely broken by design).

http://www.gradle.org/

[rodiongork]

You should check out Gradle

Yes, I think I've heard of it - and heard that some big projects moved to it. I know many disadvantages of maven, but for my purposes they are not crucial (and not all are fixed by gradle, it looks). Anyway both of them are something incomparably cooler than my recollections of "make". :)

[TheBeardedQuack]

I'd been learning C++ for about 2 years before I tried java and honestly I found the differences a nightmare... I know once you're in them a lot is the same but it's too much for me XD.

Although it can be dangerous at times I prefer to manage my own memory thanks. And every program having to be an actual class seems rather pointless to me too.

If you're not bothered by any of this then just look a at the obvious pros and con's...

Why choose C++
Faster execution speeds(because it's fully compiled)
Cheaper memory handling and more control over it too
Compatible with nearly all machines (unless you use system specific code)
Direct links into OS's

Why choose java
99% portability
Extensive core library
Quicker compiling

[Dy7SLyTq]

Faster execution speeds(because it's fully compiled)

as i just learned, jit compiling is theoretically faster

Compatible with nearly all machines (unless you use system specific code)

almost all languages are, unless its by design a dsl

Direct links into OS's

so do most other languages, because of assembly interfaces

[Cubbi]

Cherapy wrote:

JIT compilation doesn't mean it's always going to be slower

DTSCode wrote:

as i just learned, jit compiling is theoretically faster

That was not what Cherapy said.

[chrisname]

@Cubbi
In your experience, has JIT-compiled code ever been faster in practice?