5 ms·
Not all geekbench scores are created equal. Comparing ARM and x86 scores is an exercise in futility as there are simply too many factors to work through. It als
by hajile 6y ago
Not all geekbench scores are created equal. Comparing ARM and x86 scores is an exercise in futility as there are simply too many factors to work through. It also doesn't include all workload types.
For example, I can say with 100% confidence that M1 has nowhere near 32MB of onboard cache. Once it starts hitting cache limits, it's performance will drop off a cliff as fast cores that can't be fed are just slow cores. It's also worth noting that around 30% of the AMD power budget is just Infinity Fabric (hypertransport 4.0). When things get wide and you have to manage that much wider complexity, the resulting control circuitry has a big effect on power consumption too.
All that said, I do wonder how much of a part the ISA plays here.
- 013a 6y agoM1 has 16MB of L2 cache; 12MB dedicated to the HP cores and 4MB dedicated to the LP cores. Another important consideration is the on-SOC DRAM. This is really incomparable to anything else on the market, x86 or ARM, so its hard to say how this will impact performance, but it may help alleviate the need for a larger cache. I think its pretty clear that Apple has something special here when we're quibbling about the cache and power draw per core differences of a 10 watt chip versus a 100 watt one; its missing the bigger picture that Apple did this at 10 watts. They're so far beyond their own class, and the next two above it, that we're frantically trying to explain it as anything except alien technology by drawing comparisons to chips which require power supplies the size of sixteen iPhones. Even if they were just short of mobile i9 performance (they're not), this would still be a massive feat of engineering worthy of an upgrade.
- john_alan 6y agoReally interesting analysis. So you expect the M1 MBP will outpace the more expensive Intel 13 MBP they are selling for more money!! How would that not destroy sales of their “higher end” intel MBP 13? If so do you think it will be better across most workload types?
- julienb_sea 6y agoI don't see why they would care that they are destroying sales of the intel MBP 13. Let consumers buy what they want - the M1 chip is likely far higher profit margins than the intel variant, and encouraging consumers to the Apple chip model is definitely a profit driver. Some people especially developers may be skeptical of leaving x86 at this stage. I think the smart ones would just delay a laptop purchase until ARM is proven with docker and other developer workflows. Another consideration - companies buying Apple machines will likely stay on Intel for a longer time, as supporting both Intel and ARM from an enterprise IT perspective just sounds like a PITA.
- theptip 6y agoDocker runs in a VM on MacOS anyway, it’s not running on bare metal. Is instruction-set even relevant in that world?
- eulers_secret 6y agoThank you for posting this! I was so confused when folks were saying 16GB of ram was too little. I run Linux on all my machines, and even running many (5-10) containers, 16GB was plenty. I now understand a bit better.
- barrkel 6y agoMy Linux laptop locks up every now and then with swapping when I'm running our app in k3s; three database servers (2 mysql, 1 clickhouse), 4 JVMs, node, rails, IntelliJ, Chrome, Firefox and Slack, and you're starting to hit the buffers. I was contemplating adding more ram; 64 GB looks appealing. I would not buy a new machine today for work with less than 32 GB.
- asdfaoeu 6y agoThat uses hardware virtualization which is very much dependent on the architecture. Running an x86 docker image on a M1 would take a significant performance penalty.
- hajile 6y agoAMD's Smart Memory Access was recently announced. In unoptimized games, they're projecting a 5% performance boost between their stock overclock and SMA (rumors put the overclock at only around 1%). The bigger issue here is bandwidth. AMD hasn't increased their APU graphics much because the slow DDR4 128-bit bus isn't sufficient (let alone when the CPU and GPU are both needing to use that bandwidth). I also didn't mention PCIe lanes. They are notoriously power hungry and that higher TDP chip not only has way more, but also has PCIe 4 lanes which have twice the bandwidth and a big increase in power consumption (why they stuck with PCIe 3 on mobile). It's also notable that even equal cache sizes are not created equal. Lowering the latency requires more sophisticated designs which also use more power. https://www.amd.com/en/technologies/smart-access-memory https://www.amd.com/en/technologies/smart-access-memory
- tinus_hn 6y agoI’m pretty sure the amount of cache on the chip was on one of the slides, according to Wikipedia it’s 192 kb for instructions and 128 kb for data. To me it seems pretty unlikely to be that important because if you can have 16gb of memory in the chip, how hard can it be to increase the caches a fraction of that?
- skept 6y agoThat's 16GB of DRAM. Caches are SRAM, which has a very different set of design tradeoffs. SRAM cells use more transistors so they can't be packed as tightly as DRAM.
- tinus_hn 6y ago16gb is 500 times as much as 32mb. Cache memory is not 500 times as large as normal memory. If 32mb would be too hard they could have easily went for 1mb. But they didn’t and that’s a pretty good indicator it doesn’t make a lot of difference.
- hajile 6y agoA normal SRAM cell takes 6 transistors. 6 * 8 * 1024 * 1024 * <total_mb> is a big number. Next, SRAM doesn't scale like normal transistors. TSMC N7 cells are 0.027 nanometers while MY cells are 0.021 (1.35x). meanwhile, normal transistors got a 1.85x shrink. I-cache is also different across architectures. x86 uses 15-20% less instruction memory for the same program (on average). This means for the same size cache that x86 can store more code and have a higher hit rate. The next issue is latency. Larger cache sizes mean larger latencies. AMD and Intel have both used 64kb L1 and then move back to 32kb because of latencies. The fact that x86 chips get such good performance with a fraction of the L1 cache points more to since kind of inefficiency in Apples design. I'd guess AMD/Intel have much better prefetcher designs.
- tinus_hn 6y ago> 6 * 8 * 1024 * 1024 * <total_mb> is a big number. No, when your chip has many billions of transistors that’s not a big number. For 1 mb that’s about 0.2%, a tiny number, also when multiplied with 1.85. Next the argument is that x64 chips are better because they have less cache while before the Apple chips couldn’t compete because Intel had more. That doesn’t make sense. And how are you drawing conclusions on the design and performance of a chip that’s not even on the market yet anyway?
- saagarjha 6y ago> Not all geekbench scores are created equal. Comparing ARM and x86 scores is an exercise in futility as there are simply too many factors to work through. It also doesn't include all workload types. The meme of saying that Geekbench is not a useful metric across cores, or that it is not representative of real-world usage, and therefore cannot be used needs to die. It’s not perfect, it can never be perfect. But it’s not like it will be randomly off by a factor of two. I’ve been running extremely compute-bound workloads on both Intel and Apple’s chips for quite a while and these chips are 100% what Geekbench says about them. Yes, they are just that good.
- jzbiciak 6y agoIn the case of Infinity Fabric: high speed I/O links generally consume gobs of power just to wiggle the pins, long before any control plane gets involved. In this case, it's high speed differential signaling, and that's going to have a /lot/ of active power. There's a lot of C*dv/dt going on there!