6 ms·

Does anyone know the names of the key people behind Rosetta 2? In my experience, exceptionally well executed tech like this tends to have 1-2 very talented peo

by darzu 4y ago

Does anyone know the names of the key people behind Rosetta 2? In my experience, exceptionally well executed tech like this tends to have 1-2 very talented people leading. I'd like to follow their blog or Twitter.

trollied 4y ago
The original Rosetta was written by Transitive, which was formed by spinning a Manchester University research group out. See https://www.software.ac.uk/blog/2016-09-30-heroes-software-engineering-men-and-women-transitive https://www.software.ac.uk/blog/2016-09-30-heroes-software-e... I know a few of their devs went to ARM, some to Apple & a few to IBM (who bought Transitive). I do know a few of their ex staff (and their twitter handles), but I don’t feel comfortable linking them here.
- scrlk 4y ago
  IIRC the current VP of Core OS at Apple is ex-Manchester/Transitive.
cwzwarich 4y ago
I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).
- dougall 4y ago
  Amazing work! It's nice to put a name to it :)
- darzu 4y ago
  Should you feel inspired to share your learnings, insights, or future ideas about the computing spaces you know, me and I'm sure many other people would be interested to listen! My preferred way to learn about a new (to me) area of tech is to hear the insights of the people who have provably advanced that field. There's a lot of noise to signal in tech blogs.
- darzu 4y ago
  If you're feeling inclined, here's a slew of questions: What was the most surprising thing you learned while working on Rosetta 2? Is there anything (that you can share) that you would do differently? Can your recommend any great starting places for someone interested in instruction translation? Looking forward, did your work on Rosetta give you ideas for unfilled needs in the virtualization/emulation/translation space? What's the biggest inefficiency you see today in the tech stacks you interact most with? A lot of hard decisions must have been made while building Rosetta 2; can you shed light on some of those and how you navigated them?
- bdash 4y ago
  Impressive work, Cameron! Hope you're doing well.
- pcf 4y ago
  Thanks for your amazing work! May I ask – would it be possible to implement support for 32-bit VST and AU plugins? This would be a major bonus, because it could e.g. enable producers like me to open up our music projects from earlier times, and still have the old plugins work.
  - deleted 4y ago
    [deleted]
- skrrtww 4y ago
  Are you able to speak at all to the known performance struggles with x87 translation? Curious to know if we're likely to see any updates or improvements there into the future.
  - olliej 4y ago
    There are two ways to approach x87: either saying to heck with it and just using doubles for everything (this is essentially what Qemu does) or creating a software fp80 implementation. Both approaches get burned by the giant amount of state, and state weirdness, that x87 brings to the table. It's also not possible to "fix" things by optimizing for the cases where the x87 unit's precision is set to the same as fp32 or fp64, as the precision flags don't impact the exponent range. But even on native hardware using x87 is vastly slower than fp64, and it's just a shame that only win64 had the good sense to define long double as being fp64 instead of fp80 as every other x86_64 platform did :-/
    - phire 4y ago
      > It's also not possible to "fix" things by optimizing for the cases where the x87 unit's precision is set to the same as fp32 or fp64, as the precision flags don't impact the exponent range. I've been meaning to look into this. Certainly you can't blindly optimise all x87 code sequences to fp32 or fp64. But some sequences are safe. For example, adding two numbers and saving back to memory is safe to optimise (at least for the infinity case, I haven't double-checked the subnormal behaviour). It's only when you need to add three or more numbers that you run into issues (though you can go further, if all N numbers have the same sign, you will get the correct result, you just might have saturated at infinity a few operations earlier than native x87) Same goes for multiplication of two numbers (and N numbers that all provably >= 1.0) The question is if such code sequences are common enough to bother trying to identify at compile time and optimise.
      - olliej 4y ago
        > For example, adding two numbers and saving back to memory is safe to optimise (at least for the infinity case, I haven't double-checked the subnormal behaviour). It's only when you need to add three or more numbers that you run into issues (though you can go further, if all N numbers have the same sign, you will get the correct result, you just might have saturated at infinity a few operations earlier than native x87) No, you cannot. Operations you can optimise are negation, nan, and infinity checks (ignoring pseudo nans and pseudo infinity checks of course). fp80 has a 15bit exponent, and functionally a 63 significand, vs fp64's 11bit exponent and 52bit significand. When setting x87 to a reduced precision mode you aren't switching to fp64, you're getting a mix with a 15 bit exponent and a 53 significand. The effect is that you retain 53bits of precision for values where fp64 has entered subnormals, and conversely you maintain 53 bits of precision after fp64 has overflowed. There are perf benefits to reducing precision in x87 (at least in the 90s), but the main advantage is consistent rounding with fp64 while in the range of normalized fp64 values.
- Klonoar 4y ago
  Huh, this is timely. Incredibly random but: do you know if there was anything that changed as of Ventura to where trying to mmap below the 2/4GB boundary would no longer work in Rosetta 2? I've an app where it's worked right up to Monterey yet inexplicably just bombs in Ventura.
  - anyfoo 4y ago
    Not affiliated and don't know, but curious why you're doing that in the first place?
    - Klonoar 4y ago
      's not my doing, it's just an older project that's slowly migrating to a newer system but is held back by everyone having lives. I wouldn't do it normally, heh.
  - saagarjha 4y ago
    Pretty sure mmap goes almost directly to the kernel in Rosetta 2, and Apple silicon requires at least 4 GB.
    - Klonoar 4y ago
      This works fine in Big Sur and Monterey on Apple Silicon, hence my point about if something changed in Ventura. Edit: Big Sur -> Ventura.
  - mrpippy 4y ago
    This should work (Wine obviously needs it when running 32-bit apps). Are you explicitly specifying a small PAGEZERO when compiling?
    - Klonoar 4y ago
      Yup!
- keepquestioning 4y ago
  Isn't Rosetta 2 "done"? What are you working on now?

by darzu 4y ago

trollied 4y ago

The original Rosetta was written by Transitive, which was formed by spinning a Manchester University research group out. See https://www.software.ac.uk/blog/2016-09-30-heroes-software-engineering-men-and-women-transitive https://www.software.ac.uk/blog/2016-09-30-heroes-software-e... I know a few of their devs went to ARM, some to Apple & a few to IBM (who bought Transitive). I do know a few of their ex staff (and their twitter handles), but I don’t feel comfortable linking them here.

scrlk 4y ago
IIRC the current VP of Core OS at Apple is ex-Manchester/Transitive.

cwzwarich 4y ago

I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).

