[naikrovek]

> If it does that optimally

ah, the "sufficiently smart compiler" argument. There is no such compiler, FYI, and there may not ever be. Not for every situation that developers are creating in Java today.

it's a matter of hitting your CPU cache as often as possible. Neither javac nor the runtime has any freaking clue how to do that, but you, as a developer, do. When you write Java, you can't do a lot to control how that JVM arranges data or how it fetches it from RAM, partially because of OOP, partially because of autoboxing/unboxing, so you wind up missing the cache a lot more unless you create a bunch of primitive types and use those, and that that point, why are you writing Java?

I'm not saying Java is bad. I'm saying that it is not the fastest language you can use. You seem to be arguing that it is, or that it could be. It cannot.

> average performance for a large codebase will be much better than something like C/C++ given the same amount of effort.

absolutely not. Maybe if you're fully skilled in Java and new to C or C++, but if you are equally skilled in both, you would never choose Java for performance alone.

[kaba0]

There is an interesting presentation titled death of optimizing compilers, where it is claimed that programs increasingly are either in their hot path where performance is absolutely crucial and not even C/C++ is sufficiently low-level (you can achieve 2-3 orders of magnitude faster code by hand-optimized assembly), or on cold paths where even Bash would suffice.

Nonetheless, I found that it is easy to find these hot spots and they are trivial to “fix” in java for optimal performance, by simply using a primitive array. At every other place, Java is more than fast enough even with the occasional “jumping around”.

Also, haven’t seen a study on that but would be interested in Java’s defragmentation skills (due to moving GC). Malloc implementations can fragments a lot, and cold path code jumps around a lot. Wouldn’t be surprised if Java would fair quite well here.

[naikrovek]

I would love to see a video game implemented in Bash with the hottest spots implemented in Assembly, just to see how poorly that would perform.

I work for a company that has AWS Lambdas which are invoked 10s of trillions of times per year, with about 45% of that happening in a single month, and another 45% happening 6 months later, also within a single month.

I cannot imagine what our AWS bill would be like if those lambdas ran Bash. 100x larger? At least.

Performance matters. It's not obvious how much it matters until you look, but it matters. There are zero users who will complain that an application makes them wait less than it did previously. There are zero managers who will complain that their AWS bill gets lower because code takes less time to run and uses less RAM.

I have no idea why anyone would even begin to argue the opposite.

[kaba0]

I didn’t write that I agreed with said presentation, but it was interesting, and a good take away is that if you have such a scorching hot loop that iterates over megabytes of data, a compiler may not be sufficient even in low-level languages. (Think of video codecs). And the other side, routine optimizations done on cold paths may not be as worthy (the bash line was me exaggerating the effect - but just think of any Python deployment, they are basically that, slow code calling into optimized libs in C and Fortran)

[al_mandi]

I'm curious about the cost of hosting if you're using plain ol' VMs instead of lambdas (EC2, etc.). What are those functions written in? Unless you're going to say C/C++/Rust or a similar language, I'm not sure there will be any significant variance.