All of these tasks are "accelerated" by skimping on quality or using silicon dedicated to a specific program. It doesn't matter in real life unless literally the only thing you do is use a browser and nothing else, and even then only JS, not wasm. In which case, I don't know why you would even have a CPU with more than two cores, and an i3 would be more than enough anyways. JS acceleration really only matters if you want to maximize battery life and the only thing you're doing with your computer is contained in a traditional webview. That is to say, it matters little for laptops, as they already have 7-8 hour battery life, and literally not at all for desktops.

So, for example, my computer can encode 4 4K videos in real time simultaneously. Why don't I use this feature? Because the encode quality is subpar. So unless you give me a benchmark of the iPad Pro on ffmpeg or any other open source, non-hardware accelerated video encode software, comparison is completely moot. And the benchmarks that have been done on ffmpeg on x265 or x264 show that the iPad Pro is multiple times slower than an Intel laptop. Now obviously x265 is optimized for x86, but not on the order of multiple times slower. Unless it is the case, and that means that your benchmarks don't apply either.

Herein lies the issue, for many many workloads hardware acceleration while faster offers results that are not comparable to the CPU in terms of quality. So the only way to compare is by disabling hardware acceleration, and x86 processors tend to win.

Metal is a trash API that no one uses in the real world. It offers literally nothing better than Vulkan. And the fact that the chip is "customized for the API" is vacuous. All GPUs are optimized for OpenGL, DirectX or Vulkan. Same for a lot of the "Core" APIs. They will not succeed outside of the mobile market.

The T2 chip is simply a glorified security processor. There is absolutely nothing the T2 chip does that a traditional security processor in say a Zen chip can't do. x86 CPUs can already do AES at speeds so high you would need something like 4 RAID-0 NVMe SSDs to have a performance bottleneck, and even then the limitation isn't the CPU but RAM speed. There is no real world scenario where you would need to "accelerate" disk encryption or other kinds of cryptography beyond what an x86 CPU can do. Cryptography isn't some kind of magic you can't implement without some specialized chip, literally everything the T2 chip does can be done using a trusty old x86 processor and TPM. The only use of the T2 chip is for Apple to have more control over your hardware, and literally nothing else.

> the 4k exports from iMovie or other video/image editor has been proven to be vastly faster on iPad Pro than the fastest Macbook Pro.

I'd only be impressed if both used the exact same high-quality software encoder. Most likely the iPad uses the fast but less quality dedicated hardware encoder of the A-Series SoC and the MacBook uses a high quality but slow software-only one, which is what you typically use in any non-real-time encoding scenario due to way better bitrate-to-quality ratios.

> Javascript Core (they have hardware-based JS acceleration support)

Do you have a credible source for this? AFAIK JS VMs have gotten to the same place that Java VMs (for which some people also envisioned dedicated silicon a long time ago, but it was a dud) reached: so frickin fast on standard x86 ISA that putting any special instructions for them into the ISA isn't worth it, because it's more important to stay flexible to be able to adapt future extensions of ECMAScript.

> It's why they added T2 chips to their Macs to help accelerate a lot of tasks like disk encryption, more locked down security with TouchID

That has more to do with having a secure element under Apple's control in the T2 chip and nothing with performance. Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.

I'd love to make such a benchmark, but I won't because I don't have enough money to justify buying a Mac. If you send me one I'll port the rendering engine over and do the benchmark, though.

Because the way the code is compiled or hand optimized even, which kind of extensions are used for ARM vs x86 (SSE, AVX and so on). Many of the worloads used in Geekbench are straight up directly accelerated, which is fine if the only thing that's requiring CPU power on your machine is Javascript, but not so otherwise.

Other synthetic benchmarks of memory bandwidth and so on use all acceleration features of the plafortm on ARM but don't support AVX2 or AVX512, although some other workloads in the benchmark do. And of course you would have to choose exactly which instruction is used in which scenario in which processor(Intel vs Zen 1 vs Zen 2) in order to have the same kind of optimization as for ARM processors. Then comes the issue that vector operations are "hand-tuned", which is not realistic and depending on the skill of the programmer and their affinity with a given uArch can yield vastly different results. Which is why they should either use the fastest library for each processor, or leave all the optimization to the compiler.

The only way to do a proper comparison between two uArch is with an open source benchmark compiled specifically for the processor.