I was the only person working on it for ~2 years, and I wrote the majority of the code in the first version that shipped. That said, I’m definitely glad that I eventually found someone else (and later a whole team) to work on it with me, and it wouldn’t have been as successful without that.
When people think of a binary translator, they usually just think of the ISA aspects, as opposed to the complicated interactions with the OS etc. that can consume just as much (or even more) engineering effort overall.
As someone frustrated in a team of 10+ that is struggling to ship even seemingly trivial things due to processes and overheads and inefficiencies, I would really appreciate some insights on how do you organize the work to allow a single developer to achieve this.
How do you communicate with the rest of the organization? What is the lifecycle and release process like? Do you write requirements and specs for others (like validation or integration) to base their work on? Basically, what does the day to day work look like?
Well, the first thing to realize about scaling codebases with developers is that an N developer team will usually produce a codebase that requires N developers to maintain. So by starting small and staying small until you reach a certain critical mass of fundamental decisions, you can avoid some of the problems that you get from having too many developers too early. You can easily also fall into the reverse trap: a historical core with pieces that fit too well together, but most of the developers on the team don’t intuitively understand the reasons behind all of the past decisions (because they weren’t there when they happened). This can lead to poorly affixed additions to a system in response to new features or requirements.
As far as Rosetta in particular was concerned, I think I was just in the right environment to consistently be in a flow state. I have had fleeting moments of depression upon the realization that I will probably never be this productive for an extended period of time ever again.
Thank you for what you did with Rosetta 2. It is outstanding.
On your last point, I’ve felt something like that myself and I hold onto hope that it isn’t true for myself (and now for you in your future endeavors). But even if it is true, you achieved something superhuman in your niche and the vast majority of people throughout the history of time have no idea what that is like. Tasting Heaven cannot last too long while on Earth. Maybe AI will bring us a little bit closer to that Heaven.
Thanks for sharing. Do you have an estimation of LoC? I know it's a BS indicator but just curious. I'd imagine it's something difficult but not too large.
>How do you communicate with the rest of the organization?
I wonder if Apple's renowned secrecy is a help with this. If nobody outside your small team knows what you are doing then it is hard for them to stick their oar in.
For the record I was interning on Cameron's team while he worked on Rosetta 2 and didn't even know myself what he worked on (the rest of the team and I were working on something else). I only found out later after it was released!
Apple is like this, I have seen plenty of instances where you have one person carrying a team of 5 or more on their back. I always wonder how they manage to compensate them when it’s clear they are getting 10x more done. Hopefully they get paid 10x, but something tells me that isn’t true.
When I was consulting I saw that everywhere. A team of ten people would have one or two primary contributors and often one person who had a negative impact on productivity.
That's super impressive. I remember being astonished that the x86 executable of Python running through Rosetta 2 on my M1 was just a factor of 2 slower than the native version.
QEMU was something like a factor of 5-10x slower than native, IIRC.
QEMU loses a bit from being a generic translator instead of being specialized for x86->ARM like Rosetta 2, Box64 or FEXEmu. It does a lot of spilling for example even though x86 has a lot fewer registers than aarch64.
Flags are also tricky, though they're pretty well optimized. In the end the main issue with them is also the spilling, but QEMU's generic architecture makes it expensive to handle consecutive jump instructions for example.
> It's a huge achievement for a single person to have written most of that.
Qemu was mostly Fabrice Bellard by himself at the beginning and plenty of emulators are single person project.
It’s a field which lends itself well to single person development. How to properly architecture compiler/interpreter/emulator has been studied to death and everyone mostly uses the same core principles so there is little guess work as how to start (provided you have taken the time to study the field). If you are ready to do the work, you can reach a working translator from hard work alone. Then, the interesting work of optimising it starts.
Don’t get me wrong, Rosetta 2 is a very impressive achievement because the performances are really good. I tip my metaphorical hat to whoever did it. My post is more in the spirit of you can do something in the same ballpark too if that’s your kick.
That is fascinating that this amazing system was the work of largely one person. You mentioned that interacting with the OS was super difficult. What were the most enjoyable aspects of building Rosetta?
I am also amazed that this was the work of largely one person. Having seamless and performant Rosetta 2 was a major factor why the Apple transition from Intel to Apple Silicon was viable in the first place!
It's a shame that Apple's stated intent is to throw the project away after a while. Personally, I really hope it sticks around forever, though I'm not optimistic.
Rosetta 2 can't go away until Apple is ready to also retire Game Porting Toolkit. At most, they might drop support for running regular x86 macOS applications while keeping it around for Linux VMs and Windows applications, but that would be pretty weird.
In principle, the Linux Rosetta binaries should remain usable well into the future. Even if Apple discontinues support for Rosetta in their VMs, there's very little (beyond a simple, easily removed runtime check) preventing them from being used standalone.
AFAIK Linux Rosetta does not work standalone but uses some channels to exchange x86 and arm binary code between Linux guest and macOS host. Actual translation happens in the macOS.
I don't understand why Apple even bothers these days, I wouldn't be surprised if Apple's gaming market is a quarter of what the Linux gaming market currently is (thanks to Valve and their work on proton and by extension wine)...
Because people want to use their fancy new hardware to play games? Linux market share wouldnt be increasing so fast if Valve didn’t do the work so why shouldn’t Apple do the same?
They don't really block games though. It's more like they don't want to maintain the roads the games need to run on.
Transitioning to ARM wasn't possible if they had to support 2 x86 ABI's and an extra ARM 32 bits ABI. Throw in another migration and you have an untestable number of legacy combinations.
I think it is different this time. A lot of developers use Rosetta 2 for Linux to run x86-64 Linux Docker containers under macOS (including me). They'll be upset if Apple discontinues Rosetta 2 for Linux. By contrast, once the PPC-to-Intel transition was under way, Rosetta was only used for running old software, and as time went by that software became increasingly outdated and use of it declined. While I think Rosetta 2 for macOS usage will likely decline over time too, I think Rosetta 2 for Linux usage is going to be much more stable and Apple will likely maintain it for a lot longer. Maybe if we eventually see a gradual migration of data centres from x86-64 to ARM, Rosetta 2 for Linux usage might begin to also decline, and then Apple may actually kill it. But, if such a migration happens, it is going to take a decade or more for us to get there.
I just pointed out what happened in the past. I have no clue if Apple will deprecate it and what reason they put forward doing so. I personally like the fact that I can run both arm and x86 binaries. But I think judging Apple that if they don’t have a personal reason to support Linux (they also use it for their services) they will remove it. But deprecated dons’t mean it will be removed anytime soon. Apple keeps APIs and frameworks as long as they don’t interfere with something else.
What's the advantage of running x86-64 Linux Docker containers over running ARM Linux Docker containers? Aren't most distributionss and packages available for both platforms?
Microsoft SQL Server is only available as an x86-64 docker container binary. They actually had a native(?) arm64 docker container under the name "azure-sql-edge", which was (and still is) super useful as you can run it "natively" in an arm64 qemu linux for example, but alas that version was not long lived, as Microsoft decided to stop developing it again, which feels like a huge step backwards.
There's probably other closed-source linux software being distributed as amd64-only binaries (rosetta 2 for linux VMs isn't limited to docker containers).
Lots and lots of Docker images are only linux/amd64 compatible. Without Rosetta 2 I wouldn't be able to do my job, especially in a team with a mix of Mac and Linux workstations and most images being build as amd64/linux only.
Some images are only available for amd64 still. Like oracle databases. Even if there is an arm64 of a recent version of the app, it may not exist for older versions that you want to test against.
When people think of a binary translator, they usually just think of the ISA aspects, as opposed to the complicated interactions with the OS etc. that can consume just as much (or even more) engineering effort overall.