The sad thing is that a computer from the late '90s running software from the late '90s is extremely fast and snappy basically all the time. Old computers are just so much more responsive.

Honestly, what I want is for more developers to test and optimize their software for low-power machines. Say, a cheap netbook for example (like a Chromebook). I've heard that if you do that, you will be faster than basically every other piece of software on the system. And that speed will persist (multiply, even) on any more-powerful computer.

I've heard of one person who does that for their Quake-engine game/implementation (don't remember which). They get thousands of frames per second on a modern machine. I am guilty of not doing that myself, though. Might pick up a cheap netbook from eBay for around $30.

> 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.

Frankly I'm shocked that deduplicateTree is two orders of magnitude slower than deduplicateGreybeard, despite having asymptotically better-or-equal performance (TreeSet runtime is O(output log output), whereas sorting an array is O(input log input)). I'd say that perhaps boxing the integers is slowing the algorithm down, but deduplicateGreybeardCollections has only a <3x performance hit rather than >100x. Is the problem due to allocating large amounts of internal memory and branching heavily (binary trees as opposed to B-trees), or less predictable/vectorizable code execution than array traversal, or virtual comparison dispatch slower than `items.sort(Comparator.naturalOrder())`, or some TreeSet-specific slowdown?

Very good question. I'm away from my work station so I can't do additional profiling, but my overall experience is that TreeSet is hella slow in almost every case.

My hunch is that the extreme indirection makes mince out of data locality during traversal, since TreeSet is backed by a red black tree, so conversion to list is O(n) cache misses, whereas the sorting algorithms are reasonably well behaved from a cache perspective (Java uses a dual pivot quicksort for primitives and TimSort for objects IIRC).

Correction: Performing O(input) failed insertions into a TreeSet might be O(input log output) runtime, which is slower than what I stated above if input > output.

I looked at this source when you shared it and had planned to show it to a few engineers on my team. Now, sadly, the file is gone. Any chance you can put it back up?

  > Most development is done on high powered hardware that makes slow code very difficult to distinguish from fast code, even though you can often get 10x performance improvements without sacrificing readability or development effort.

true, but compilers are also doing a lot more, and one big driver of high-performance machines (at least for native dev) is compilation taking waaaay too much time...