In a previous job, we had a cross compiler that cross/decompiled a static x86 Linux binary to Java bytecode (with syscalls emulated in Java). Testing this on an ARM processor the Java version of a scientific benchmark we were using was significantly faster (1.6X) than the best gcc could do with the original C. This wasn't anything fancy our cross-compiler had done, but the JVM itself. This isn't a comparison to x86 hardware, just an indication of the effort put into the ARM based JVM.

ARM has been so dominant in the mobile market that there has been a lot of effort around ARM optimisations, both in compilers and interpreted languages. Way more so than alternative architectures like MIPS etc.

Java doesn't have that many x86 specific optimisations actually. It does some auto-vectorisation, it supports things like AES-NI and other specialised hw instructions, but, those are easy to port to ARM.

The vast bulk of the effort in modern JVM compiler optimisations is more at the program structural level: removing allocations, merging methods together so they can be optimised as a whole, removing abstraction, and so on. All that stuff is CPU independent.

It's not very "new". People have been working on porting, improving and optimizing software for the Arm server ecosystem for more than a decade now; really performant and widely available hardware may be new on the scene, but it would be silly to wait for that before starting work on the software side of things...

x86's age and complexity give it a significant disadvantage. Both the cache coherency model and the instruction set incur a lot of overhead to do at speed.

That's very interesting. Could you elaborate?

A lot of the most commonly run software out there doesn't use the large, complex instructions offered on x86, so a bunch of pristine silicon goes to waste. Use the space taken by AVX512 etc to make more, simpler cores, and you get more performance for the same price, or less cost for the same performance. Simpler cores are easier to clock higher with less voltage, and less likely to have defects that would pull down yields.

The big vector units aren't the problem though. They're a consequence of the big complicated schedulers that most x86 cores are designed with. As long as the core has to be huge anyway, you might as well spend some space on more powerful math units.

It's possible to design an x86 chip with much more priority on throughput per square centimeter, with many more simple cores working together, but I have no idea how it would work out.

There's a lot of logic and complexity on decoding, fusing, etc.

FWIW, 32 bit x86 (i386) and ARM arrived in the same year (1985.)