And before that they successfully managed the transition from m68k to PPC.

The processor doesn't matter.

Yep. Just to put this into perspective: tiny NeXT shipped NeXTStep on 4 architectures. M68K, Intel, PA-RISC and SPARC. They had at least two more in the lab, M88K and PPC.

Compiling for different architectures was a checkbox in ProjectBuilder (after you took care of endian issues, once). Much easier than in Xcode today.

My favorite was that they apparently shipped an additional architecture by accident: the developer tools came with one of the aforementioned architectures long after it had been officially dropped.

The processor doesn't matter to Apple because they don't mind fucking over their customers and their third party developers.

That’s a popular line around here but it doesn’t line up with the reality. When they’ve done architecture changes in the past they’ve reached out to large developers for feedback before committing to the changes being made. The original very OpenStep like OS X did not ship en mass because it lacked a bridge library to support developers and Adobe and others cried foul. That’s how Carbon came about. When 64bit Carbon was shelved some 10 years ago, the “sky is falling” was proclaimed but Adobe came along for the ride and everything was fine. Are Technica did a great write up summarizing both the genesis and end of Carbon development [0]

The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know.

Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at.

[0] https://arstechnica.com/staff/2008/04/rhapsody-and-blues/

[1] http://vintagemacmuseum.com/the-apple-developer-transition-s...

Apple spent a lot of effort with each transition trying to make it as smooth for customers as possible while still pushing forward with the new system.

I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.

(gaius is right, however: CodeWarrior saved Apple once, but they've clearly learned a lot with successive transitions.)

It’s true that Apple fumbled 68k —> PPC as far as MPW went but it’s also true that creating fat binaries was a total non-issue with CodeWarrior. Apple had learnt from that mistake for PPC —> x86

The difference is that the x86 chips were so much faster than what they had for PPC, that they could still emulate it without customers feeling like they were going backwards.

How does this fuck over customers or third party devs in anyways?

If you are changing CPU architecture, you have three options with respect to backwards compatibility.

1) Old programs don't work, because it is a different CPU architecture. 2) Old programs work, but in a VM, so it can't take full advantage of the hardware. 3) Old programs must be recompiled to work on new architecture.

The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.

You go through some mental gymnastics to make it seem like #3 is only possible for open source.

Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs.

None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software.

Cheers

I'm looking at it from the point of view of the customer. If I don't have the source code, I cannot recompile the code, end of story. The company that sold the binary executable might recompile it for the new architecture, but they're probably not going to give the recompiled binary away for free. That is why I say that #3 is, for the user, only possible for open source.

I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place.

If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.

You can conjure up fictitious reasons, but the manufacturer never guaranteed the buyer that future hardware versions would use the same CPU.

Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs.

You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)

I doubt that story has changed much.

It does matter that the new processor is a lot more powerful and faster than the old processor. This wouldn't be the case this time.

It's not powerful/faster that sells chips, it's power and speed relative to envelope. Maybe the iMac pro continues to ship with Xeons, the iMac with Core i5 and i7 depending on configuration.

But compare the Intel Core m3 to the Apple A11, and a completely different story will emerge. The A11 is already comparable to relatively recent Macbooks in terms of performance.

The point is, if we're going to bring up what an 'easy' time Apple has had transitioning from one architecture to another, it's worth remembering each transition came with a big performance jump. This made the new platform desirable and emulation bearable. If they are considering a transition again, 'bearable emulation' is not as much of a given.

While single core performance may not be higher, I could see Apple adding more cores than their current Intel offerings have, and still fall within an acceptable power envelope (thermal, battery life, etc).

My memory is that the PPC -> x86 jump was due to PPC supply issues and the fact that the PowerPC 970 / G5 was too power hungry for laptops. I could be wrong, but I administered labs of mixed x86 / PPC Macs during the transition and the performance jump seemed just like the normal difference between successive generations.

