|
|
|
|
|
|
by SleepyMyroslav
7 days ago
|
|
|
I am not GP poster. I find pron points interesting even if I work in the gamedev on game engines. If you don't mind I will try to explain how I see them interesting. Since I have not worked on Rust systems I will stick to C++. Note his example elsewhere in this discussion of 2 projects done at same time in Java and Rust and the complaint that Rust system used too many locks. This can happen in C++ too. But why it does not happen in (my) practice? Because C++ evolved to not use locks in large scale parallel systems. This was said from mainstage conferences keynotes at least since 2013 [1]. So there is "normal C++" and "C++ that works at large scale" and they are not the same C++ languages. The performance scales between them are many orders of magnitude. Imho it does not mean that Java anywhere near the best of what C++ can do. So here we are talking past each other. pron is correct that Java is not bad and you are correct that you have no reasons to leave Rust. 1. https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-se... |
|
|
I don't think you're aware of where Java is today. Here's a recent talk about some of the issues we're working on now: https://youtu.be/J4O5h3xpIY8
I said that in the past the people who believed Java can't match or exceed C++'s performance were typically those with a lot of low-level programming experience and little or no experience with Java, while today it's mostly people with little experience with low-level programming, but I think you may be in the first group. To people in that group, the question I pose is: what is exactly that you'd think makes Java harder to compile in an optimised way than C++? That's not hard to answer for JS or Python, but you'll find that it is hard to answer for Java. (I don't have a question to ask the people in the second group because they are typically people who don't know much about software performance to begin with, don't have any informed intuition about it, and just say nonsensical things like "runtime overhead").
On the whole, the range of optimisations available to our compiler is larger than to a C++ compiler, and we have a wider selection of memory management optimisations, too (this matters mostly in large programs with a wide variety of object lifetimes).
So if you were to ask me why I would speculate that C++ can't be as well-optimised as Java, I could tell you that it's because it can't inline as aggressively and it can't move pointers (due to its constraints and intended domains).
I think an answer for why Java wouldn't be as optimised at C++ could refer to things like "Java has an interpreter" (true, but that design was chosen to support more aggressive speculative optimisations in the compiler), or "Java has moving-tracing GCs" (true, and that was chosen because they offer an optimisation of memory management in a wide variety of situations). The JVM was designed to address specific performance shortcoming of low-level languages; true, they don't result in a win in all situations, and in some they even lose, but these mechanisms were chosen because they do win in many situations.
In general, when we (the JVM's developers) see something that C++ can do faster, we treat it as a performance bug and solve it. What John (the chief JVM architect) is talking about is related to the last area where Java suffers (arrays-of-structs) to which we'll start delivering the solution very soon.
There are some intentional performance-related tradeoffs that both our team and the C++/gcc/LLVM teams make, but they are about offering better or worse performance under different circumstances, and definitely not universally.
As an example I was personally involved with, the C++ team and us intentionally chose differenet approaches to coroutines that give better performance in some situations and worse in others, and we both opted to prioritise different situations (i.e. situations where cache misses are more or less likely).
In general, C++ offers better performance than Java in some programs, and the opposite is true in other programs. On average, their performance has come closer over the years, each improving the areas where they were weaker.
As to "the best of what C++ can do", it's hard to define, because, as I said, every Java program can be seen as a C++ program, so technically C++ can always match the performance of a Java program given enough effort and expertise. But when talking about performance, what's practically possible matters much more than what's hypothetically possible, and in those programs where Java wins, achieving the same performance in C++ is just far more costly.
But also, given that both languages can and do come close to the maximal hypothetical hardware performance, they're rarely too far apart (unless we're considering warmup time), and they're both very much "anywhere near" each other almost all the time.