Hacker News Reader

Comment by marshray | Hacker News Reader

This argument has been made since the introduction of the JVM in the early mid-90's.

Seems to me like if, in practice, JIT provided better performance then by now people would be rewriting their C/C++ code in Java and C# for speed.

View on HN

Most importantly people would write JITers for C and C++.

It might still be possible. The JVM and .NET both have their speed annihilated by their awful choice of memory model.

What's wrong with their memory model? Honest question.

In a nutshell: Too much pointer chasing. C# actually does much better than Java here, with its features for working with user defined value types, but it could still improve by a lot.

the jvm lacks structs and more specifically arrays of structs as a way to allocate memory. this causes extreme bloat due to object overhead as well as a ton of indirections when using large collections. the indirections destroy any semblance of locality you may have thought you had which is the absolute worst thing you can do from a performance perspective on modern processors. what people end up doing instead is making parallel arrays of primitives where there is an array for each field. this is also not ideal for locality but it's better than the alternative since there isn't a data dependency between the loads (they can all be done in parallel).

i am not that familiar with the C# runtime and i know C# has user definable value types, but i'm not sure what their limitations are.

There's a proposal to fix this by adding value types to the JVM. It's part of something called “Project Valhalla”.

http://jesperdj.com/2015/10/04/project-valhalla-value-types/

Garbage Collection is a very consequential design decision. To free that last unused object is going to take O(total writable address space) memory bandwidth.

In addition to what others have mentioned, there's also the inability to map structures on to an area of memory. The result is that you end up using streams and other methods to accomplish the same thing, and they result in a lot of function/method overhead for reading/writing simple values to/from memory.

What are some languages that have a better memory model and work faster with a JIT rather than an AOT compiler?

For that matter, does Java code execute faster or slower with an AOT compiler than with HotSpot? I did a quick Google search but couldn't find an answer, except for JEP 295 saying that AOT is sometimes slower and sometimes faster :(

> Seems to me like if, in practice, JIT provided better performance then by now people would be rewriting their C/C++ code in Java and C# for speed.

It's a little bit faster, not faster by enough to matter. If you're going to rewrite C/C++ code for speed you'd go to Fortran or assembler, and even then you're unlikely to get enough of a speedup to be worth a rewrite.

New projects do use Java or C# rather than C/C++ though.

> New projects do use Java or C# rather than C/C++ though.

Nobody is picking Java/C# over C/C++ for performance reasons.

It is not that Java or C# are able to beat C and C++ on micro-benchmarks, rather they are fast enough for most tasks that need to be implemented, while providing more productivity.

The few cases where raw performance down to the the byte level and ms matter are pretty niche.

I've seen a project pick Java over C/C++ because of the memory leaks they saw in the latter in practice. You can call that a correctness issue rather than a performance issue if you like, but the practical impact was the same as a performance problem.

"New projects do use Java or C# rather than C/C++ though."

But not for speed reasons. Java is in no way faster than well written C/C++

Java might not be, but C# is another matter.

Specially after the Midori and Singularity projects, and how it affected the design of C# 7.x low level features and UWP AOT compiler (shared with Visual C++).

Also Unity is porting engine code from C++ to C# thanks to their new native code compiler for their C# subset, HPC#.

The discussion was about JITs vs AoT compiled native code. Unity is not using a JIT runtime for their new Burst compiler but using LLVM to do AoT native compilation and getting rid of garbage collection. If you get rid of JIT and garbage collection then yes, a subset of C# can be competitive in performance with C++ for some uses.

JIT vs AOT is an implementation detail, nothing to do with a programming language as such, unless we are speaking about dynamic languages, traditionally very hard to AOT.

In fact C# always supported AOT compilation, just that Microsoft never bothered to actually optimize the generated code, as NGEN usage scenario is fast startup with dynamic linking for desktop applications.

While on Midori, Singularity, Windows 8.x Store, and now .NET Native, C# is always AOT compiled to native code, using static linking in some cases.

As for GC, C# always offered a few ways to avoid allocations, it is a matter for developers to actually learn to use the tools at their disposal.

With C# 7.x language features and the new Span related classes, it is even easier to avoid triggering the GC in high performance paths.

For someone who doesn't develop for the MS stack but is still curious, what are these ways to avoid allocations and GC in performance-critical paths?

X is not faster than well written Y, for all X and Y; that's not a particularly useful comparison though. I've seen a project pick Java over C/C++ because, based on their previous experience, the memory leaks typical of C/C++ codebases were a worse performance problem than any Java overhead.

Well written Java is sure to be slower than well written C/C++.

Happy? ;)

But yes, the point you make, is valid, it is much harder to write C/C++ well, because of the burden of memory management. So if you lack the time or skilled people, it might make sense to choose Java out of perfomance reasons.

Nah, nobody in their right mind would use Java/C# over C/C++ for performance...

http://blog.metaobject.com/2015/10/jitterdammerung.html?m=1

That’s a great blog post!

> I agree with Ousterhout's critics who say that the split into scripting languages and systems languages is arbitrary, Objective-C for example combines that approach into a single language, though one that is very much a hybrid itself. The "Objective" part is very similar to a scripting language, despite the fact that it is compiled ahead of time, in both performance and ease/speed of development, the C part does the heavy lifting of a systems language. Alas, Apple has worked continuously and fairly successfully at destroying both of these aspects and turning the language into a bad caricature of Java. However, although the split is arbitrary, the competing and diverging requirements are real, see Erlang's split into a functional language in the small and an object-oriented language in the large.

I still strongly think Apple is taking the wrong approach with Swift by not building on the ObjC hybrid model more.

Your article is correct that Java/C# performance is unpredictable. But, per the OP, C/C++ performance is also unpredictable, because C/C++ doesn't reflect what a modern processor actually does; there are cases where e.g. removing a field from a datastructure makes your performance multiple orders of magnitude worse because some cache lines now alias.

Reply on news.ycombinator.com