First-gen Apple Silicon risks

[dmccloud]

I think the Intel transition was always intended to start with the 64-bit C2D but Intel botched delivery. I could be wrong but there was all sorts of rumours of the last G5 being a stop gap and going from 64 down to 32 bit can't possibly have been what Steve Jobs had in mind.

and at same time AMD was all 64bit, more pci-e lanes workstations / server chips (intel mac pro had less then the g5), more chipset choice desktops / laptops, etc

Intel seriously dropped the ball on the 32-bit to 64-bit transition. At a time when AMD was building 64-bit off the core of the x86 code, Intel was originally pushing their Itanium platform, which was wholly incompatible with x86. Open up Windows Explorer, go to "This PC", and search for "AMD64". Those 25000+ hits that show up are all AMD's 64-bit code that Intel still has to use to this day. I remember running Windows XP x64 on an Athlon x2 machine, and the performance differences between 32-bit XP and 64-bit XP were very noticeable at the time. Now we are seeing a bit of a repeat on the PCI-E front, with AMD now fully supporting PCI-E 4.0.

 

[Waragainstsleep]

and at same time AMD was all 64bit, more pci-e lanes workstations / server chips (intel mac pro had less then the g5), more chipset choice desktops / laptops, etc

They didn't have the mobile processors though and since that covered all Apple laptops plus the iMacs, AMD was not really an option at the time.
[automerge]1596105326[/automerge]
I wonder if Apple ever tried to license x86. No-one else would be allowed but Intel could be secure knowing Apple would keep all theirs to themselves and not overtly target anyone else's business.

 

[dmccloud]

They didn't have the mobile processors though and since that covered all Apple laptops plus the iMacs, AMD was not really an option at the time.
[automerge]1596105326[/automerge]
I wonder if Apple ever tried to license x86. No-one else would be allowed but Intel could be secure knowing Apple would keep all theirs to themselves and not overtly target anyone else's business.

The only reason AMD even had an x86 license is because of IBM. Short explanation is that when Intel was first making processors utilizing the x86 instruction set, IBM wanted to use the new Intel CPUs in its PCs, but only if there was a second supplier. Intel tried to go back on that agreement multiple times over the years, and today AMDs designs are all their own, having lost any rights to Intel's microcode after the 386/486 series of processors.

 

[Analog Kid]

Adoption of ARMv8-A when v9 is just around the corner.

After the transition is complete, I also predict that Apple will be building their own instruction set in a few years and move the entire ecosystem quickly.

I've been wondering about this. Apple talked a lot about PowerPC, and then Intel Macs. ARM wasn't mentioned at all in the Keynote, and I think was mentioned mid-sentence once in the platform SOTU. They've been very careful to brand this "Apple Silicon".

I don't know much about their ARM license. I don't know that they'd drop the ARM instruction set entirely, but I could easily imagine them branching into a non-standard derivative.

Or maybe it really is just a branding exercise.

 

[satcomer]

Seeing as rumours point towards a largely unchanged chassis for the upcoming AS MacBook Pro, what can you foresee being potential early adopter issues? Software compatibility is the most obvious one, I suppose.

Yes at first many lone software hacks won’t work on the new processor Macs so unveil Apple releases the new x-Code developers will have to wait until run of theill developers use the new X-Code! It was the same way back in day!

 

[Waragainstsleep]

The only reason AMD even had an x86 license is because of IBM. Short explanation is that when Intel was first making processors utilizing the x86 instruction set, IBM wanted to use the new Intel CPUs in its PCs, but only if there was a second supplier. Intel tried to go back on that agreement multiple times over the years, and today AMDs designs are all their own, having lost any rights to Intel's microcode after the 386/486 series of processors.

Interesting, didn't know that. I assumed Intel were forced to license x86 by the Monopolies and Mergers Commission or something.
Still, doesn't mean Apple didn't at least ask about licensing x86.

Yes at first many lone software hacks won’t work on the new processor Macs so unveil Apple releases the new x-Code developers will have to wait until run of theill developers use the new X-Code! It was the same way back in day!

Xcode 12 which can compile software for Apple Silicon Macs is already available to Developers. Thats kind of the point of having the Developer Transition Kit, the kit would be pretty useless without Xcode 12.

 

