Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the Rosetta Translation Environment

developer.apple.com

Post reply on HN
Print view View original

71–80 of 249 posts

Re: About the Rosetta Translation Environment

#71

Post by rz2k »

Does anyone have any insight into the business logistics involved in a transition like this?

I presume Apple has done maintenance on transitioning desktop OS X to ARM as an option for a very long time. How many years ago would they have had to decide that was the direction they were going to make it reality? 2015? How many people would have been working on it? How many billions of dollars? How does the cost of developing the software compare to the cost of developing a new processor, or compared to tooling a production line for an entirely new platform?

I'm really curious about the share of institutional resources and attention this likely involved. I wonder how important it is as context to Apple over the past few years.

I also wonder if it heralds a new direction in personal computers. Every time I've considered that my Mac isn't that great, the alternatives aren't that great either. Would Apple ever decide to seriously compete for a dominant share of the personal computer market?

And finally, I am also curious about the accounting and financial disclosures required in such decisions. How much are institutional investors informed of long range plans? There's naturally a lot more pressure to distribute cash to shareholders if you don't know about some five-year-plan, yet that pressure waxes and wanes from activist investors, and institutional investors like CalPERS always seemed to be on board with Apple's direction anyway. Do unofficial leaks prevent violations of insider trading rules?

Re: About the Rosetta Translation Environment

#72

Post by cpuguy83 »

lsllc wrote: post #55
cpuguy83 wrote: post #19

Earlier quoted context omitted.

Apple mentioned they are specifically "working with Docker to support 'these things' in coming months". Confirmed with some Docker folks they are working on "something". All very nondescript, but they said they can't talk about it yet.

Possibly they'll do something like WSL/WSL2 to provide an ARM based Linux kernel interface and then use Rosetta2 to translate the x64 code in user space to ARM? Having ARM only containers would be mostly useless (it's technically possible, but I bet there are very few ARM container images around).

All the base images are multi arch, which I suspect covers the majority of uses in dev envs.

Re: About the Rosetta Translation Environment

#73

Post by rezmason »

DCKing wrote: post #40

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualization framework. This way e.g. Parallels and Docker could use this to provide some way to tap in probably the fastest way to run x86 on ARM Macs. This would mean Rosetta would go beyond its stated scope, and certainly go beyond what the relatively short-lived Rose…

I think the longer Rosetta exists and macOS thereby supports a wider variety of binary executables, the more people will rely on it to deliver them day-to-day functionality in increasingly complex configurations, and the more Apple will expose itself to those users' criticisms.

If Apple's rationale for the transition is to gain further control over their product design and manufacture, the prospect of having to appease folks who won't give up their old software (like me!) but who come to expect indefinite Rosetta-type backwards compatibility doesn't sound all that appealing from Apple's perspective. We're talking about a company who denied Carbon support in the 64-bit transition while some of their largest software developers still clung to it.

Furthermore, the old software they're temporarily supporting through Rosetta represents the agreements and policies Apple followed with third party developers during earlier periods in their history, which I'm sure they want to get away from. In their eyes, the sooner they can ditch those policies and impose iOS-type restrictions on any and all macOS software development, the better.

This is probably my last Mac, after thirty years. It's been fun, watching them rise in power, but they've had to become a very different kind of company to get to where they are.

Re: About the Rosetta Translation Environment

#74

Post by jojobas »

mkl wrote: post #41

> Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. How on Earth does it do that? If executable code is being generated at runtime, it's going to be x86_64 binary machine code still (there are too many ways to generate valid machine code, and it won't know right away whether you're JITting, or cross compiling and actually want x86_64), so Rosetta would need to dete…

My gut feeling is that it will be about the same as Itanium/HP Envy x2 emulation. Emulation of highly optimized hardware where code is generated by highly optimized compilers without an order of magnitude slowdown is just too good to be true.

Re: About the Rosetta Translation Environment

#75

Post by mrpippy »

jayyhu wrote: post #17

>Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. No AVX will probably mean that the vast majority of pro/graphics intensive apps won't work out of the box with Rosetta.

The “cheese grater” 2010/2012 Mac Pro didn’t support AVX either, but supported 10.14. Apps have only been able to depend on Macs having AVX for a year, but of course they should still check at runtime.

