91–100 of 367 posts
> Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. Do I understand correctly that the Rosetta is basically a transpiler from x86-64 machine code to ARM machine code which is run prior to the binary execution? If so, does it affect the application startup times?
Earlier quoted context omitted.
> I hope Rosetta is here to stay and continues developement. It almost certainly is not. Odds are Apple will eventually remove Rosetta II, as they did Rosetta back in the days, once they consider the need for that bridge to be over (Rosetta was added in 2006 in 10.4, and removed in 2011 from 10.7). > And I hope what is learned from it can be used to make a RISC-V version of it. translating native ARM to RISC-V should…
Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Rosetta 2 is all in house as far as we know. Different CEO as well. Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.
Earlier quoted context omitted.
> I hope Rosetta is here to stay and continues developement. It almost certainly is not. Odds are Apple will eventually remove Rosetta II, as they did Rosetta back in the days, once they consider the need for that bridge to be over (Rosetta was added in 2006 in 10.4, and removed in 2011 from 10.7). > And I hope what is learned from it can be used to make a RISC-V version of it. translating native ARM to RISC-V should…
> That's not going to happen unless Apple decides to switch from ARM to RISC-V, and... why would they? They've got 15 years experience and essentially full control on ARM. 15? More than a quarter century. They were one of the original investors in ARM and have produced plenty of arm devices since then beyond the newton and the ipod. I’d bet they use a bunch of risc v internally too if they just need a little cpu to m…
They didn't design their own chips for most of that time.
Earlier quoted context omitted.
> I hope Rosetta is here to stay and continues developement. It almost certainly is not. Odds are Apple will eventually remove Rosetta II, as they did Rosetta back in the days, once they consider the need for that bridge to be over (Rosetta was added in 2006 in 10.4, and removed in 2011 from 10.7). > And I hope what is learned from it can be used to make a RISC-V version of it. translating native ARM to RISC-V should…
> They've got 15 years experience and essentially full control on ARM. Do they? ARM made it very clear that they consider all ARM cores their own[1] [1]: https://www.theregister.com/2022/11/07/opinion_qualcomm_vs_a...
They do, yes. They were one of the founding 3 members of ARM itself, and the primary monetary contributor.
Through this they acquired privileges which remain extant: they can literally add custom instructions to the ISA (https://news.ycombinator.com/item?id=29798744), something there is no available license for.
> ARM made it very clear that they consider all ARM cores their own[1]
The Qualcomm situation is a breach of contract issue wrt Nuvia, it's a very different issue, and by an actor with very different privileges.
Rosetta 2 is great, except it apparently can't run statically-linked (non-PIC) binaries. I am unsure why this limitation exists, but it's pretty annoying because Virgil x86-64-binaries cannot run under Rosetta 2, which means I resort to running on the JVM on my M1...
It's unsupported in MacOS because it assumes binary compatibility on the kernel system call interface, which is not guaranteed.
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. The next-gen DR emulator (and SpeedDoubler etc) made things even faster. I suspect the ppc->x86 stuff was slower because x86 just doesn't have the registers. There's only so much you can do.
> 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,…
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.
I remember years ago when Java adjacent research was all the rage, HP had a problem that was “Rosetta lite” if you will. They had a need to run old binaries on new hardware that wasn’t exactly backward compatible. They made a transpiler that worked on binaries. It might have even been a JIT but that part of the memory is fuzzy. What made it interesting here was that as a sanity check they made an A->A mode where they…
If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)
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!
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 f…
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 remember years ago when Java adjacent research was all the rage, HP had a problem that was “Rosetta lite” if you will. They had a need to run old binaries on new hardware that wasn’t exactly backward compatible. They made a transpiler that worked on binaries. It might have even been a JIT but that part of the memory is fuzzy. What made it interesting here was that as a sanity check they made an A->A mode where they…
If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)
That said, a sufficiently advanced CPU could also make those optimisations on "static" code. That was one of the things Transmeta had been aiming towards, I think.