> Old computers are just so much more responsive.

Because the software on them predates the explosion of GCs, JITs, and hundreds of layers of abstractions & dependencies. All those techniques that improve developer iteration & velocity came at the cost of runtime performance.

Yet the only reason those things exist and are allowed to exist is because we have been training users that snappiness is not to be expected. We have been training them to wait, because their computer is busy and has a lot of work to do. The only reason these things are socially acceptable is because nobody is doing anything about them, and the average user does not care.

Also, improving developer iteration and velocity is possible without doing this.

And on the mobile side you cjisyvthroe your hands in the air and claim network latency is the root cause of your performance problems. I spent some time with a team that did this, and what I saw, and tried but failed to fix, was that the problem is usually an abuse of ORMs and a complete and utter lack of software design.

GCs and JITs are absolutely not at blame here. You could in general write just as snappy programs with them than you could with assembly in the 90s. Hell, a hot loop in Java can be as fast as C code, and it has support for vector instructions as well if you want to write even faster (and platform-independent) code than you could with only C.

Bloat usually happens at the top 2 layers (actual program code and its dependencies), not from the runtime/OS/hardware.

JIT runtimes usually result in (very) slow first execution, and the post in question is specifically about app launch. Responsiveness is not isolated to only after the app has been chugging along for a while.

> Hell, a hot loop in Java can be as fast as C code

Only if the Java code in question is written like C code and not like Java code. Which is sometimes possible, yes, but very very rare, and almost never done.

> and it has support for vector instructions as well if you want to write even faster (and platform-independent) code than you could with only C.

Absolutely nonsense. C compilers are more than capable of cpu-specific vectorization, too. CPU detection at runtime is ancient technology and perfectly compatible with AOT languages. And since offline compilers have the benefit of getting to spend all the time in the world on it, regularly and consistently have much better auto vectorization outputs.

JITs are normally under such a time crunch that it's common for their initial output to be quite mediocre, hence why you end up with multi-level JITs. Which then take even longer before the code stops being slow. Great for benchmarks, but pretty shit in the real world for general app performance.

Now you can sometimes have your cake and eat it too here, such as what Google is doing with cloud profiles on Android to basically run the JIT ahead of time. But that is very far from the norm for JIT'd things.

I’m not talking about autovectorization, but explicit one. Autovectorization simply doesn’t work reliably enough no matter how much compiler time you spend on it, and leaves behind huge performance gains. With C, your best bet is compiler-specific intrinsics, or inline assembly, while java - strangely - has an explicit, cross-architecture Vector API, that can reliably compile down to the architecture’s SIMD instructions.

You mean the brand new Vector API? The thing that's only, oh, 25 years late? That's your example of JITs not being a bottleneck?

And it's not like the JIT actually provides any advantage here anyway. There's no shortage of similarly high level SIMD libraries for the AOT-world.

Many of the game studios near me (I live in Irvine, there's quite a few) test on older hardware as part of their QA process. I don't know what their limits are these days but I remember being impressed by Blizzard when I was visiting their campus once with a friend who worked there. It was fairly comprehensive at the time. According to him, anyway, many of the studios around here had similar practices.