4 ms·

This is not an argument I can win, that is constructive or necessarily meaningful, but here's what happened when someone tried to translate C++ to an equivalent

by YZF 12y ago

This is not an argument I can win, that is constructive or necessarily meaningful, but here's what happened when someone tried to translate C++ to an equivalent Java program: http://codegolf.stackexchange.com/a/26536 http://codegolf.stackexchange.com/a/26536 (x2.5) Also see: http://benchmarksgame.alioth.debian.org/u64/java.php http://benchmarksgame.alioth.debian.org/u64/java.php (median x2 but this is stuff people spent time on optimizing which is not really what we're talking about here) Java is not 20% slower or just as fast. But if it is please submit your Java solutions to the bench mark game for us to see. Python is a few hundred time slower as long as you restrict yourself to native types (e.g. strings, integers, dictionaries, lists). Once you start defining your own classes and do more sophisticated things you get a lot slower. At any rate, my point was not to pick some specific number, my point was that sometimes you just don't care at all about how fast it runs. The x10000 was from a real world system but this can vary - a lot.

pron 12y ago
It's not hard to write single-threaded C/C++ code that's significantly faster than Java (although it will become harder once Java gets value types, that will address Java's biggest performance pitfall, namely cache-misses), and the simpler the code the better the chances for success (as complex code requires architecture employing virtual methods, and virtual method invocation in Java is faster than in C++ due to JIT inlining). But writing multithreaded code in C++ that's faster than Java is a lot harder, so much so that the C++ code will probably be significantly slower. The reason is that general-purpose lock-free data structures are a lot easier to write when you have a good GC (plus, the JDK includes state-of-the-art concurrent data structure implementations).
igouy 12y ago
>>but this is stuff people spent time on optimizing << Optimizing both Java and C++ programs.
deleted 12y ago
[deleted]
tormeh 12y ago
About optimization: If you really want to, the JVM can be surprisingly unrestrictive. You'd be amazed at the slightly mad things for example HFTs do with it. Advanced techniques include object reuse so you never activate the GC and unsafe calling of native code. Then there's the weird things you can do with the JVM directly. I can't find anything right now, but I recall weird annotations and multiline JVM arguments more wizardlike than anything. Finally there's alternative JVMs for those who want that.
- FreezerburnV 12y ago
  In regards to weird things you can do with the JVM: You can actually allocate memory outside of the garbage collect from inside pure Java code. (Unsafe.allocateMemory, specifically. or you can use ByteBuffers, but I'm not sure which one is faster or if a ByteBuffer still interacts with the GC) This can allow you to deal with "objects" which are entirely outside of the GC, and can actually be a decent chunk faster then using normal objects. I did a microtest recently (which can mean absolutely nothing in practice) where allocating two normal objects and doing something with them was about 30% slower than dealing with memory outside the GC. As for the other things you mentioned, those are actually pretty routine. At least in some places. If you're working on a game, then you're going to be reusing objects and calling native functions as a normal thing :)
  - tormeh 12y ago
    I don't think unsafe calling is standard at all. It's non-standardized as well. Normally the JVM would copy objects between the JVM and the native process. With unsafe, they are operating on the same bits of memory.
    - FreezerburnV 12y ago
      Aaah, that's what you meant by unsafe. I thought you meant that using a native code call was technically unsafe. Thanks for the clarification. (and that actually sounds pretty awesome for game development, I'll have to look into it)

by YZF 12y ago

pron 12y ago

It's not hard to write single-threaded C/C++ code that's significantly faster than Java (although it will become harder once Java gets value types, that will address Java's biggest performance pitfall, namely cache-misses), and the simpler the code the better the chances for success (as complex code requires architecture employing virtual methods, and virtual method invocation in Java is faster than in C++ due to JIT inlining). But writing multithreaded code in C++ that's faster than Java is a lot harder, so much so that the C++ code will probably be significantly slower. The reason is that general-purpose lock-free data structures are a lot easier to write when you have a good GC (plus, the JDK includes state-of-the-art concurrent data structure implementations).

igouy 12y ago

>>but this is stuff people spent time on optimizing << Optimizing both Java and C++ programs.

deleted 12y ago

[deleted]

tormeh 12y ago

About optimization: If you really want to, the JVM can be surprisingly unrestrictive. You'd be amazed at the slightly mad things for example HFTs do with it. Advanced techniques include object reuse so you never activate the GC and unsafe calling of native code. Then there's the weird things you can do with the JVM directly. I can't find anything right now, but I recall weird annotations and multiline JVM arguments more wizardlike than anything. Finally there's alternative JVMs for those who want that.

FreezerburnV 12y ago
In regards to weird things you can do with the JVM: You can actually allocate memory outside of the garbage collect from inside pure Java code. (Unsafe.allocateMemory, specifically. or you can use ByteBuffers, but I'm not sure which one is faster or if a ByteBuffer still interacts with the GC) This can allow you to deal with "objects" which are entirely outside of the GC, and can actually be a decent chunk faster then using normal objects. I did a microtest recently (which can mean absolutely nothing in practice) where allocating two normal objects and doing something with them was about 30% slower than dealing with memory outside the GC. As for the other things you mentioned, those are actually pretty routine. At least in some places. If you're working on a game, then you're going to be reusing objects and calling native functions as a normal thing :)
- tormeh 12y ago
  I don't think unsafe calling is standard at all. It's non-standardized as well. Normally the JVM would copy objects between the JVM and the native process. With unsafe, they are operating on the same bits of memory.
  - FreezerburnV 12y ago
    Aaah, that's what you meant by unsafe. I thought you meant that using a native code call was technically unsafe. Thanks for the clarification. (and that actually sounds pretty awesome for game development, I'll have to look into it)