Hacker News Reader

Comment by jwsta | Hacker News Reader

I'm a little surprised by the contortions companies go into to make languages faster.

What happened to writing C/C++ in the first place if speed matters? Would you write Stockfish in Java or Python and hope for a sophisticated, bug free VM?

View on HN

Java is actually incredibly well written for large scale multicore systems.

Java's garbage collector, although the source of many performance headaches, is in fact very sophisticated and "does the right thing" for most OOP-style code. Yes, it takes some understanding and tuning (and yes, there are multiple garbage collectors you're supposed to test out as you tune your software...) but that's the sort of thing that's available.

In C/C++ world: you can't just swap out versions of "malloc" or "new" as easily (ie: without recompiling everything, to tune / test your code on different systems). Restarting your JVM with slightly different garbage collector settings over-and-over again is absolutely a thing in the Java world to help tune your applications to the machines they run on.

---------

Java's high performance concurrency libraries are very well written as well. And there are some real speed demons (Azul) out there.

Its really a different world and model than the C/C++ world.

There are actually plenty of runtime tuning parameters for malloc and friends (using environment variables), and you can swap out allocators using LD_PRELOAD without recompiling anything.

You can do the same in C - for example:

    LD_PRELOAD=libjemalloc.so  MALLOC_CONF=narenas:1 /your/unmodified/app

Because it's difficult to write large amounts of reliable code with c++.

Yes, it's easier with modern c++, but it's still significantly harder than with, say, rust or ada (or java for that matter, which is not slow, contrary to popular belief).

Furthermore, in the Facebook case, it's about cost : you save money by being faster, but you don't want to lose money because you're tracking overflow bugs in c++. If you can have both execution speed and development/maintenance speed , it's much better.

And to be fair, it's not like FB use Java for (much) performance critical code (AFAIK, obviously).

I'd be willing to bet that lots of the core ranking/ads stuff at most of the major tech companies is written in C++.

Just checked and Spark has over a million lines of Scala code, as well as 100k+ loc of Java and Python. Which would you prefer, rewriting a million lines of Scala, or having a small team work on improving compiler/runtime efficiency?

Spark is also heavily dependent on a bajillion other OSS libraries, many of which don't directly translate to C++ libs -- Apache, Guava, etc. It's probably at least 10x this line count if you include all the utilities they pull in.

Let alone lines of code would be even more when it's written in C++.

A lot more. Scala, the Akka ecosystem, and the Hadoop ecosystem is uniquely suited to Spark's problem domain.

And Scala is, for both better and worse, an extremely compact language too. I would expect about 5x more lines of code just from that.

One interesting thing here is that there are people who know some real numbers, and not just hypotheticals, but they probably can't talk about it publicly. Google has their own distributed compute engine, written in C++. Everyone I know who's worked with it says it's much nicer than Spark, and much more performant.

I wouldn't necessarily just assume that it's 5x more code. I've spent a fair bit of time digging around in the Spark code, and it's not clear to me that it's as efficiently designed or cleanly implemented as one might like. And, while I can't speak to the influence of Google's style guide, I don't personally feel like modern C++ is 5x as verbose as modern Scala. A bit more, maybe? But it's not like Scala (2, at least) doesn't have its own bizarre sources of unnecessary verbosity. It mostly looks great by comparison to Java.

Java can actually compete with C/C++ if written in a specific, limited way. Some high-frequency trading shops use Java, and their entire business is speed.

The problem is, Java written in that specific limited way is way less expressive, less safe and less productive than modern C++, not even mentioning Rust.

Since it fails to achieve 70% of the memory corruption issues that modern C++ is capable of, definitely less safe.

As much as we would like the modern C++ from books and conference talks to exist in real life, that is not how the large majority of the world actually writes C++.

Heck, just check the AOSP source code to see how much modern C++ it has, from one of the companies that contributes to ISO C++.

Or if that fails to impress, see how much modern C++ exists in Microsoft Github sample projects.

Memory corruption / safety issues related to memory are not only typical C problems like use after free but also type errors. Optimizing Java for performance means using only primitive types which is significantly less type-safe than C++ classes / structs.

