Stop panicking about Apple's rumored switch from Intel to its own chips in the Mac

1789101113»

Comments

  • Reply 241 of 246
    Mike WuertheleMike Wuerthele Posts: 2,862administrator
    Wouldn’t Apple start this with the MacBook as a test bed/proof of concept? I can’t imagine the iMac Pro or MacPro or even the higher end MacBook Pro dumping Intel anytime soon.
    FTA: "The shift won't be immediate, and will likely start on Apple's low-end, like the MacBook and possibly a Mac mini migration."
    ARM mini would be my Mac OS X exit. Period. That's going to make me shift even more towards MS. I don't have an apple laptop anymore. Corporate machines are MS and surface looks like a more viable option. What Apple needs to understand is that the iPad is also starting to hang loose for some people. Whats the point in OS X if you can't use the full value out of it(the pure differentiation) . Features eg. like moving files over wifi, moving content to be used and consumed via OS features on your other (apple) devices. Seamless integration.  
    ... why would you not be able to use those features on an ARM Mac?
    fastasleep
  • Reply 242 of 246
    dick applebaumdick applebaum Posts: 12,433member
    nht said:
    nht said:

    asdasd said:
    melgross said:

    asdasd said:
    melgross said:

    Soli said:
    knowitall said:
    I keep wondering if it would make sense for a Mac (and macOS) to support configurations with:
    1. an ARM CPU and an Intel CPU
    2. multiple ARM CPUs
    3. multiple ARM CPUs and an Intel CPU
    Maybe it need not be all or nothing?
    I think it does. Including an Intel CPU defeats the purpose (getting rid of Intel).
    Why assume that Apple would be getting rid of Intel because they wanted to use an ARM-based Mac for, say, a new MacBook Air that was basically the 12" MacBook but running an Apple-designed chip? Do you really think there's an ARM-equivlenet that will work for the Mac Pro? I don't see the Pro-line being affected by this until such time as most people are instead bitching that Apple isn't moving fast enough to switch their high-end machines to to ARM.
    Prescient!
    Sure. If Apple can get the ARM chips to run x86 software natively, as I’m proposing, there is no way they could consider it for a high end machine. While some say that Apple could force its users and developers down that road again, I’m not so sure.

    whike users don’t care what in the machine, as long as it works, developers do. There are all too many ignorant people out there who believe the solution is to “just have it go through a recompile!” Sure, if you have a flashlight app, that will work. But no decently complex software will ever work properly, if at all, with “just” a recompile. It’s months of major work, at least, and mammoth amounts of money. Developers have to be taken off other projects, etc.

    having said that, desktop chips don’t have the power constraints mobile chips do. Even the Macbook Pro uses chips up to a 35 watt power draw. Compare that to the 6 watt draw of the A series for the iPad, or the M series of Intel chips for the Macbook. There’s plenty Apple could do just by going to 12 Watts. But at some point there’s a limit. As you go up the power scale, you actually have less options, because when you hit these power levels, you find that you’re competing with really high end chips. Right now, the A series can compete with the M series easily, and some other ultralow power Intel chips for mobile. But Desktop chips are different. Apple may still have an advantage, but by how much?
    It’s will be a recompile for pretty much everything that uses objective c, swift, even c or c++ code that compiles already in Xcode. What compiles for ARM or x86 now for iOS can work for the Mac in future. 
    It might, it might not, depending on how Apple handles it. Some code may not be doing things correctly, such as using pointers and memory locations they know Apple has told them not to. All that will change.
    Sorry that’s technically illiterate. Yes during the carbon transformation - which was the move of the OS 9 to a reduced api set that would compile for OS X developers had to do some work, and some developers were using memory incorrectly. That’s because the old OS 9 api allowed access to the memory behind pointers, and carbon replaced that with references which were opaque. Also developers back then were hackers. 

    Thats not the case now. There’s no way of writing swift, objective C, c or C++ in Xcode in such a way that it compiles incorrectly in ARM rather than x86. High level code is abstracted away from such considerations. You can cause memory issues ie overflows on c arrays but it would happen on both processors. 
    What is technically illiterate is claiming anything non-trivial is a simple recompile...better today than before with arm now little endian...but shit, look at the lack of aTV ports of iOS apps that could reuse 80-90% of the UI.  Going from iOS to macOS is also not that common.



    I'm certainly no Intel chip/ISA expert... but, have some honest questions.
    What is X86, X64, X86-64, AMD64 and Intel64? What's the difference between them?

    They are all names for the Instruction Set Architecture (ISA) of a processor.
    x86: This is the original 32-bit Intel x86 instruction set that has come to dominate the world.

    x86-64, X64: These are the generic names for the 64-bit extension to x86 that is fully backwards compatible with x86. These are specified by Intel but based on AMD's design.

    AMD64: When 64-bit processors were first coming to market, AMD devised the 64-bit extension to the x86 instruction set which maintained backwards compatibility with all the existing 32-bit programs. This was AMD64, it's more or less the same as the current x86-64 specification.

    Intel64: This term is ambiguous but could refer to the x86 64-bit extension or it could refer to Intel Itanium (IA-64). IA-64 was Intel's original 64-bit offering to compete with AMD64. It was a complete overhaul of the instruction set that ruined backwards compatibility with all applications for x86. It was a complete failure for Intel and they ended up releasing new processors based on AMD64 which became today's x86 64-bit extension.

    https://www.quora.com/What-is-X86-X64-X86-64-AMD64-and-Intel64-Whats-the-difference-between-them

    As I understand the above:

    1. AMD64 is a 64-bit extension to Intel X86
    2. AMD64 is backwards compatible with Intel X86 and prior Intel ISAs going all the way back to 8-bit, 16-bit, 32-bit
    3. Intel 64-bit implementation is uses the AMD64 specs
    4. AMD64 runs on ARM

    If these are true, wouldn't your following assertions, largely, be moot?

    nht said:
    Going from native x86 macOS to arm macOS will mostly compile clean the first go, and maybe pass your unit tests but a lot of stuff out there isn’t native.  Java, python, matlab, mono, games, etc that uses third party tool chains will require the toolmakers to port and they often need to code closer to the OS and lower levels than application code.  

    These apps have a bigger footprint that you would assume in the scientific and commercial worlds.
    It would be except for #4 isn't true.  arm64 is ARM.
    Ahh... My bad!  I was surfing all over the place and conflated some things:

    1. Intel chips convert CISC instructions to RISC instructions for execution
    2. AMD developed the AMD64 ISA which is a superset of Intel x86 ISA
    3. AMD was/is developing X-gene 64-bit ARM servers
    4. Intel threatened to sue to prevent Microsoft, Qualcomm (or others) from appropriating or emulating its ISA IP 

    What I don't understand is how can AMD use Intel ISA others cannot.

    Edit:  Apparently, AMD has a non-transferrable license to use the Intel x86 ISA.
    edited April 9
  • Reply 243 of 246
    SoliSoli Posts: 7,666member
    nht said:
    nht said:

    asdasd said:
    melgross said:

    asdasd said:
    melgross said:

    Soli said:
    knowitall said:
    I keep wondering if it would make sense for a Mac (and macOS) to support configurations with:
    1. an ARM CPU and an Intel CPU
    2. multiple ARM CPUs
    3. multiple ARM CPUs and an Intel CPU
    Maybe it need not be all or nothing?
    I think it does. Including an Intel CPU defeats the purpose (getting rid of Intel).
    Why assume that Apple would be getting rid of Intel because they wanted to use an ARM-based Mac for, say, a new MacBook Air that was basically the 12" MacBook but running an Apple-designed chip? Do you really think there's an ARM-equivlenet that will work for the Mac Pro? I don't see the Pro-line being affected by this until such time as most people are instead bitching that Apple isn't moving fast enough to switch their high-end machines to to ARM.
    Prescient!
    Sure. If Apple can get the ARM chips to run x86 software natively, as I’m proposing, there is no way they could consider it for a high end machine. While some say that Apple could force its users and developers down that road again, I’m not so sure.

    whike users don’t care what in the machine, as long as it works, developers do. There are all too many ignorant people out there who believe the solution is to “just have it go through a recompile!” Sure, if you have a flashlight app, that will work. But no decently complex software will ever work properly, if at all, with “just” a recompile. It’s months of major work, at least, and mammoth amounts of money. Developers have to be taken off other projects, etc.

    having said that, desktop chips don’t have the power constraints mobile chips do. Even the Macbook Pro uses chips up to a 35 watt power draw. Compare that to the 6 watt draw of the A series for the iPad, or the M series of Intel chips for the Macbook. There’s plenty Apple could do just by going to 12 Watts. But at some point there’s a limit. As you go up the power scale, you actually have less options, because when you hit these power levels, you find that you’re competing with really high end chips. Right now, the A series can compete with the M series easily, and some other ultralow power Intel chips for mobile. But Desktop chips are different. Apple may still have an advantage, but by how much?
    It’s will be a recompile for pretty much everything that uses objective c, swift, even c or c++ code that compiles already in Xcode. What compiles for ARM or x86 now for iOS can work for the Mac in future. 
    It might, it might not, depending on how Apple handles it. Some code may not be doing things correctly, such as using pointers and memory locations they know Apple has told them not to. All that will change.
    Sorry that’s technically illiterate. Yes during the carbon transformation - which was the move of the OS 9 to a reduced api set that would compile for OS X developers had to do some work, and some developers were using memory incorrectly. That’s because the old OS 9 api allowed access to the memory behind pointers, and carbon replaced that with references which were opaque. Also developers back then were hackers. 

    Thats not the case now. There’s no way of writing swift, objective C, c or C++ in Xcode in such a way that it compiles incorrectly in ARM rather than x86. High level code is abstracted away from such considerations. You can cause memory issues ie overflows on c arrays but it would happen on both processors. 
    What is technically illiterate is claiming anything non-trivial is a simple recompile...better today than before with arm now little endian...but shit, look at the lack of aTV ports of iOS apps that could reuse 80-90% of the UI.  Going from iOS to macOS is also not that common.



    I'm certainly no Intel chip/ISA expert... but, have some honest questions.
    What is X86, X64, X86-64, AMD64 and Intel64? What's the difference between them?

    They are all names for the Instruction Set Architecture (ISA) of a processor.
    x86: This is the original 32-bit Intel x86 instruction set that has come to dominate the world.

    x86-64, X64: These are the generic names for the 64-bit extension to x86 that is fully backwards compatible with x86. These are specified by Intel but based on AMD's design.

    AMD64: When 64-bit processors were first coming to market, AMD devised the 64-bit extension to the x86 instruction set which maintained backwards compatibility with all the existing 32-bit programs. This was AMD64, it's more or less the same as the current x86-64 specification.

    Intel64: This term is ambiguous but could refer to the x86 64-bit extension or it could refer to Intel Itanium (IA-64). IA-64 was Intel's original 64-bit offering to compete with AMD64. It was a complete overhaul of the instruction set that ruined backwards compatibility with all applications for x86. It was a complete failure for Intel and they ended up releasing new processors based on AMD64 which became today's x86 64-bit extension.

    https://www.quora.com/What-is-X86-X64-X86-64-AMD64-and-Intel64-Whats-the-difference-between-them

    As I understand the above:

    1. AMD64 is a 64-bit extension to Intel X86
    2. AMD64 is backwards compatible with Intel X86 and prior Intel ISAs going all the way back to 8-bit, 16-bit, 32-bit
    3. Intel 64-bit implementation is uses the AMD64 specs
    4. AMD64 runs on ARM

    If these are true, wouldn't your following assertions, largely, be moot?

    nht said:
    Going from native x86 macOS to arm macOS will mostly compile clean the first go, and maybe pass your unit tests but a lot of stuff out there isn’t native.  Java, python, matlab, mono, games, etc that uses third party tool chains will require the toolmakers to port and they often need to code closer to the OS and lower levels than application code.  

    These apps have a bigger footprint that you would assume in the scientific and commercial worlds.
    It would be except for #4 isn't true.  arm64 is ARM.
    Ahh... My bad!  I was surfing all over the place and conflated some things:

    1. Intel chips convert CISC instructions to RISC instructions for execution
    2. AMD developed the AMD64 ISA which is a superset of Intel x86 ISA
    3. AMD was/is developing X-gene 64-bit ARM servers
    4. Intel threatened to sue to prevent Microsoft, Qualcomm (or others) from appropriating or emulating its ISA IP 

    What I don't understand is how can AMD use Intel ISA others cannot.

    Edit:  Apparently, AMD has a non-transferrable license to use the Intel x86 ISA.
    Could Apple get a license from Intel? Would it still put Apple in the relatively same position as they are now or would it allow them major advantages with their custom silicon that would still allow for Windows via Bootcamp and/or VMs to work great?
  • Reply 244 of 246
    dick applebaumdick applebaum Posts: 12,433member
    Soli said:
    nht said:
    nht said:

    asdasd said:
    melgross said:

    asdasd said:
    melgross said:

    Soli said:
    knowitall said:
    I keep wondering if it would make sense for a Mac (and macOS) to support configurations with:
    1. an ARM CPU and an Intel CPU
    2. multiple ARM CPUs
    3. multiple ARM CPUs and an Intel CPU
    Maybe it need not be all or nothing?
    I think it does. Including an Intel CPU defeats the purpose (getting rid of Intel).
    Why assume that Apple would be getting rid of Intel because they wanted to use an ARM-based Mac for, say, a new MacBook Air that was basically the 12" MacBook but running an Apple-designed chip? Do you really think there's an ARM-equivlenet that will work for the Mac Pro? I don't see the Pro-line being affected by this until such time as most people are instead bitching that Apple isn't moving fast enough to switch their high-end machines to to ARM.
    Prescient!
    Sure. If Apple can get the ARM chips to run x86 software natively, as I’m proposing, there is no way they could consider it for a high end machine. While some say that Apple could force its users and developers down that road again, I’m not so sure.

    whike users don’t care what in the machine, as long as it works, developers do. There are all too many ignorant people out there who believe the solution is to “just have it go through a recompile!” Sure, if you have a flashlight app, that will work. But no decently complex software will ever work properly, if at all, with “just” a recompile. It’s months of major work, at least, and mammoth amounts of money. Developers have to be taken off other projects, etc.

    having said that, desktop chips don’t have the power constraints mobile chips do. Even the Macbook Pro uses chips up to a 35 watt power draw. Compare that to the 6 watt draw of the A series for the iPad, or the M series of Intel chips for the Macbook. There’s plenty Apple could do just by going to 12 Watts. But at some point there’s a limit. As you go up the power scale, you actually have less options, because when you hit these power levels, you find that you’re competing with really high end chips. Right now, the A series can compete with the M series easily, and some other ultralow power Intel chips for mobile. But Desktop chips are different. Apple may still have an advantage, but by how much?
    It’s will be a recompile for pretty much everything that uses objective c, swift, even c or c++ code that compiles already in Xcode. What compiles for ARM or x86 now for iOS can work for the Mac in future. 
    It might, it might not, depending on how Apple handles it. Some code may not be doing things correctly, such as using pointers and memory locations they know Apple has told them not to. All that will change.
    Sorry that’s technically illiterate. Yes during the carbon transformation - which was the move of the OS 9 to a reduced api set that would compile for OS X developers had to do some work, and some developers were using memory incorrectly. That’s because the old OS 9 api allowed access to the memory behind pointers, and carbon replaced that with references which were opaque. Also developers back then were hackers. 

    Thats not the case now. There’s no way of writing swift, objective C, c or C++ in Xcode in such a way that it compiles incorrectly in ARM rather than x86. High level code is abstracted away from such considerations. You can cause memory issues ie overflows on c arrays but it would happen on both processors. 
    What is technically illiterate is claiming anything non-trivial is a simple recompile...better today than before with arm now little endian...but shit, look at the lack of aTV ports of iOS apps that could reuse 80-90% of the UI.  Going from iOS to macOS is also not that common.



    I'm certainly no Intel chip/ISA expert... but, have some honest questions.
    What is X86, X64, X86-64, AMD64 and Intel64? What's the difference between them?

    They are all names for the Instruction Set Architecture (ISA) of a processor.
    x86: This is the original 32-bit Intel x86 instruction set that has come to dominate the world.

    x86-64, X64: These are the generic names for the 64-bit extension to x86 that is fully backwards compatible with x86. These are specified by Intel but based on AMD's design.

    AMD64: When 64-bit processors were first coming to market, AMD devised the 64-bit extension to the x86 instruction set which maintained backwards compatibility with all the existing 32-bit programs. This was AMD64, it's more or less the same as the current x86-64 specification.

    Intel64: This term is ambiguous but could refer to the x86 64-bit extension or it could refer to Intel Itanium (IA-64). IA-64 was Intel's original 64-bit offering to compete with AMD64. It was a complete overhaul of the instruction set that ruined backwards compatibility with all applications for x86. It was a complete failure for Intel and they ended up releasing new processors based on AMD64 which became today's x86 64-bit extension.

    https://www.quora.com/What-is-X86-X64-X86-64-AMD64-and-Intel64-Whats-the-difference-between-them

    As I understand the above:

    1. AMD64 is a 64-bit extension to Intel X86
    2. AMD64 is backwards compatible with Intel X86 and prior Intel ISAs going all the way back to 8-bit, 16-bit, 32-bit
    3. Intel 64-bit implementation is uses the AMD64 specs
    4. AMD64 runs on ARM

    If these are true, wouldn't your following assertions, largely, be moot?

    nht said:
    Going from native x86 macOS to arm macOS will mostly compile clean the first go, and maybe pass your unit tests but a lot of stuff out there isn’t native.  Java, python, matlab, mono, games, etc that uses third party tool chains will require the toolmakers to port and they often need to code closer to the OS and lower levels than application code.  

    These apps have a bigger footprint that you would assume in the scientific and commercial worlds.
    It would be except for #4 isn't true.  arm64 is ARM.
    Ahh... My bad!  I was surfing all over the place and conflated some things:

    1. Intel chips convert CISC instructions to RISC instructions for execution
    2. AMD developed the AMD64 ISA which is a superset of Intel x86 ISA
    3. AMD was/is developing X-gene 64-bit ARM servers
    4. Intel threatened to sue to prevent Microsoft, Qualcomm (or others) from appropriating or emulating its ISA IP 

    What I don't understand is how can AMD use Intel ISA others cannot.

    Edit:  Apparently, AMD has a non-transferrable license to use the Intel x86 ISA.
    Could Apple get a license from Intel? Would it still put Apple in the relatively same position as they are now or would it allow them major advantages with their custom silicon that would still allow for Windows via Bootcamp and/or VMs to work great?
    Interesting questions:

    I suspect that Apple has more leverage thanyone to get a license.  It depends on what Intel thinks the future value is of their x86 ISA.

    I don’t think Apple would bother if they couldn’t use the license in their custom silicon for the advantages you mention.
    edited April 9
  • Reply 245 of 246
    melgrossmelgross Posts: 30,520member
    bb-15 said:
    jdiamond said:
    In all the Mac CPU shifts, IMO, what made the Intel shift the most significant is it provided a gateway for switchers - a crutch for people to use Windows while slowly over months learning the Mac.  While all Macs have had some sort of Windows emulation (remember those 486 cards), this was the first time you could truly get native Windows speeds.  It may have also been a marketing win, since people could understand how powerful the CPU was...

    Then, all that will be left is the old marketing problem - once again, people will say "How does a Threadripper laptop compare to an Apple A12x laptop?" ...

    However, there are mitigating factors now:

    -> There are a LOT more Mac users - it's much more common to have a Mac, whether it's at home, school or business.  There's a lot more help out there...
    * You are right that Intel on the Mac helped switchers to go to the Mac side.
    - It is a major reason why Mac OS worldwide marketshare was able to go above 5% (from a bottom of about 2%).
    - Using Windows on an Intel Mac became easy to do with Boot Camp or emulation and importantly performance was fast enough to even use Windows games on a Mac.

    * Where I think you are wrong is that you assume that Windows on a Mac is only useful for switching.
    Instead using Windows on Mac can be ongoing.
    - Examples; let's say a person wants to play Fallout 4 on a Mac?
    Easy. Use Boot Camp and install Windows.
    - And what if a job requires complex formatted documents and the equivalent Mac software doesn't get the formatting right?
    Run Boot Camp or an emulator on the Mac to use Windows business software.

    * I remember those 486 cards in the 90s. They made Macs much more expensive. Windows emulation on the Power PC CPU was slow.
    In early 2000s at my house I had to have both a Windows PC and Macs to meet my family's computing needs.

    In the late 80s Apple had the opportunity to switch to Intel. It didn't and John Sculley admits that this was his biggest mistake at Apple.
    https://www.networkworld.com/article/2337951/wireless/former-apple-ceo-reveals-his-biggest-mistake.html

    Not going with Intel on the Mac led to the Apple's decline in the 90s.
    - Now with the success of the iPhone, the situation today is different. But isolating Macs again (for the average user) by using a different CPU is risky.
    Not going with Intel in the 90’s had nothing to do with Apple’s decline. Nothing whatsoever.

    your history is all screwed up.

    the reason for Apple’s decline, had to do tith the then CEO, Micheal Spindler, making a major error for the holiday 1995 season. By that time, the PPC had established itself, and talk was that it would take over for Windows as well, as Microsoft was known to be working on a version for the new NT system they were coming out with.

    right before that holiday quarter, my Mac group here in NYC - NYMUG had two people from Apple at out meeting. At the time, NYMUG was one of the largest user groups around, at over 5,400 members. We would get 375 people to an average meeting in Martin Luther H.S. When a major company came, such as Adobe or Apple itself, we would get upwards of 500 people to that meeting.

    so Apple would come to us with new products, and announcements. This they did then. They stated that Apple was going to increase its marketshare from 12% to 16% with two new computers that cost under $4,000, including keyboard, but not the monitor. Back then, all computers were expensive. We were pretty excited by that. But even over dinner later, they wouldn’t tell us, on the executive board of the club, what exactly these machines would comprise of.

    when the quarter commented, and Apple announced these machines, in the 600 family, they were using the older 68040 chips. Well, by then, not too many peop,e wanted that, and the machines tanked. Apple intended to sell 1 million machines that quarter, a lot for the time, but just sold a fraction. When c]schools and libraries begged Apple to either give them unsold machines, or to sell them to them at cost, Spindler, who was a finance guy, you know, a bean counter, decided not to, and dumped them. I mean literally.

    the word got out, and CIOs from large corporations, who never liked Macs, told their bosses that Apple would go out of business, and so they should get rid of their Macs and go all in Windows. That happened, and Apple began a decline. A friend of mine was in charge of small computer purchases at Boeing at the time. They had about 34,000 Macs, and a bit over 500 Windows machines. Three years later, they had about 3,000 Macs and about 30,000+ Windows machines.

    this had nothing to do with x86. In fact, after Steve came back and revitalized Apple, Apple’s Mac sales were climbing at a very high rate which reached as high as 35% a year. Right after Steve announced the move to Intel, some predictions were that Apple’s sales would tank. Of course, that didn’t happen, and Apple maintained a 25% sales increase for several years, though the Bush recession killed much of that for everyone, and it’s never recovered.
  • Reply 246 of 246
    melgrossmelgross Posts: 30,520member

    Wouldn’t Apple start this with the MacBook as a test bed/proof of concept? I can’t imagine the iMac Pro or MacPro or even the higher end MacBook Pro dumping Intel anytime soon.
    FTA: "The shift won't be immediate, and will likely start on Apple's low-end, like the MacBook and possibly a Mac mini migration."
    ARM mini would be my Mac OS X exit. Period. That's going to make me shift even more towards MS. I don't have an apple laptop anymore. Corporate machines are MS and surface looks like a more viable option. What Apple needs to understand is that the iPad is also starting to hang loose for some people. Whats the point in OS X if you can't use the full value out of it(the pure differentiation) . Features eg. like moving files over wifi, moving content to be used and consumed via OS features on your other (apple) devices. Seamless integration.  
    Surface isn’t an option for anyone. Right now, iPads are 91% of all corporate tablets, and Surface is hanging around 1-2%. Surface is also hanging on a thread at Microsoft, and I wouldn’t be surprised if at some point they kill it.

    apple is also selling more machines to enterprise, and these sales are climbing by as much as 50% a year, off a small base, while Windows still declines. Microsoft understands this, which is why they just rearranged their corporate structure to continue to de-emphasize Windows in favor of pushing an all in attitude towards equal ability for every OS.
    edited April 10
Sign In or Register to comment.