16 ms·

Lets not commit the same sin as the PyPy people, is it really faster than the C++ rendering engine? If not, how far off the mark is it? I really want real numb

Lets not commit the same sin as the PyPy people, is it really faster than the C++ rendering engine? If not, how far off the mark is it? I really want real numbers, not idle conjecture. Gosling was fond of speculating that Java would eventually be faster than C and C++ because of $COOL_FEATURE_X, but nothing ever materialized or made enough of a difference. Concurrent GC didn't make up the difference. JIT didn't make up the difference. Why would I believe anybody else bringing the same message? This cyclical "we're gunna be faster and here is the cool compiler research saying so!" is why the programming language community has thoroughly alienated my colleagues that work in systems. They can't afford to build their systems on speculation, it HAS to work. They believe nothing anybody says about programming languages now. What's the most impactful territory to conquer that could help make up the difference? Rust's design allows for a subset of valid programs that could be constructed in C++. It's the same kind of thinking that Haskell utilizes. The type system is useful in Haskell because it disallows potentially invalid programs giving you a smaller space to reason about. (cf. Total programming) However, that subsetting means avenues and opportunities for optimization are eliminated. Optimization sometimes means doing something batshit. A high-level 6502 emulator a friend wrote in x86 asm comes to mind.

pcwalton 14y ago
It's currently slower, yes. Stack checks and stack switching, for example, are part of the reason; that's why we plan to make them able to be turned off. Certainly, if you need something to be shipped soon, and you need it to be performance-competitive with C++, don't use Rust. Despite the fact that it's backed with LLVM, the compiler is quite immature. I don't think at this point that any significant avenues for optimization are closed off in the Rust language design relative to C++. The safety checks are all designed to be optional.
pron 14y ago
Gosling was fond of speculating that Java would eventually be faster than C and C++... but nothing ever materialized or made enough of a difference. Uhm, I'd say Java already is faster than C++ for all intents and purposes. If your codebase is >50KLOC and the number of developers on your team is more than, say, 4 or 5, then some crazy optimizations that are possible in C++ for small applications are out of the question, and the JIT plus the GC more than make up the remaining difference. Also, modern performance-critical software requires good concurrency, and Java has stuff like fork-join, that I'm not sure is available in standard C++ (it is, of course, available in Cilk). So, even though it's hard to provide hard evidence (because most benchmarks are <50KLOC and written by one or two developers at most), I'd say from experience that Java already is faster than C++ in practically all circumstances (except, maybe, scientific-computation applications), not counting startup time. The only missing piece in the Java performance puzzle is value types and arrays-of-structs, and those, I believe are coming, and should make scientific-computation faster in Java as well.
- codewright 14y ago
  I'll assume you're talking about throughput, rather than latency/real-time constraints. I'm pretty dubious, given that Google extensively utilizes C++ in their more performance sensitive portions of their architecture. Their custom web server, for example, is written in C++. Lets not forget the rather large HPC codebases out there in Fortran. Can you prove any of this?
  - pron 14y ago
    Obviously, Java is less predictable than C++ so it's not suitable for hard real-time (though RTSJ JVMs are!), but I'd say that in the common case, Java would have lower latencies, too (when everything is compiled after a good warmup). I don't know why Google uses C++, but I'd guess that it's for predictability. A web server would rather always have a reasonably low latency than somewhat lower latencies in most cases with a chance for an occasional latency spike. Also, small, well-contained C++ program would probably perform better than Java, and I don't know how big is each of Google's C++ apps. And like I said, this is very hard to prove; it's just been my experience after replacing a couple of legacy C++ apps with Java ones. But I think it could be "theoretically proven" (if that even means anything for such an empirical claim), by analyzing why and where C++ has any performance advantages vs. where Java has them, and showing that the larger the codebase and the team, the C++ advantages must disappear, while Java's become more significant. Just to give two examples of why that should be: in a large application, the domain model might require some class methods to be virtual. The JVM can detect at runtime that in practice only one or two implementations are present, and would inline them. This is not possible for the C++ compiler. The other example is memory management. Java's memory allocation is so much faster than malloc (it's just a pointer bump), allows for better concurrency, and automatically reduces fragmentation. The way to get good memory management in C++ is by forsaking malloc for manual management (say, object pools), but that becomes increasingly difficult to maintain in a large, ever shifting codebase with many developers involved. Also, Java has better concurrency support which is, as you've said, important for throughput. The only counter example is arrays of structs that are simply not supported on the JVM, and where C++ would have obvious cache-miss advantages.

pcwalton 14y ago

It's currently slower, yes. Stack checks and stack switching, for example, are part of the reason; that's why we plan to make them able to be turned off. Certainly, if you need something to be shipped soon, and you need it to be performance-competitive with C++, don't use Rust. Despite the fact that it's backed with LLVM, the compiler is quite immature. I don't think at this point that any significant avenues for optimization are closed off in the Rust language design relative to C++. The safety checks are all designed to be optional.

pron 14y ago

Gosling was fond of speculating that Java would eventually be faster than C and C++... but nothing ever materialized or made enough of a difference. Uhm, I'd say Java already is faster than C++ for all intents and purposes. If your codebase is >50KLOC and the number of developers on your team is more than, say, 4 or 5, then some crazy optimizations that are possible in C++ for small applications are out of the question, and the JIT plus the GC more than make up the remaining difference. Also, modern performance-critical software requires good concurrency, and Java has stuff like fork-join, that I'm not sure is available in standard C++ (it is, of course, available in Cilk). So, even though it's hard to provide hard evidence (because most benchmarks are <50KLOC and written by one or two developers at most), I'd say from experience that Java already is faster than C++ in practically all circumstances (except, maybe, scientific-computation applications), not counting startup time. The only missing piece in the Java performance puzzle is value types and arrays-of-structs, and those, I believe are coming, and should make scientific-computation faster in Java as well.

codewright 14y ago
I'll assume you're talking about throughput, rather than latency/real-time constraints. I'm pretty dubious, given that Google extensively utilizes C++ in their more performance sensitive portions of their architecture. Their custom web server, for example, is written in C++. Lets not forget the rather large HPC codebases out there in Fortran. Can you prove any of this?
- pron 14y ago
  Obviously, Java is less predictable than C++ so it's not suitable for hard real-time (though RTSJ JVMs are!), but I'd say that in the common case, Java would have lower latencies, too (when everything is compiled after a good warmup). I don't know why Google uses C++, but I'd guess that it's for predictability. A web server would rather always have a reasonably low latency than somewhat lower latencies in most cases with a chance for an occasional latency spike. Also, small, well-contained C++ program would probably perform better than Java, and I don't know how big is each of Google's C++ apps. And like I said, this is very hard to prove; it's just been my experience after replacing a couple of legacy C++ apps with Java ones. But I think it could be "theoretically proven" (if that even means anything for such an empirical claim), by analyzing why and where C++ has any performance advantages vs. where Java has them, and showing that the larger the codebase and the team, the C++ advantages must disappear, while Java's become more significant. Just to give two examples of why that should be: in a large application, the domain model might require some class methods to be virtual. The JVM can detect at runtime that in practice only one or two implementations are present, and would inline them. This is not possible for the C++ compiler. The other example is memory management. Java's memory allocation is so much faster than malloc (it's just a pointer bump), allows for better concurrency, and automatically reduces fragmentation. The way to get good memory management in C++ is by forsaking malloc for manual management (say, object pools), but that becomes increasingly difficult to maintain in a large, ever shifting codebase with many developers involved. Also, Java has better concurrency support which is, as you've said, important for throughput. The only counter example is arrays of structs that are simply not supported on the JVM, and where C++ would have obvious cache-miss advantages.