Stroustrup as always fails to recognize the vast surface area of C++ features, foot cannons, and the heavy weight of C compatibility around C++ neck.
C++ barely made sense in 1995. It makes absolutely no sense today.
C++ barely made sense in 1995. It makes absolutely no sense today.
So in other words, Java is bad at scaling a basic math operation like multiplication?
> "In many ways Java is running rings around C++ performance"
The AI-space is proof positive of that being false. C++ is kicking Java's butt, squeezing literally trillions of ops per second of performance, all of this happening before the Java runtime can even startup.
The first transformer-based language model was built with PyTorth; imagine if PyTorch was a python wrapper for Java code instead of C++ code? It'd be garbage. I mean how freaking long did it take for Java to even get a basic Vector API? C++ devs have been writing SIMD optimized code for years now. And besides that, try getting a Java program to scale at tens or even hundreds or thousands of GPUs for a large language model. You'd need GPUs with literally 20-30% more RAM just to accommodate the GC.
As someone working in a team of 3 with a c++ code base this statement is hilarious hyperbole.
This doesn't make any sense and nothing in this comment is something an experienced optimizer would say.
I'm not sure where the fantasy comes from that java is going to beat C++, but anyone experienced in optimization is going to control their memory allocations, then control data access being linear so the prefetcher works well, then control memory alignment, then worry about SIMD and multi-threading.
When people talk about optimizing in java, it's usually about turning off the garbage collection, fighting with the garbage collection etc. Memory allocation is trivial in C++ because so much ends up on the stack and preallocating memory is trivial. Java optimization gets stuck on step 1, trying to control memory allocations and pointer chasing.
Show me a program in java and I will show you how it can run faster in C++ (and possibly even faster in ISPC).
Most C++ code I have seen does not even approach this level of care and customization.
When we are talking about speed, most people mean basic out-of-the-box speed of the code without heroic efforts. C++ and Java are a wash at this point performance wise. Most analytics code I have seen on Wall Street was either Java or C++, with the choice driven by what the quants wanted in their resume, not performance.
All the other stuff in this thread amounts to toy problems, from a software engineering complexity standpoint. Yes, you can write a fairly good CFD kernel in C, C++, or fortran. There are no lifetime or boundary issues in these use cases. The safety of the language in such cases is of no interest.
It is usually dead simple. Reserve memory in a vector, put data in, loop through it linearly. Modern C++ is very simple most of the time. Where are you getting this idea?
It is virtually impossible to write a realistically complex zero-copy RPC server in C++ because the lifetime issues are too daunting.
This is not only untrue, it doesn't even make sense. What is it that you think can be done in java and what are these lifetime issues you think are in the way? You didn't give any actual technical examples, so feel free to show something real and back up this claim.
Even Go can beat C++ in this use case, for the same reasons
Prove it, let's see where these ideas are coming from, because I don't think they are coming from experience with C++.
The safety of the language in such cases is of no interest.
This is also overblown in modern C++. It is easy to boil things down to value semantics and let simple lifetimes manage resources with scope. When it isn't something you can do with scope and you have to manage resources yourself, the language won't help you anyway since you are writing it yourself.
You've already proven that you don't know what I am talking about and now you are doubling down. There is no way to put data into a std::vector without copying it. Vector can't adopt memory that already exists. So your plan doesn't suit the use case I am discussing: zero-copy RPC servers.
You said "zero-copy RPC servers" (for some reason) but never gave any evidence of what you are saying or explained it technically in any way.
I'll ask again, show me what is being done in java that can't be done in C++. Show me technically, prove what you are saying.
I know how these conversations usually go. It's mostly the other person trying anything they can to not give evidence of what they're saying.
True, but all of this isn't neccesary to be faster than java.
When we are talking about speed, most people mean basic out-of-the-box speed of the code without heroic efforts.
Fair enough in general. All it takes in C++ is allocating memory out of hot loops and looping through memory linearly. This basically eliminates memory allocation as a bottleneck and pointer chasing as a bottleneck. These two things alone can make a program 100x faster or more.
In C++ makes this is often the simplest possible way to do something, although unfortunately that doesn't mean programs are always done like this.