[Slartie]

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

[mikhailt]

That is true, I don't have any evidence to say that x86 isn't faster or equal against Apple's ARM CPUs or vis versa. They're hard to come by since they're both completely different arch.

For JS: https://twitter.com/codinghorror/status/1049082262854094848

It looks like it's not exclusive to Apple's CPU, it's the specific instruction features in ARM 8.3 ISA that makes JS faster.

Added here: https://bugs.webkit.org/show_bug.cgi?id=184023

> Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.

Right but back then, Intel mobile chips weren't that fast. I had MBP with Filevault that took a massive hit and I had to turn it off to get back disk performance. I can't prove that T2 is the reason the encryption doesn't take any hit on T2 Macs, all I can see from my trial of rMBP 16, there was zero performance hit with it on or off.

[Slartie]

Thanks for the JS link, I didn't know about that. Though I would hardly call that "Javascript acceleration in hardware". They added a slightly weird float-to-int conversion command that handles overflows a bit different than the normal command, and for lack of better names (and probably because no one else is expected to require that quirky command) they put a "Javascript" into its name.

The perf hit with Filevault became practically zero when Intel added the AES encryption hardware into its chips, which was quite a while ago (and definitely long before the T2 was a thing). I don't remember exactly when that was, but I remember noticing a considerable difference, because I've used FDE since it became available in Filevault. It wasn't even on Macs only, my Windows machines also showed the same improvements using (IIRC) TrueCrypt back in the days.

The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.

[sudosysgen]

>The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.

I don't really see how that would help, CPU i/o has to handle the exact same amount of incoming data encryption or not. Maybe a bit less RAM impact though.

[Slartie]

My thought was this: If the CPU decrypts, it touches every byte being read to RAM, and it touches the data again later when it does actual work on it. If it doesn't decrypt, but a chip next to the NAND does the job, the CPU can DMA-transfer the data directly from that chip to RAM. The first time the CPU touches the data is when it actually does some real work on it.

[sudosysgen]

True, but my thought was that since AES decryption is mostly limited by RAM bandwidth anyways, the transfer from the SSD to the CPU, then from the CPU to the T2 chip, then from the T2 chip to the CPU won't be much faster than transferring from the SSD into the RAM, then decryption, then it being read back into the RAM.

[Slartie]

AFAIK the T2 is also the SSD controller in Apple's architecture, meaning it speaks directly to the NAND. So it should not be necessary for data to first go to the CPU, then to the T2 for decryption - the T2 can transparently decrypt and encrypt while doing the job of offering block-device-level access to the flash chips.

[sudosysgen]

I mean, that might depend on the type of encryption used by your computer but there is a ton of documentation about full disk encryption in the Linux world and for over a decade there is almost no performance hit. My experience with a 2008 MBP running Debian was that disk encryption on or off had a very small performance hit.