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