3 ms·

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.

MrBuddyCasino 4y ago
I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.
- marginalia_nu 4y ago
  Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.
  - kaba0 4y ago
    FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example). Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).
    - marginalia_nu 4y ago
      Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.
      - MrBuddyCasino 4y ago
        We'll see how far value objects and the vector API go. The lack of operator overloading makes writing scientific/numerical code a bit awkward, though this could be mitigated by using Kotlin instead.
- pjmlp 4y ago
  Native interop is everywhere on Android, but then again, good luck having updated Java features on ART.
kaba0 4y ago
For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.
- geodel 4y ago
  It is more of generate more garbage / collect more garbage (Java) vs Not generating that much garbage in first place (Go). This is use case for writing GC benchmarks developers not for typical enterprise CRUD developers.
- marginalia_nu 4y ago
  It's definitely a factor, but it's not really enough. You can squeeze far more performance out of the hardware than idiomatic Java permits.
  - kaba0 4y ago
    Sure, but not with another managed language like Go.
    - marginalia_nu 4y ago
      I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?
      - kaba0 4y ago
        Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable to C, the reason for the performance discrepancy between the two is memory layout, which may or may not matter for the problem at hand. In my experience, most (especially business) applications are absolutely not going through millions of data entries doing some local calculations over them, that part is delegated to a database. They either do some IO over them, or have much smaller element sizes. Java has escape hatches even for handling some of the “millions-of-elements in a hot loop”, but for an AAA game engine it might not be the best choice, but for anything else? It is more than fair game.

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.

MrBuddyCasino 4y ago

I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.

marginalia_nu 4y ago
Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.
- kaba0 4y ago
  FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example). Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).
  - marginalia_nu 4y ago
    Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.
    - MrBuddyCasino 4y ago
      We'll see how far value objects and the vector API go. The lack of operator overloading makes writing scientific/numerical code a bit awkward, though this could be mitigated by using Kotlin instead.
pjmlp 4y ago
Native interop is everywhere on Android, but then again, good luck having updated Java features on ART.

kaba0 4y ago

For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.

geodel 4y ago
It is more of generate more garbage / collect more garbage (Java) vs Not generating that much garbage in first place (Go). This is use case for writing GC benchmarks developers not for typical enterprise CRUD developers.
marginalia_nu 4y ago
It's definitely a factor, but it's not really enough. You can squeeze far more performance out of the hardware than idiomatic Java permits.
- kaba0 4y ago
  Sure, but not with another managed language like Go.
  - marginalia_nu 4y ago
    I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?
    - kaba0 4y ago
      Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable to C, the reason for the performance discrepancy between the two is memory layout, which may or may not matter for the problem at hand. In my experience, most (especially business) applications are absolutely not going through millions of data entries doing some local calculations over them, that part is delegated to a database. They either do some IO over them, or have much smaller element sizes. Java has escape hatches even for handling some of the “millions-of-elements in a hot loop”, but for an AAA game engine it might not be the best choice, but for anything else? It is more than fair game.