Re: About the Rosetta Translation Environment

#76

Post by nielsole »

jedieaston wrote: post #12
marcinzm wrote: post #4

>However, Rosetta doesn’t translate the following executables: Virtual Machine apps that virtualize x86_64 computer platforms How will this impact docker? Does this mean you can't run x86 docker containers on new Apple laptops?

Docker on ARM will work, Docker for x86 will not. The State of the Union showed a demo of Hypervisor.framework with Parallels, and they made it clear that Debian AArch64 was running (uname -a). Since Docker runs inside a VM on the Mac, it'll have to be an ARM VM with ARM containers. (Presumably, running docker build with your Dockerfile will make it work just fine, unless you need x86 specific libraries).

Could you run the linux docker machine on aarch64 and just the docker container/process on JIT-x86? The majority of syscalls doesn't care about architecture, do they? And the OS should theoretically be agnostic to the machine code the application is written in. Probably requires some cooperation on part of the linux docker host. Did I get the idea across?

You would go to hell for implementing that either way

Re: About the Rosetta Translation Environment

#77

Post by proninyaroslav »

haxxorfreak wrote: post #51
godzillabrennus wrote: post #38

The Apple transition to ARM for me is sad. There was so much positivity around the Intel transition. It opened up the Mac platform. Now it’s going back into a closed black box.

I'm optimistic and while the constant references to ARM as "Apple Silicon" make it sounds proprietary I see it as an example of Apple following Jobs' goal of "skating to where the puck will be". Microsoft is toying with the same transition with Windows 10 ARM builds and the Surface Pro X, and the news yesterday about an ARM-based supercomputer taking the TOP500 crown are all signs that ARM is the future. It will take…

Can you install something other than Windows 10 on Surface Pro X? I think not. There may be hackers who can crack these things, but this is not an ideal solution. There will also be problems with the drivers, I'm sure of that. Mac is waiting for the same fate.

Re: About the Rosetta Translation Environment

#78

Post by Someone »

DCKing wrote: post #40

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualization framework. This way e.g. Parallels and Docker could use this to provide some way to tap in probably the fastest way to run x86 on ARM Macs. This would mean Rosetta would go beyond its stated scope, and certainly go beyond what the relatively short-lived Rose…

AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance.

So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)

Re: About the Rosetta Translation Environment

#79

Post by dannyw »

lsllc wrote: post #55
cpuguy83 wrote: post #19

Earlier quoted context omitted.

Apple mentioned they are specifically "working with Docker to support 'these things' in coming months". Confirmed with some Docker folks they are working on "something". All very nondescript, but they said they can't talk about it yet.

Possibly they'll do something like WSL/WSL2 to provide an ARM based Linux kernel interface and then use Rosetta2 to translate the x64 code in user space to ARM? Having ARM only containers would be mostly useless (it's technically possible, but I bet there are very few ARM container images around).

There are heaps and heaps of ARM containers around thanks to the Raspberry Pi.

I've never had a problem running Docker on my Pi, and I don't expect anyone will have a problem running Docker on a Mac given Apple's much much larger developer market share.

Re: About the Rosetta Translation Environment

#80

Post by jeffbee »

underdeserver wrote: post #58
jeffbee wrote: post #43

Earlier quoted context omitted.

But doesn't this mean that they are translating and running the JIT and the JIT is creating new executable x86 code which then also needs to be translated? I'm a bit baffled as to how any of this can work properly, for example if my JIT is sampling instructions to determine when to optimize, does Rosetta need to reverse-translate the actual instruction pointer back to the original x86 code offset?

> But doesn't this mean that they are translating and running the JIT and the JIT is creating new executable x86 code which then also needs to be translated? Yup. > I'm a bit baffled as to how any of this can work properly, for example if my JIT is sampling instructions to determine when to optimize, does Rosetta need to reverse-translate the actual instruction pointer back to the original x86 code offset? Well, not…

The hard part seems to be metadata, or information about the program rather than the program itself. Rosetta will translate the program but it doesn't know about the metadata, so you have a referential integrity problem, seemingly. For example what is going to happen if a program running under Rosetta uses setitimer to deliver SIGPROF? What's in si_addr?
Post reply on HN