2 ms·

An interesting case of the deep-nested delay affecting a cool-headed and respectful discussion. Law of unintended consequences I guess. I would respectfully co

An interesting case of the deep-nested delay affecting a cool-headed and respectful discussion. Law of unintended consequences I guess. I would respectfully contend that outside of micro-benchmarks (which kill Java because of long startup time and no chance to JIT) that Java is as fast as C++, and in the presence of lots of cores probably faster. This is again based in large part on my direct anecdotal experience, I would be very interested to hear about everyone else's experience in the matter. But the real point is that with Moore's law now working on cores instead of mhz, single-threaded performance just doesn't matter that much going forward. Exponential increase and all that. For a look at where this shit is going take a look a look at Azul. http://www.azulsystems.com/ http://www.azulsystems.com/

10ren 18y ago
I think that was its intended consequence (though it didn't affect my replies.) I'm glad I put you on the spot, because your reasoning was worth hearing. You're making an interesting case. I haven't heard any claim that Java actually is faster than C++ in practice, just that it theoretically could be, because of JIT optimizations (then again, I don't think C/C++ is used that much in the server, anyway.) I also haven't heard of Java getting a comparative advantage due to multicore, just that FP would. But that's not to say it isn't true. You could be right. Interesting. (The link seems to be commodity computing, like Sun blade servers).
- benreesman 18y ago
  Let's carry on this conversation via email, my address is in my profile. I can share with you some of the sources that have led me to form this opinion. +1 thoughtful and respectful debate.
  - icey 18y ago
    It's kind of a shame that the code that was meant to stop flamewars stymies interesting conversations like this one.
    - rufo 18y ago
      Indeed - I'm not a Java or C++ programmer, but I was finding this conversation rather interesting to follow along.
      - benreesman 18y ago
        I would love to chat with one or both of you about my opinions on the JVM if you're interested. Please email me and we can meet up on IRC or something.
  - 10ren 18y ago
    ...there is no email address in your profile. But I don't think there's any problem putting the links here, from HN's point of view (unless you want to keep them private, of course).
- AlisdairO 18y ago
  I'm looking at JVM performance optimisations at the moment (I'm working on cache-friendly data structures for DBMSs, and interested in how running this stuff on a JVM affects things). As just a little test, I wrote an identical binary search in Java and C over a large array (with randomly increasing contents), with a very large number of iterations. I pregenerated all the search numbers to eliminate discrepancies with regards to time taken for RNG. It turned out that for completely predictable searches C was always a bit faster, and over smaller array sizes C also beat out java. As the array got over about a million elements in size, Java caught up to and then got significantly faster than C. On further investigation of a 150 million element dataset, Java was performing 1/3 again as many instructions, but missing cache half as much. I've been spending some time looking at all the JVM performance optimisations, but I still haven't worked out why this is - a random binary search isn't exactly a test case that's run time optimisation-specific. It's fascinating stuff, anyway.

10ren 18y ago

I think that was its intended consequence (though it didn't affect my replies.) I'm glad I put you on the spot, because your reasoning was worth hearing. You're making an interesting case. I haven't heard any claim that Java actually is faster than C++ in practice, just that it theoretically could be, because of JIT optimizations (then again, I don't think C/C++ is used that much in the server, anyway.) I also haven't heard of Java getting a comparative advantage due to multicore, just that FP would. But that's not to say it isn't true. You could be right. Interesting. (The link seems to be commodity computing, like Sun blade servers).

benreesman 18y ago
Let's carry on this conversation via email, my address is in my profile. I can share with you some of the sources that have led me to form this opinion. +1 thoughtful and respectful debate.
- icey 18y ago
  It's kind of a shame that the code that was meant to stop flamewars stymies interesting conversations like this one.
  - rufo 18y ago
    Indeed - I'm not a Java or C++ programmer, but I was finding this conversation rather interesting to follow along.
    - benreesman 18y ago
      I would love to chat with one or both of you about my opinions on the JVM if you're interested. Please email me and we can meet up on IRC or something.
- 10ren 18y ago
  ...there is no email address in your profile. But I don't think there's any problem putting the links here, from HN's point of view (unless you want to keep them private, of course).
AlisdairO 18y ago
I'm looking at JVM performance optimisations at the moment (I'm working on cache-friendly data structures for DBMSs, and interested in how running this stuff on a JVM affects things). As just a little test, I wrote an identical binary search in Java and C over a large array (with randomly increasing contents), with a very large number of iterations. I pregenerated all the search numbers to eliminate discrepancies with regards to time taken for RNG. It turned out that for completely predictable searches C was always a bit faster, and over smaller array sizes C also beat out java. As the array got over about a million elements in size, Java caught up to and then got significantly faster than C. On further investigation of a 150 million element dataset, Java was performing 1/3 again as many instructions, but missing cache half as much. I've been spending some time looking at all the JVM performance optimisations, but I still haven't worked out why this is - a random binary search isn't exactly a test case that's run time optimisation-specific. It's fascinating stuff, anyway.