I understand proton isn’t the same thing, it was just an example of a compatibility layer…and how would a bidirectional compatibility layer not be beneficial? X86 in servers may be going away and even that’s debatable, but x86 isn’t going anywhere in the consumer space. Graviton chips are great, but they’re useless if there’s no viable way to translate those x86 legacy applications over to ARM without breaking the bank until your business is ready to transition the workload to ARM.
Amazon was working on a compatibility layer specifically for this purpose, however I suspect they’ve given up because they’ve slowly added Intel and AMD chipsets back into their general purpose ec2 class for newer generations and there hasn’t been a single word about compatibility with graviton other than just use arm based workloads.
You just can’t move to ARM because it’s cheaper, that’s just not going to work. You need to make the effort to move away from x86 and adopt applications that are arm native before making that jump. With a compatibility layer it doesn’t matter, that’s where the money is, if I can build a compatibility layer that translates an x86 binary to an arm binary, then I can move those workloads to the cheaper and more efficient server class.
It’s a different problem under the same name. You’re comparing apples to oranges by comparing WINE and Rosetta.
WINE (as I understand it) explicitly does its best to maintain the instructions and basically just implements functions that are missing.
Rosetta actually changes out every instruction (and presumably has to do a WINE-like thing as well to handle dynamically linked code, though in theory this is more of a 1-to-1 mapping since you’re not swapping OSes).
if there’s no viable way to translate those x86 legacy applications over to ARM
For a properly written application that doesn’t have a lot of third party binary dependents… This really shouldn’t be that big of a job. You just recompile the code on ARM, test, and fix any bugs.
I’d speculate that most of the time this stuff comes up like: “this was written for Windows with some very specific Microsoft libraries/tech in mind and we want to run it on Linux and ARM as cost cutting measures.”
Granted, it’s not unusual for a large enough code base to contain some code that wasn’t written in an architecture neutral way/does some shady stuff.
I’m not comparing Rosetta and proton…I’m just using them as examples of compatibility layers that make their products viable. I frankly don’t give a shit about the inner workings of Rosetta or proton, but thanks for clarifying I guess.
I understand proton isn’t the same thing, it was just an example of a compatibility layer…and how would a bidirectional compatibility layer not be beneficial? X86 in servers may be going away and even that’s debatable, but x86 isn’t going anywhere in the consumer space. Graviton chips are great, but they’re useless if there’s no viable way to translate those x86 legacy applications over to ARM without breaking the bank until your business is ready to transition the workload to ARM.
Amazon was working on a compatibility layer specifically for this purpose, however I suspect they’ve given up because they’ve slowly added Intel and AMD chipsets back into their general purpose ec2 class for newer generations and there hasn’t been a single word about compatibility with graviton other than just use arm based workloads.
You just can’t move to ARM because it’s cheaper, that’s just not going to work. You need to make the effort to move away from x86 and adopt applications that are arm native before making that jump. With a compatibility layer it doesn’t matter, that’s where the money is, if I can build a compatibility layer that translates an x86 binary to an arm binary, then I can move those workloads to the cheaper and more efficient server class.
It’s a different problem under the same name. You’re comparing apples to oranges by comparing WINE and Rosetta.
WINE (as I understand it) explicitly does its best to maintain the instructions and basically just implements functions that are missing.
Rosetta actually changes out every instruction (and presumably has to do a WINE-like thing as well to handle dynamically linked code, though in theory this is more of a 1-to-1 mapping since you’re not swapping OSes).
For a properly written application that doesn’t have a lot of third party binary dependents… This really shouldn’t be that big of a job. You just recompile the code on ARM, test, and fix any bugs.
I’d speculate that most of the time this stuff comes up like: “this was written for Windows with some very specific Microsoft libraries/tech in mind and we want to run it on Linux and ARM as cost cutting measures.”
Granted, it’s not unusual for a large enough code base to contain some code that wasn’t written in an architecture neutral way/does some shady stuff.
I’m not comparing Rosetta and proton…I’m just using them as examples of compatibility layers that make their products viable. I frankly don’t give a shit about the inner workings of Rosetta or proton, but thanks for clarifying I guess.