Keep in mind that while you don’t see much 68k outside embedded these days, you still see POWER in supercomputer rankings, and it also appeared in game consoles.

They were a lot faster, especially the laptops. And that was really the consumer proposition in both cases - you put up with our switch in exchange for a faster, better, stronger computer.

If Apple ends up doing it, the proposition would almost certainly be different and it seems very unlikely it would involve things like running your x86_64 macOS apps on your brand new Mac except three times slower. Thinking about this in terms of previous changes (or in terms of PPC history details) just seems obviously wrongheaded to me.

People assume that everyone who uses a Mac is running Photoshop or developing advanced AI but they're not. There are a lot of professionals using Apple products but they avoid the low end like the plague. Apple is a lifestyle brand these days and much of the user base has no demand for anything beyond the core Apple Apps.

The Macbook Core i3 is barely enough to run Safari or iTunes and Apple could probably replace the CPU without many of those users ever noticing.

I'd expect a huge performance jump when the new ARM-based Macs come out, both in Single-core (they can ramp up the clocks and increase cache and execution units) and Multi-core (they can add more cores to fit new power budgets as well).

The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench, and within about 30% on their top desktop CPUs.

It's entirely possible for chip architectures to see 2x-3x speeds when moving from mobile power budgets to desktop power budgets.

An Intel Pentium 4410Y Kaby Lake running at 4.5-6 Watts gets about 1800 single-core on Geekbench, while an Intel Core i7-7700K Kaby Lake running at 115 Watts gets 5600 single-core on Geekbench.

> The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench

No, they aren't. iPhone X's multithreaded geekbench score is 10k. The 15" macbook pro is 15k. That's a lot more than 10%. It's only close if you look at the lower end Intel chips, the dual core ones (which is what Apple ships in the 13" macbook pro).

Those are multi-core numbers, not the single-core numbers.

What do you think is the most important for 250million desktop users? Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.

Even browsers are doing a better job of loading multiple cores now and desktop machines often have more processes running in the background.

> Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.

My dual Xeon E5-2690 v4 regularly loads all its cores and benefits greatly from them, but keep making assumptions by all means.

But if all you want is a chromebook competitor then sure, A11-class works fine. I'm going to guess that the people using Mac Pros tend to care a bit more about just running Chrome/Safari, though. Maybe Apple is just going to completely give up on their historically strong content creation market.

Geekbench is not representative of application performance, sadly.

The Intel chip is definitely along the biggest line items on a Mac. Apple can cut that cost by 70-80%.

Maybe the first few hardware revisions it won't be as performant. Its probably going to be an Armbook that will have the form factor of the Air or the Macbook but with A12 chips. The current A11s are in striking distance for performance.

The current A-series SoC’s were also designed around the power and thermal requirements of a mobile phone. In a laptop or desktop they would have a lot more wiggle room.

They could also run more than one per machine

> This wouldn't be the case this time.

I don't think we can make that assumption here. I would be very surprised if the ARM chips they put in desktops are identical to the ones they put in phones.

For one, the power budget is going to be a lot larger (even for a notebook), and power is roughly equivalent to speed.

Apple's ARM chips compare favorably to the crap that is in most laptops. Those Intel Core i3 6100U or Core i5 6200U chips? The midrange and low end will be greatly served from ARM chips.

They will not compete at the high end against the Core i7s with 6 cores running at 3.8GHz (12 with HT) though.

> Geekbench 4 scores are calibrated against a baseline score of 4000 (which is the score of an Intel Core i7-6600U)

https://browser.geekbench.com/mac-benchmarks

> iMac (27-inch Retina Mid 2017) | Intel Core i7-7700K @ 4.2 GHz (4 cores) | 5683

https://browser.geekbench.com/ios-benchmarks

> iPhone 8 | Apple A11 Bionic @ 2.4 GHz | 4217

4217 for Apple A11 @ 2.4Ghz vs 5683 for Intel Core i7-7700K @ 4.2GHz

