Hacker News Reader

Comment by dynjo | Hacker News Reader

It is quite astonishing how seamless Apple has managed to make the Intel to ARM transition, there are some seriously smart minds behind Rosetta. I honestly don't think I had a single software issue during the transition!

View on HN

If that blows your mind, you should see how Microsoft did the emulation of the PowerPC based Xeon chip to X86 so you can play Xbox 360 games on Xbox One.

There's an old pdf from Microsoft researchers with the details but I can't seem to find it right now.

They also bought a boat load of PPC Macs for much of the early Xbox dev work.

Any good videos on that?

I finally started seriously using a M1 work laptop yesterday, and I'm impressed. More than twice as fast on a compute-intensive job as my personal 2015 MBP, with a binary compiled for x86 and with hand-coded SIMD instructions.

Are you me lol? I'm on my third day on M1 Pro. Battery life is nuts. I can be on video calls and still do dev work without worrying about charging. And the thing runs cool!

It helps that there were almost 2 years between the release and your adoption. I had a very early M1 and it was not too bad, but there were issues. I knew that going in.

I had an M1 Air early on and I didn't run into any issues. Even the issues with apps like Homebrew were resolved within 3-4 months of the M1 debut. It's amazing just how seamless such a major architectural transition it was and continues to be!

They've almost made it too good. I have to run software that ships an x86 version of CPython, and it just deeply offends me on a personal level, even though I can't actually detect any slowdown (probably because lol python in the first place)

It has been extremely smooth sailing. I moved my own mac over to it about a year ago, swapping a beefed up MPB for a budget friendly M1 Air (which has massively smashed it out the park performance wise, far better than I was expecting). Didn't have a single issue.

My work mac was upgraded to a MBP M1 Pro and again, very smooth. I had one minor issue with a docker container not being happy (it was an x86 instance) but one minor tweak to the docker compose file and I was done.

It does still amaze me how good these new machines are. Its almost enough to redeem apple for the total pile of overheating, underperforming crap that came directly before the transition (aka any mac with a touchbar).

There's an annoying dwarf fortress bug but other than that, same

It isn't their first rodeo: 68k->PPC->x86_64->ARM.

nitpick, they did PPC -> x86 (32), the x86_64 bit transition was later (no translation layer though). They actually had 64-bit PPC systems on the G5 when they switched to Intel 32-bit, but Rosetta only does 32-bit PPC -> 32-bit x86; it would have been rare to have released 64-bit PPC only software.

They had 64 bit Carbon translation layer, but spiked it to force Adobe and some other large publishers to go native Intel. There was a furious uproar at the time, but it turned out to be the right decision.

But they've been on x84_64 for a long time. How much of that knowledge is still around? Probably some traces of it have been institutionalized but it isn't the same as if they just grabbed the same team and made them do it again a year after the least transition.

Rosetta 1 and the PPC -> x86 move wasn't anywhere near as smooth, I recall countless problems with that switch. Rosetta 2 is a totally different experience, and so much better in every way.

You gotta think there's been a lot of churn and lost knowledge at the company between PPC->x86_64 (2006) and now though.

I think the end of support for 32-bit applications in 2019 helped, slightly, with the run-up.

Assuming you weren’t already shipping 64-bit applications…which would be weird…updating the application probably required getting everything into a contemporary version of Xcode, cleaning out the cruft, and getting it compiling nice and cleanly. After that, the ARM transition was kind of a “it just works” scenario.

Now, I’m sure Adobe and other high-performance application developers had to do some architecture-specific tweaks, but, gotta think Apple clued them in ahead of time as to what was coming.

I have a single counter-example. Mailplane, a Gmail SSB. It's Intel including its JS engine, making the Gmail UI too sluggish to use.

I've fallen back to using Fluid, an ancient and also Intel-specific SSB, but its web content runs in a separate WebKit ARM process so it's plenty fast.

I've emailed the Mailplane author but they wont release an Universal version of the app since they've EOL'd Mailplane.

I have yet to find a Gmail SSB that I'm happy with under ARM. Fluid is a barely workable solution.

For what it's worth, I use Mailplane on an M1 MacBook Air (8GB) with 2 Gmail tabs and a calendar tab without noticeable issues.

Unfortunately the developers weren't able to get Google to work with them on a policy change that impacted the app [0] [1] and so gave up and have moved on to a new and completely different customer support service.

[0] https://developers.googleblog.com/2020/08/guidance-for-our-e... [1] https://mailplaneapp.com/blog/entry/mailplane_stopped_sellin...

So unfortunately

I wonder what's different about my setup. I've tried deleting and re-installing Mailplane and tried it on two different M1s (my personal MBA and my work 16" MBP). On both, there is significant lag in the UI. Just using the j/k keys to move up/down the message list it takes like 500 ms for the selected row to change.

I use non-default Gmail UI settings. I'm still using the classic theme, dense settings, etc. I'll try again, because I'd really like to use Mailplane as long as it will survive.

I'm aware why Mailplane has been EOL'd. But the developer also claims he's trying to keep it alive as long as possible and he's released at least one version since that blog post, so I'd hoped he would be willing to release a universal build. I don't know anything about the internals of Mailplane but I guess it's a non-trivial amount of work to do so.

Since this is the company's third big arch transition, cross-compilation and compatibility is probably considered a core competency for Apple to maintain internally.

And Next was multi-platform as well.

having total control on the hardware and the software didn't hurt for sure

Qualcomm (and Broadcomm) has total control on the hardware and software side of a lot of stuff and their stuff is shit.

It's not about control, it's about good engineering.

So many parts across the stack need to work well for this to go well. Early support for popular software is a good example. This goes from partnerships all the way down to hardware designers.

I'd argue it's not about engineering more than it is about good organizational structure.

And having execs who design the organizational structure around those goals is part of what makes good engineering :)

It's about both control and engineering in Apple's case.

That's really not the case, if you're in Microsoft or Linux's position you can't really change the OS architecture or driver models for any particular vendor.

That generality and general knowledge separation between different stacks leaves quite a lot of efficiency on the table.

Reply on news.ycombinator.com