C++ isn't Coq, so don't get what type safety you are selling.

Naturally it is possible to write static classes that hide the internals of a data structure, and ensure they are properly used.

And if that isn't enough, Valhalla is eventually here, Java 17 already includes the preview for new native memory primitives, and polyglot developers can always write a bunch of native methods, no need to throw safety and productivity away for 100% of the code.

C++ is not Coq, but it is still a lot closer to Coq than C-like Java written for performance.

> Naturally it is possible to write static classes that hide the internals of a data structure

Which limits you to reusing a single instance which is not only very limited in what you can do with, but also inherently error-prone compared to passing structs.

Valhalla does not exist yet, had been in development for a decade, and even once they release it, it won't be equivalent to C++ structs - it is by design much more limited.

Finally, productivity of Java is overrated, I've been writing in many languages and I'm not more productive in Java than in C++. Productivity is mostly a trait of a developer and libraries, not a language.

No it doesn't limit it, because that single instance class can also do JNI and manual memory management without exposing it on the public interface.

I know C++ since 1993, have delivered C++ into production at CERN and Nokia Networks, and also taught it at the university to first year students.

So what do I know a bit about C++ productivity versus other languages.

Now if we start talking about GPGPU programming, HPC or writing device drivers then it is another matter, there is where C++ shines and will keep doing so for the foreseeable future.

CERN is definitely not going to rewrite HLT in Java, in fact for some units not even C++ was good enough, and the code is actually implemented in FPGAs.

Because they want a higher level of abstraction for 'all the other benefits' - and then just to get it work a little faster.

When we think C++ performance, we're thinking of something like a video or audio compression i.e. discrete functionality. Note a massive, enterprise level solution with myriads of kinds of business functions.

It would never get complete in C++ as that language has complexity issues which overwhelm everything else at some scale, more often than not.

Even then, many devs focus too much on the performance tree and miss the forest of polyglot programming.

If there are performance issues with a Java application, where after all attempts, there is still some room left, there is no need to throw everything way.

Those areas can be ported to C, C++, Rust, whatever, and then called via native methods.

Java designed for performance, when the VM settles down after n iterations pushes 'on par' with C++.

There's also no reason to believe that C or C++ will be faster, because you have to 1) know how to write performant C++ code (not obvious) and 2) content with the Java-JNI-C barrier which is non-negligible.

I don't see too many scenarios where taking a module and porting to C++ is really ever a thing frankly.

Usually, it'd be for integrating already existing systems - or - for integrating things which might naturally be written in C/C++ in the first place.

For something like Graal, it's one of those broad improvements wherein everyone gains, hopefully magically without having to do anything like a big improvement in V8 that just 'happens'.

Since 2006 I already replaced a couple of C++ platforms with either Java or .NET, then there is Android as well, or embedded platforms like microEJ.

On managed languages FFI should never be done 1:1, as you very well point out it isn't negligible.

Rather they should be thought as in-process RPC, that actually do a bunch of work per call.

It is still faster than doing IPC across processes.

Question is, would you prefer to re-write Spark in C or use GraalVM to get a boost in speed? It's not feasible to re-write everything from scratch.

Rust rewrites are already in progress.

When you make a better compiler/runtime, that work on one program benefits many programs. So it is often more cost-effective to improve the compiler/runtime than to improve all the user programs. Developing higher-level languages creates a similar situation: many programmers can be more productive.

70% of memory corruption issues causing huge increase in development costs happened.

Right now their only use for green field projects is on ecosystems where there are no alternatives.

Java's used in HFT, so that's enough

Yeah, why won't you use one if the most complicated, error prone and complex languages instead of Java.

Just curious, is there any kind of standardized JMX and remote debug in C/C++ world (on Linux)?

That was the question I was asking too. Guess CS grads now a days know Java best. and therefore they have to have java. optimization comes next. Leading to all these tech challenges.

Writing safe C++ is harder than plain simple Java.

Reply on news.ycombinator.com