13 ms·

It seems to me that if Apple felt that Nvidia would limit them, they could have outbid them for ARM! So I think you are correct.

dannyw 6y ago
Apple would not get antitrust approval (iPhone maker controls all android chips????). So that’s why.
- macintux 6y ago
  Were it a serious enough threat to their ARM license, they'd find a way to buy ARM and keep it independent.
- kabacha 6y ago
  Exactly, Apple is already straddling the line (and imho way past it) on anti-comp laws.
  - jonhohle 6y ago
    What is their monopoly or which of their competitors are they colluding with?
    - tick_tock_tick 6y ago
      Neither of those are required to violate anti-trust laws.
      - jonhohle 6y ago
        Such as? https://www.ftc.gov/enforcement/anticompetitive-practices https://www.ftc.gov/enforcement/anticompetitive-practices
  - kzrdude 6y ago
    I'm not defending Apple, just thinking that can't we say this for many of the biggest tech firms? They are way past the line on anticompetitive business.
    - wongarsu 6y ago
      Yes, Apple is not alone in this. Google is another example, and they are very aware of this and are acting very carefully
scarface74 6y ago
I doubt Apple is dumb enough not to have basically a perpetual license for ARM.
- systemvoltage 6y ago
  I would also agree, the thing is - businesses breakup and come together all the time. If it makes sense and both parties can agree despite of past disagrements and lawsuits, they will partner. Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.
  - scarface74 6y ago
    What need does Apple have with ARMs R&D going forward? They have their own chip designers, build tools, etc.? True about frenemies the entire time that Apple was suing Samsung, it was using Samsung to manufacture many of its components.
    - pas 6y ago
      But if your chip heavily builds on arm's IP you need a license for that at least as long as you can't replace the infringing parts of the design. Which sounds very much impossible if you also want to progress on other aspects of having the best chips.
      - spacedcowboy 6y ago
        Apple uses the ARM ISA. It doesn't use ARM IP - as in, the design of the chip. Apple designed their own damn chip! Since they're not branding it as ARM in any way, shape, or form, and they have a perpetual architectural license to the ISA, I suspect they could do pretty much what they please - as long as they don't call it ARM. Which they don't.
        pas 6y ago
        During the design were they careful not to create any derivative works of arm IP and/or not to infringe on any of arm's patents?
millstone 6y ago
I think Apple is not committed to ARM at all. Bitcode, Rosetta 2, "Apple Silicon" - it all suggests they want to keep ISA flexibility.
- emn13 6y ago
  Wow, but that cost - it's not a small thing to transition ISA, and don't forget that this transition is one of the simpler ones (more registers, fairly few devices). The risks of transitioning everything away from arm would be much greater. I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.
  - pas 6y ago
    Do it more and more and they'll have the tools to efficiently manage them. Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.
  - rocqua 6y ago
    At the low-level driver interface, transitioning ISA is a big deal. But I would guess that, at higher levels, most of the work is just changing the target of your compiler? As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.
    - emn13 6y ago
      No way; not at all. First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff. Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat. Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad? All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.

dannyw 6y ago

Apple would not get antitrust approval (iPhone maker controls all android chips????). So that’s why.

macintux 6y ago
Were it a serious enough threat to their ARM license, they'd find a way to buy ARM and keep it independent.
kabacha 6y ago
Exactly, Apple is already straddling the line (and imho way past it) on anti-comp laws.
- jonhohle 6y ago
  What is their monopoly or which of their competitors are they colluding with?
  - tick_tock_tick 6y ago
    Neither of those are required to violate anti-trust laws.
    - jonhohle 6y ago
      Such as? https://www.ftc.gov/enforcement/anticompetitive-practices https://www.ftc.gov/enforcement/anticompetitive-practices
- kzrdude 6y ago
  I'm not defending Apple, just thinking that can't we say this for many of the biggest tech firms? They are way past the line on anticompetitive business.
  - wongarsu 6y ago
    Yes, Apple is not alone in this. Google is another example, and they are very aware of this and are acting very carefully

scarface74 6y ago

I doubt Apple is dumb enough not to have basically a perpetual license for ARM.

systemvoltage 6y ago
I would also agree, the thing is - businesses breakup and come together all the time. If it makes sense and both parties can agree despite of past disagrements and lawsuits, they will partner. Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.
- scarface74 6y ago
  What need does Apple have with ARMs R&D going forward? They have their own chip designers, build tools, etc.? True about frenemies the entire time that Apple was suing Samsung, it was using Samsung to manufacture many of its components.
  - pas 6y ago
    But if your chip heavily builds on arm's IP you need a license for that at least as long as you can't replace the infringing parts of the design. Which sounds very much impossible if you also want to progress on other aspects of having the best chips.
    - spacedcowboy 6y ago
      Apple uses the ARM ISA. It doesn't use ARM IP - as in, the design of the chip. Apple designed their own damn chip! Since they're not branding it as ARM in any way, shape, or form, and they have a perpetual architectural license to the ISA, I suspect they could do pretty much what they please - as long as they don't call it ARM. Which they don't.
      - pas 6y ago
        During the design were they careful not to create any derivative works of arm IP and/or not to infringe on any of arm's patents?

millstone 6y ago

I think Apple is not committed to ARM at all. Bitcode, Rosetta 2, "Apple Silicon" - it all suggests they want to keep ISA flexibility.

emn13 6y ago
Wow, but that cost - it's not a small thing to transition ISA, and don't forget that this transition is one of the simpler ones (more registers, fairly few devices). The risks of transitioning everything away from arm would be much greater. I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.
- pas 6y ago
  Do it more and more and they'll have the tools to efficiently manage them. Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.
- rocqua 6y ago
  At the low-level driver interface, transitioning ISA is a big deal. But I would guess that, at higher levels, most of the work is just changing the target of your compiler? As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.
  - emn13 6y ago
    No way; not at all. First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff. Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat. Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad? All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.