dougall 4y ago
Amazing work! It's nice to put a name to it :)
darzu 4y ago
Should you feel inspired to share your learnings, insights, or future ideas about the computing spaces you know, me and I'm sure many other people would be interested to listen! My preferred way to learn about a new (to me) area of tech is to hear the insights of the people who have provably advanced that field. There's a lot of noise to signal in tech blogs.
darzu 4y ago
If you're feeling inclined, here's a slew of questions: What was the most surprising thing you learned while working on Rosetta 2? Is there anything (that you can share) that you would do differently? Can your recommend any great starting places for someone interested in instruction translation? Looking forward, did your work on Rosetta give you ideas for unfilled needs in the virtualization/emulation/translation space? What's the biggest inefficiency you see today in the tech stacks you interact most with? A lot of hard decisions must have been made while building Rosetta 2; can you shed light on some of those and how you navigated them?
bdash 4y ago
Impressive work, Cameron! Hope you're doing well.
pcf 4y ago
Thanks for your amazing work! May I ask – would it be possible to implement support for 32-bit VST and AU plugins? This would be a major bonus, because it could e.g. enable producers like me to open up our music projects from earlier times, and still have the old plugins work.
- deleted 4y ago
  [deleted]
skrrtww 4y ago
Are you able to speak at all to the known performance struggles with x87 translation? Curious to know if we're likely to see any updates or improvements there into the future.
- olliej 4y ago
  There are two ways to approach x87: either saying to heck with it and just using doubles for everything (this is essentially what Qemu does) or creating a software fp80 implementation. Both approaches get burned by the giant amount of state, and state weirdness, that x87 brings to the table. It's also not possible to "fix" things by optimizing for the cases where the x87 unit's precision is set to the same as fp32 or fp64, as the precision flags don't impact the exponent range. But even on native hardware using x87 is vastly slower than fp64, and it's just a shame that only win64 had the good sense to define long double as being fp64 instead of fp80 as every other x86_64 platform did :-/
  - phire 4y ago
    > It's also not possible to "fix" things by optimizing for the cases where the x87 unit's precision is set to the same as fp32 or fp64, as the precision flags don't impact the exponent range. I've been meaning to look into this. Certainly you can't blindly optimise all x87 code sequences to fp32 or fp64. But some sequences are safe. For example, adding two numbers and saving back to memory is safe to optimise (at least for the infinity case, I haven't double-checked the subnormal behaviour). It's only when you need to add three or more numbers that you run into issues (though you can go further, if all N numbers have the same sign, you will get the correct result, you just might have saturated at infinity a few operations earlier than native x87) Same goes for multiplication of two numbers (and N numbers that all provably >= 1.0) The question is if such code sequences are common enough to bother trying to identify at compile time and optimise.
    - olliej 4y ago
      > For example, adding two numbers and saving back to memory is safe to optimise (at least for the infinity case, I haven't double-checked the subnormal behaviour). It's only when you need to add three or more numbers that you run into issues (though you can go further, if all N numbers have the same sign, you will get the correct result, you just might have saturated at infinity a few operations earlier than native x87) No, you cannot. Operations you can optimise are negation, nan, and infinity checks (ignoring pseudo nans and pseudo infinity checks of course). fp80 has a 15bit exponent, and functionally a 63 significand, vs fp64's 11bit exponent and 52bit significand. When setting x87 to a reduced precision mode you aren't switching to fp64, you're getting a mix with a 15 bit exponent and a 53 significand. The effect is that you retain 53bits of precision for values where fp64 has entered subnormals, and conversely you maintain 53 bits of precision after fp64 has overflowed. There are perf benefits to reducing precision in x87 (at least in the 90s), but the main advantage is consistent rounding with fp64 while in the range of normalized fp64 values.
Klonoar 4y ago
Huh, this is timely. Incredibly random but: do you know if there was anything that changed as of Ventura to where trying to mmap below the 2/4GB boundary would no longer work in Rosetta 2? I've an app where it's worked right up to Monterey yet inexplicably just bombs in Ventura.
- anyfoo 4y ago
  Not affiliated and don't know, but curious why you're doing that in the first place?
  - Klonoar 4y ago
    's not my doing, it's just an older project that's slowly migrating to a newer system but is held back by everyone having lives. I wouldn't do it normally, heh.
- saagarjha 4y ago
  Pretty sure mmap goes almost directly to the kernel in Rosetta 2, and Apple silicon requires at least 4 GB.
  - Klonoar 4y ago
    This works fine in Big Sur and Monterey on Apple Silicon, hence my point about if something changed in Ventura. Edit: Big Sur -> Ventura.
- mrpippy 4y ago
  This should work (Wine obviously needs it when running 32-bit apps). Are you explicitly specifying a small PAGEZERO when compiling?
  - Klonoar 4y ago
    Yup!
keepquestioning 4y ago
Isn't Rosetta 2 "done"? What are you working on now?