> Apple's historically been pretty good at making this stuff. Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the fastest 68k mac you could buy.

Not arguing the facts here, but I'm curious—are these successes related? And if so, how has Apple done that?

I would imagine that very few of the engineers who programmed Apple's 68k emulator are still working at Apple today. So, why is Apple still so good at this? Strong internal documentation? Conducive management practices? Or were they just lucky both times?

I mean they are one of very few companies who have done arch changes like this and they had already done it twice before Rosetta 2. The same engineers might not have been used for all 3 but I'm sure there was at least a tiny bit of overlap between 68k->PPC and PPC->Intel (and likewise overlap between PPC->Intel and Intel->ARM) that coupled with passed down knowledge within the company gives them a leg up. They know the pitfalls, they've see issues/advantages of using certain approaches.

I think of it in same way that I've migrated from old->new versions of frameworks/languages in the past with breaking changes and each time I've done it I've gotten better at knowing what to expect, what to look for, places where it makes sense to "just get it working" or "upgrade the code to the new paradigm". The first time or two I did it was as a junior working under senior developers so I wasn't as involved but what did trickle down to me and/or my part in the refactor/upgrade taught me things. Later times when I was in charge (or on my own) I was able to draw on those past experiences.

Obviously my work is nowhere near as complicated as arch changes but if you squint and turn your head to the side I think you can see the similarities.

> Or were they just lucky to have success both times?

I think 2 times might be explained with "luck" but being successful 3 times points to a strong trend IMHO, especially since Rosetta 2 seems to have done even better than Rosetta 1 for the last transition.

FWIW, I know several current engineers at Apple who wrote ground-breaking stuff before the Mac even existed. Apple certainly doesn't have any problem with older engineers, and it turns out that transferring that expertise to new chips on demand isn't particularly hard for them.

> Apple certainly doesn't have any problem with older engineers

Just to be clear, I never meant to suggest that they did—I just didn't realize employees remained with the company for that long, instead of switching.

I suspect that there's a design document somewhere that has secrets and tips. Plus MacOS and NeXTstep have been ported so many times that by now any arch-level things are well-isolated. A lot of the pain of MacOS on x86 were related to kernel extensions and driver API changes. And a lot of stuff fell out during the 64-bit transition.

In general, MacOS/iOS/iPadOS owe everything to the excellent architecture laid down by the NeXT team back in the day. NeXTstep now has the dream that MS tried and failed to do back in the day: an OS that runs on every kind of device they make. Funny how that is.

> I suspect the ppc->x86 stuff was slower because x86 just doesn't have the registers.

My understanding is that part of the reason the G4/5 was sort of able to keep up with x86 at the time was due to the heavy use of SIMD in some apps. And I doubt that Rosetta would have been able to translate that stuff into SSE (or whatever the x86 version of SIMD was at the time) on the fly.

Apple had a library of SIMD subroutines (IIRC Accelerate.framework) and Rosetta was able to use the x86 implementation when translating PPC applications that called it.

Rosetta actually did support Altivec. It didn't support G5 input at all though (but likely because that was considered pretty niche, as Apple only released a G5 iMac, a PowerMac, and an XServe, due to the out-of-control power and thermals of the PowerPC 970).

> Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the fastest 68k mac you could buy.

This is not true. A 6100/60 running 68K code was about the speed of my unaccelerated Mac LCII 68030/16. Even when using SpeedDoubler, you only got speeds up to my LCII with a 68030/40Mhz accelerator.

Even the highest end 8100/80 was slower than a high end 68k Quadra.

The only time 68K code ran faster is when it made heavy use of the Mac APIS that were native.

>The only time 68K code ran faster is when it made heavy use of the Mac APIS that were native.

Yes, and that just confirms the original point. Mac apps often spend a lot of time in the OS apis and therefore the 68K code (the app) often ran faster on PPC than it did on 68K because apps often spend much of their time in OS apis. The earlier post said "so good that for some things the PPC Mac was the fastest 68k mac." That is true.

In my own experience, I found most 68K apps felt as fast or faster. Your app mix might have been different, but many folks found the PPC faster.

Part of that was the greater clock speeds on the 601 and 603, though. Those started at 60MHz. Clock for clock 68K apps were generally poorer on PowerPC until PPC clock speeds made them competitive, and then the dynamic recompiling emulator knocked it out of the park.

Similarly, Rosetta was clock-for-clock worse than Power Macs at running Power Mac applications. The last generation G5s would routinely surpass Mac Pros of similar or even slightly greater clocks. On native apps, though, it was no contest, and by the next generation the sheer processor oomph put the problem completely away.

Rosetta 2 is notable in that it is so far Apple's only processor transition where the new architecture was unambiguously faster than the old one on the old one's own turf.

The first gen 68K emulator performed worse on the PPC 603 than the 601.

That's not true for the 6100 but for the 8100 it was totally true. And at some point my 8500 ran 68k faster than any 68040 ever made, which isn't really fair since the 8500 was rocking good.