[the8thark]

The fact that many people don't update Apple's existing OS until .3-.6 should tell you everything you need to know about their track record of getting things right the first time. And this is failure within a very narrow set of computer specs. Apple now wants to increase the scope, using two very different hardware packages. If you buy early, you will likely get burned. Wait as long as you can.

I would say that less to do with Apple as you claim and more to do with software support. You need to make sure your software is fully compatable with the new OS version before you update. That takes a while. Often Apple is on 10.X.3 by that point in time.

 

[||\||]

I would say that less to do with Apple as you claim and more to do with software support. You need to make sure your software is fully compatable with the new OS version before you update. That takes a while. Often Apple is on 10.X.3 by that point in time.

Nah. Not true. Issues are not limited to third-party applications. Apple's own apps have/have had problems and people are having/were having issues with basic OS functions. This happens with every iteration. Catalina seems particularly bad.

 

[Waragainstsleep]

I'll say this for Catalina: Apple has finally fixed an issue with Mail that made it impossible to move large amounts of messages between mailboxes, or to move any kind of mailbox folder structure from one account to another.
It used to be painful as you had to do folders one by one and their contents separately. Messages could only be done in small batches too or they would time out before completion and you wouldn't know how far the copy/move had gotten before crapping out.
Now it seems you can dump a folder with at least two nested layers and thousands of messages distributed throughout and Mail just calmly (and seriously quickly) moves the lot without issue.

This makes me very happy.

 

[leman]

Furthermore we have no idea what kind of architectural quirks it may have or whether it has SIMD extensions comparable to SSE and AVX. While Apple will certainly make sure there own applications perform well, expecting 3rd party developers to take code they've spent decades hand tuning for x86/SSE/AVX and optimize it for what is initially going to be a very small percentage of the already limited Mac user base is likely unrealistic.

A quick addendum — just discovered this little gem: https://github.com/simd-everywhere/simde

With this library, you can use your SSE and AVX intrinsics on Apple Silicon just as you normally would. You might not get the optimal performance in each case, but this should be enough to get one started.

 

[atmenterprises]

I can't speak on AS but I bought a first gen Intel iMac in 2006 and it worked flawlessly until the hard drive gave out about eight years later.

 

[Yebubbleman]

Seeing as rumours point towards a largely unchanged chassis for the upcoming AS MacBook Pro, what can you foresee being potential early adopter issues? Software compatibility is the most obvious one, I suppose.

As someone who ordered the first Intel 20" iMac back in February 2006 and remembers what being an early adopter on that transition was like, you're going to have a bunch of software that isn't native. That being said, I don't foresee this being anywhere near as much of a clusterf**k this time around as it was then, especially with Microsoft, Adobe, and Apple's own apps all being pretty much ready to go already. There is also a bevy of Mac software that was needed then that there really isn't a modern equivalent out there (let alone need for) today.

Otherwise, as was stated before, the Core Duo/Solo Macs kind of got shafted in that they were quickly outclassed by the Core 2 Duo Macs. If you bought a Core Duo Mac, you got kicked to the curb one OS release before your Mac's immediate successor. That kind of sucked. So, basically, Rev A you were capped at 10.6 Snow Leopard; Rev B you were capped at 10.7 Lion; and Rev C (and many Revs after) you were capped at 10.11 El Capitan because the requirements didn't change between 10.8 Mountain Lion and 10.11 El Capitan.

On the MacBook Pro side of things, Apple really didn't figure out thermals very well. At least not until the Unibody design some three years into the Intel Era. The first two Revs of MacBook Pro ran way hot for their enclosure (albeit the ATI Radeon Mobility X1600 was more to blame than the Core Duo and Core 2 Duo). The pre-unibody white MacBooks had some issues here too; albeit not as severe nor as often. All that to say that Apple may have additional learning curves ahead when it comes to redesigning their notebooks for the new architecture. However, assuming they are coservative with their early designs, stick to their current designs (at least initially) and largely don't do any drastic chassis thinning, they should be much better off this time around.

As long as someone in the engineering team does a good and proper retrospective of the Intel Mac era from 2006 to present, and goes over every learned lesson with a fine tooth comb, they ought to be much better off this time around.