4 ms·

The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues

by pron 3mo ago

The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).

germandiago 3mo ago
Well, yes. True that for long-running apps JVM seems to be tuned. I meant the kind of "perf-to-the-instruction" thst native can generate vs other considerations.
- pron 2mo ago
  One thing we C++ programmers know, though, is that direct control over instructions helps performance in small programs but can hurt it in larger programs. E.g. it is really hard to enjoy the performance benefits that moving collectors and JITs can bring in large C++ applications.
  - germandiago 2mo ago
    I am not sure of the real life difference of this. You can tweak C++ a lot, you can make caches, etc your own with memoization and others. True that you would need to build it by hand and, at that time, maybe it is better to just pick something tried and tested for that use case.
    - pron 2mo ago
      It's not so easy. The pattern you'd want to try and match or beat moving collectors is arenas, and they're really not trivial to use in C++ (or Rust). The only low-level language that supports them well is Zig. But even then, evolution of the program can often require large architectural changes. So yes, in principle it's possible to match and perhaps somewhat exceed Java's performance in C++, even in large programs (just as, in principle, it's possible to match and exceed C++'s performance in Assembly), but we don't care about what's possible in principle; we care about what we can achieve with the budget we have. Or put another way, C++ has better performance/effort than Assembly, and Java has better performance/effort than C++ in large programs (perhaps not in all domains, but in important ones). The JVM was designed to (among other things) specifically make it easier to overcome some known performance problems that large C++ programs experience.
      - germandiago 2mo ago
        > we care about what we can achieve with the budget we have 100% agree on this. This is the last driver for everything else in professional environments. Related: I think C++ safety being driven by profiles and not the Safe C++ stuff that was proposed violates the economic assumption in so many ways that it was the wrong choice for C++.

by pron 3mo ago

germandiago 3mo ago

Well, yes. True that for long-running apps JVM seems to be tuned. I meant the kind of "perf-to-the-instruction" thst native can generate vs other considerations.

pron 2mo ago
One thing we C++ programmers know, though, is that direct control over instructions helps performance in small programs but can hurt it in larger programs. E.g. it is really hard to enjoy the performance benefits that moving collectors and JITs can bring in large C++ applications.
- germandiago 2mo ago
  I am not sure of the real life difference of this. You can tweak C++ a lot, you can make caches, etc your own with memoization and others. True that you would need to build it by hand and, at that time, maybe it is better to just pick something tried and tested for that use case.
  - pron 2mo ago
    It's not so easy. The pattern you'd want to try and match or beat moving collectors is arenas, and they're really not trivial to use in C++ (or Rust). The only low-level language that supports them well is Zig. But even then, evolution of the program can often require large architectural changes. So yes, in principle it's possible to match and perhaps somewhat exceed Java's performance in C++, even in large programs (just as, in principle, it's possible to match and exceed C++'s performance in Assembly), but we don't care about what's possible in principle; we care about what we can achieve with the budget we have. Or put another way, C++ has better performance/effort than Assembly, and Java has better performance/effort than C++ in large programs (perhaps not in all domains, but in important ones). The JVM was designed to (among other things) specifically make it easier to overcome some known performance problems that large C++ programs experience.
    - germandiago 2mo ago
      > we care about what we can achieve with the budget we have 100% agree on this. This is the last driver for everything else in professional environments. Related: I think C++ safety being driven by profiles and not the Safe C++ stuff that was proposed violates the economic assumption in so many ways that it was the wrong choice for C++.