Comment by croemer
1 year ago
We're you really _the_ creator of Rosetta 2? How big was the team, what was your role in it?
Rosetta 2 is amazing, I'm genuinely surprised this is the work of just one person!
1 year ago
We're you really _the_ creator of Rosetta 2? How big was the team, what was your role in it?
Rosetta 2 is amazing, I'm genuinely surprised this is the work of just one person!
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.
2 replies →
>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.
4 replies →
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 probably had to account for differences in memory models. A fork with that stuff removed might be able to easily catch up.
4 replies →
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.
9 replies →
Where did Apple state that Rosetta 2 was to be deprecated?
12 replies →
It is my experience that it is easier to create good quality things as an individual than as a team. Especially for the core of a product. Also look at Asahi.
However, to really finish/polish a product you need a larger group of people. To get the UI just right, to get the documentation right, to advocate the product, to support it.
It is easily possible to have 10 people working on the team and only having a single core person. Then find someone to act as product manager while as the core person you can focus on the core of the product while still setting the direction without having to chase all the other work.
It is possible, but not easy to set up in most organisations. You need a lot of individual credit/authority and/or the business case needs to be very evident.