5 ms·

Is the switch to ARM going to be for cost savings, or are the chips actually faster than current Intel?

by nodesocket 7y ago

phoobahr 7y ago
https://news.ycombinator.com/item?id=21033371 https://news.ycombinator.com/item?id=21033371
- sudosysgen 7y ago
  That's Geekbench. The differences in Geekbench for ARM devices and Geekbench for x86 are laughable. Why not compare them in a real life workload like a render on Blender or a kernel compile?
  - mattkevan 7y ago
    I’d love to read your results rendering something in Blender on the latest A13 chip, if that’s the best way to make a comparison.
    - sudosysgen 7y ago
      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.
  - uglycoyote 7y ago
    How is running the same code in two different machines and reporting the results objectively "laughable"?
    - sudosysgen 7y ago
      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.
  - mikhailt 7y ago
    People have (Jonathan Morrison for an example) , 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. Intel CPUs are not customized by Apple for their own APIs, they're for general purpose use. yes, they have ISA extensions that Apple could use like QuickSync but it's not enough for Apple. Apple customize their A series with the same APIs they use, such as Metal, CoreFoundation, Javascript Core (they have hardware-based JS acceleration support), etc. 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 and so on.
    - Slartie 7y ago
      > 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 7y ago
        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 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 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.

Is the switch to ARM going to be for cost savings, or are the chips actually faster than current Intel?

phoobahr 7y ago

https://news.ycombinator.com/item?id=21033371 https://news.ycombinator.com/item?id=21033371

sudosysgen 7y ago
That's Geekbench. The differences in Geekbench for ARM devices and Geekbench for x86 are laughable. Why not compare them in a real life workload like a render on Blender or a kernel compile?
- mattkevan 7y ago
  I’d love to read your results rendering something in Blender on the latest A13 chip, if that’s the best way to make a comparison.
  - sudosysgen 7y ago
    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.
- uglycoyote 7y ago
  How is running the same code in two different machines and reporting the results objectively "laughable"?
  - sudosysgen 7y ago
    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.
- mikhailt 7y ago
  People have (Jonathan Morrison for an example) , 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. Intel CPUs are not customized by Apple for their own APIs, they're for general purpose use. yes, they have ISA extensions that Apple could use like QuickSync but it's not enough for Apple. Apple customize their A series with the same APIs they use, such as Metal, CoreFoundation, Javascript Core (they have hardware-based JS acceleration support), etc. 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 and so on.
  - Slartie 7y ago
    > 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 7y ago
      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 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 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.