The issue is that on x86, if you write memory addresses in a certain sequence, all other cores will see the writes in the same sequence. The ARM memory model is so radically different from x86 that you end up sprinkling memory barriers everywhere to guarantee cross threaded consistency, and that really hurts performance. Apple’s Rosetta 2 gets a lot of benefit from being a pre-compiling translator (for most cases - it still has to interpret JIT type workloads), but most people figured that would get you to 50% - at best. I’ve messed around with running x86 binaries in emulation on ARM before, and got about 10% of native performance on a Rpi4. We also have an answer now to the insane x86 translation performance (around 80% of native performance, give or take - and, yes, this does mean that the M1 runs x86 binaries faster than an awful lot of x86 hardware out there). All this performance is on about 30W, and this is their first pass at it. Yes, yes, I know, your overclocked AMD ThreadBlaster 7970XP, with enough threads, will build the kernel faster on 400W. For now, there are enough weird little broken corner cases that I’d suggest holding off unless you’re OK with that and want legitimately insane battery life and performance.īut an awful lot does work, and it works really well. Most of the software ecosystem quirks will be worked out by then, and just about everything will work.
Should you buy one of Apple’s M1 devices? Probably not - wait 6 months for the next round of hardware, and buy then. Lock your staging, or a thumb twitch might just leave you 100m above Mun with no descent (or ascent!) stage left attached… This does mean that, once again, Jeb ends up stuck places he’d probably rather not be stuck. I mean, it’ll even play Kerbal Space Program with pretty darn good graphics! That’s an x86 game with no native port yet, and it’s not exactly a CPU sipper! The fan almost never comes off idle, power consumption (I work in a solar office, remember?) is a rounding error, and it just does what I ask of it in a real hurry. I figured it would be really good, but it’s beyond good, crossing into the “Yeah, I’ll call this magical…” realm. Not just for the power - that’s amazing too, but simple, flat out, using it for stuff. It’s a common theme with ARM desktop use, especially 64-bit, so this is no different. The Intel one wasn’t doing most of what I wanted (to say the GPU sucked would be an understatement), I’ve been lusting after a mid-range ARM desktop for a long while, and the fact that things would be broken on it doesn’t bother me - it’s not a production machine for me, so I’m happy to run on the bleeding, slightly broken edge. While I don’t generally make a habit of buying brand new, just-released hardware, I made an exception for the M1 and bought a M1 Mac Mini to replace an Intel Mac Mini (which had replaced a perfectly function 2014 iMac I’d still be running if the monitor hadn’t failed - the display assembly, used, cost $600 in not-cracked condition). The fastest Linux machine I’ve ever used is a hardware virtualized install on the Apple M1 - and this post covers how to do it! I’ve also, as is usual for me, gone down some weird paths - like ARM Linux virtualization, x86 Linux emulation, and BOINC in an ARM VM! Apple did it, has shipped hardware, and I’ve had a chance to play with for a while now. About six months ago, I speculated a bit on what Apple might do with their upcoming (rumored at the time) ARM transition.
0 kommentar(er)