Of course, microbenchmarks don't mean much. But the margins are thin enough for users to notice already. Add in more power, more cores, more Ghz, better optimized instruction set, more vertically integrated system, and who knows.

geekbench scores look impressive because they are very very short bursts to prevent power/thermal throttling on iphones, iphones are able to scale up/down preformance wise very quickly, x86 CPUs less so, so what is really being tested is how fast can a cpu jump from idle to full speed.

Geekbench is not at all a reliable benchmark that tells you anything about real preformance.

Its a total farce to suggest that a CPU with a power budget that is 10x to 20x larger, on a modern process, with modern archtecture is somehow just as fast or slower.

Intel is dragging 40 years of legacy along. I’m not so sure a new processor can’t be faster and less wasteful of battery power.

Indeed, we have every indication that Apple can already do both of these things. Go look at Geekbench 4 single-core scores for the current iPhone and iPad vs. the current MacBook Pro. Apple is already beating Intel on speed in a design that uses MUCH less power.

I guess that Apple would have the resources and knowledge to create an extended ARM architecture that could match x64 in the same power envelope, if they really really wanted.

The market segment isn't that large though so it seems tough to get it done within the laptop budget. Still, it could benefit the other devices and streamline the hardware development, so maybe they think it's worthwhile.

But what -- and work with me here -- if the processor is slimmer. With rounded corners.

> until developers can recompile?

Will it be that simple? Apple's own Logic Pro ships with a lot of legacy products from Emagic days. I know they've re-skinned a few with the last couple releases, but I'm guessing a lot of the DSP code is still the same.

Creatives who want hardware optimized Adobe apps to continue to be fast will care. I wouldn't count on emulation of vectorized code to work all that well.

Yep, I think people tend to gloss over how smooth these transitions really were. From a creative professional perspective, they were huge short-term PITA until Adobe etc had everything ported over. Also Excel lost VBA support for several years.

I remember everything audio was a mess although I'd imagine a lot of it had to do with smaller developers lacking resources to port existing software.

Losing VBA support stinks, but do any professional Excel users even consider Office for Mac?

At least for me "professional Excel users" sent out stuff that I could not open, and that is not good for the for the platform.

"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008. , (Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.

No, I get it. I just think that, in general, people who spend a big chunk of most of their work days using Excel kind of consider anything other than Windows MS Office Excel a non-starter.

Adobe's transition was somewhat rough because they took the Carbon route, and then had to do it again to switch over to Cocoa. I expect that now that all their apps are built on Cocoa, the transition will be relatively breezy.

emulating x86 on ARM with any kind of real preformanceis additionally tricky because the x86 archetechure has very strong memory gaurentees (dosent matter if memory is aligned, dosent matter when in the instruction pipeline you access it, etc) that ARM isnt even close to matching.

Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.

From what I've heard, x86 to PPC or ARM emulators are doing dynamic recompiling and instrumentation. It catches the illegal memory accesses and rebuilds the code responsible to add paths with slower code with alignment compensation.

A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.

…or you design your own ARM CPU that handles unaligned memory accesses fine, and run your emulator on that hardware.

AFAIK the ARM license doesn't allow to invent arbitrary extensions to the ISA. So this might not be allowed.

Apple has an architectural license. I would expect that allows them to add instructions (assuming modern ARM still has the concept of instruction set extensions)

Google didn’t answer that for me, but I found out that there now is a ”cp15 sctlr[1] (alignment bit)”. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... says this about it:

”3.5.1. Alignment faults

If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”

I thought the emulation only covered x86 not x86_64 because patents still cover 64 bit x86. Would that be more or less of an issue for Apple

As much as Apple made a big deal marketing "Rosetta", behind the scenes it was a product from Transitive called QuickTransit. QuickTransit is gone now, absorbed by IBM. In comparison the 68k to PowerPC emulation was very primitive and slow and mostly appeared to work because of how unbelievably slow 68ks were vs PPC.