5 ms·
TLDR: Based on a single simple synthetic benchmark, the low performance "Icestorm" cores were shown to be as much as 52%—or as little as 18%—of the performance
by simondotau 5y ago
TLDR: Based on a single simple synthetic benchmark, the low performance "Icestorm" cores were shown to be as much as 52%—or as little as 18%—of the performance of the primary "Firestorm" cores. Highly efficient assembly showed the least performance drop whereas complex "idiomatic" Swift code showed the greatest performance drop.
However the Icestorm cores also use substantially less energy so they are an efficiency win regardless. Plus they take up use significantly less physical space which is a large cost saving for the SOC part.
- Filligree 5y agoHow significantly less, I wonder? For my workloads it’d be an overall win to have more cores at that speed. The more the better; I’d cap out at maybe a a hundred or so. Obviously Firestorm is better, but a hundred-core desktop CPU at present seems… unlikely.
- maccard 5y agoAMD [0] would like a word. it's 64 cores but 128 with hyperthreading. [0] https://www.amd.com/en/products/cpu/amd-ryzen-threadripper-3990x https://www.amd.com/en/products/cpu/amd-ryzen-threadripper-3...
- Filligree 5y agoSo, not a hundred-core processor yet. I can’t use hyperthreading. It does give a 60% speed boost, but it’s also disabled in production so…
- em500 5y agoEyballing die shots, Firestorm is about 4 times the size of Icestorm, so if you have perfectly parallelizable workloads, you stand to gain if Firestorm is less than 4 times as fast per core. (This ignores L2 cache and maybe some other supporting transistors which makes things much more complicated.) In the simple benchmarks, the speed differences range roughly from 2x to 5x. It looks like the current configuration (4 Firestorm + 4 Icestorm) is pretty well balanced: equisized alternatives (5 Firestorm + 0 Icestorm, or 3 Firestorm + 8 Icestorm) can be faster for specific workloads, but probably not across the board. The Apple CPU team really knows what they're doing (but that has been abundantly clear for many years now).
- OskarS 5y ago> Highly efficient assembly showed the least performance drop whereas complex "idiomatic" Swift code showed the greatest performance drop. I wonder what this means. The efficient assembly probably has fewer instructions that use vector instruction and floating point calculations more, while the "idiomatic" Swift probably has just a larger number of instructions that aren't doing heavy calculation. Does that imply then that the high performance cores does much deeper pipelining, but the the number floating point units or whatever is probably pretty similar across both types?
- simondotau 5y agoMy initial guess is that it's because Icestorm CPUs have less L1 and L2 cache, resulting in more frequent cache misses in complex loops. I'm by no means an expert in any of this, so I really have no place hypothesising. Firestorm has 128KB L1 per core and 12MB shared L2. Icestorm has 64KB L1 per core and 4MB shared L2.
- OskarS 5y agoYeah, that makes a ton of sense. Cache misses would be less of a factor in the highly optimized assembly case.
- emn13 5y agoI've never written native code for an apple device, but have some low-level experience on other things; my guess would be that idiomatic swift contains safety checks, i.e. predictable branches, but branches nevertheless - and that simpler cores with poor or no branch prediction suffer much more heavily than "smarter" cores from that kind of code. At the end of the day, if all you're doing is basic adding/multiplying, you just don't need a fancy core (and hence: GPGPU, right?) So this microbenchmark result isn't very surprising, although it's nice to see the principles in action.
- saagarjha 5y agoThat is correct. Also, the checks have a bit of an unfortunate downside that they need to be emitted for each array access if the loop is unrolled (as it should be here).