I was interested by the GPU that was mentioned in the slide, does this mean that Apple is thinking that they have the expertise to take on Nvidia and AMD in that space?
Whether or not they think that or they can, they have been developing GPUs for iOS devices. It'll be interesting to see what they do for their desktops.
I agree. I know they're currently using AMD GPUs, but how much longer will they keep using AMD if they believe that their own in house chips can do a better job? Also, I'm curious as to whether they would try to sell their GPUs (iGPU?) to gamers who traditionally don't stay within the Mac ecosystem at all. Having a 3rd major player in the GPU space would be wild.
The advantage Apple has is that Nvidia and AMD and Intel have to actually make money from their chips. Apple can break even or make a loss on the chips themselves.
I don't mean in pricing, but design. Other companies have to design chips that make sense in the market. Apple makes it for themselves, and they can make chips that would not make financial sense, but perform great.
And charge you a bunch for the whole package, of course.
Given the lackluster support Apple has for the AMD GPUs they currently ship I bet it will feel like an upgrade. Plus a lot of the product line uses the integrated Intel graphics so beating that isn't much of a challenge.
I'm curious about the future, especially games, if they want to take on consoles.
PS4 and XboxOne are 7 years old and while the next gen looks really good Apple can refresh the productline much quicker (on the other hand it's a good question if people really would want to buy a new console say every year because Apple sure will be aggressive pushing out new models much more frequently)
macOS's gaming story has always been pretty abysmal. They nuked a ton of games when they dropped 32-bit support, and they refuse to implement the graphics API that the gaming industry is standardizing around. I don't foresee any improvements in Mac gaming from this announcement.
> But now games like Fortnite, Minecraft, PUBG etc. that already exist on iOS can natively run on the Mac. So I think that's a pretty big thing
With touch controls on non-touchscreen devices.
It isn't big.
I think the fact they chose to show off a fairly poorly running version of Tomb Raider as their demo goes to show that they still fundamentally do not understand the gaming market.
I wonder if this is actually even related to the original Rosetta (which was actually an external vendor - QuickTransit by Transitive), acquired by IBM. Most of the Transitive team left IBM to go to Arm and Apple.
It may be to avoid appearing to be misleading. They'll almost certainly be able to virtualize ARM-based Windows, but that's not what normal users are looking for when they want to virtualize Windows.
Keep in mind that current macOS runs ONLY 64-bit x86 apps and interestingly Windows on ARM emulates ONLY 32-bit apps. Since 64-bit extensions were designed by AMD, maybe they have some deal with them?
Perhaps it's just to temper expectations then. If the performance or user experience isn't comparable to what today's users expect, it's probably better not to celebrate that use case.
I used Parallels for a while, and it was great, but then we kind of standardized on VirtualBox at work. It was okay.
But then our dev environments got too big to run on laptops, so now they're all cloud-hosted VMs. We still run Docker (which uses a VM under the covers for Mac) but that uses Apple's Hypervisor framework and isn't really "user-facing" virtualization.
Especially – and funnily enough – in business contexts, where you need to run software which are each only available on either Mac or Windows, but not both.
Do you have any examples? I was running VMWare Fusion until about 2015 for my office laptop for Visio and Project, at which point I felt no need on my next refresh to simply not request it due to cloud-based alternatives.
Yes, the NURBS (surface) modeler "Rhino" is one – or rather was; meanwhile it got a Mac version, but that one still has no feature parity, so you would still see this running in Parallels somewhere, I guess.
Indeed - and I'm hoping they give some more details about that, whether it's ARM only virtualisation, or if their Rosetta 2 also supports x86 virtualisation.
I noticed that too. Might have trademark or legal reasons though. Technically, if they're able to dynamically translate x86 to ARM as they've explicitly stated (with JIT of JS and the JVM as the example) they should be able to dynamically translate x86 VMs regardless of what OS they contain, which would allow x86 Windows to be virtualized with better-than-interpreted performance.
Or at least that's what I hope ;-) I'm relying on running x86 Windows and Linux within Parallels in addition to native MacOS Apps to do my daily work, which involves compiling and testing x86 binaries for these platforms, so whether this virtualization thing actually runs x86 OSes transparently is an absolute make-or-break feature for me to continue my usage of the MacOS platform for work.
I don’t think that would perform very well without some hardware support for it as well. Not an expert on this by any stretch but as I understand it modern virtualization is almost always hardware accelerated which I can’t imagine is a viable option if you’re translating the binaries with Rosetta.
Hoping there's a way to switch to a more compact view, but as shown in the keynote it looks terrible. What is with the insistence on wasting space in modern operating systems? Were people getting too productive with new, large displays?
Also interesting that the dev kits use the same chip as the latest iPad Pros (A12Z). I’d love to see the two OSes merge to some extent because I love writing on the tablet but find iPadOS not the best for general dev work.
Oh, 1,000%. Even basic tasks like working on a file, then pasting said file to a cloud storage app and then to an email/slack channel take an order of magnitude longer than it would on a computer. Long way to go before the iPad becomes a true Pro machine, but for some fields, it's basically there. Still, such simple quality of life improves that are mainstay/muscle memory on computers essentially take time and animations and taps to execute.
Already Apple is making it a headache to run non-signed apps on the Mac. I don't think they're going to slow down the "convergence" of iOS and MacOS at this point.
It was very odd seeing Lara walk through an area with dappled bright light, and her body remain uniformly lit. It may be that the game has a very basic lighting engine though.
It is like many triple A games in that it has a wide range of settings, all the way from full potato to RTX (it was ironically one of the first games to support that).
Again, people need to dial back their expectations here. You aren't going to see cutting edge games running well through emulation. There is a reason Apple made such a huge emphasis on native apps, native is always going to run much faster.
They didn't demo gaming to suggest this is a great machine for gaming, they demoed it to show that it was possible at all. The previous version of Rosetta during the PowerPC->Intel transition was not known for performance.
If gaming is important to you and you want a Mac then you want an Intel Mac or whatever games are released for Mac ARM. Emulated games are not going to compete with native.
But does it run better than on the current intel mac mini with integrated graphics? All it needs to do is beat intel in comparable circumstances.
It doesn't really matter what the graphics performance is, on high end macs they'll still ship a dedicated GPU from AMD. What matters is that the game is GPU-limited instead of CPU-limited.
The maxed out mac mini cpu is a 6 core 3.2Ghz i7 with turbo boost to 4.6Ghz. I wonder if they can beat that with a newly ARM optimized MacOS? The current i7 has tons of power still as an 8th gen Intel cpu.
> But does it run better than on the current intel mac mini with integrated graphics? All it needs to do is beat intel in comparable circumstances.
Having gone and checked, no. Not even close.
(Nor would it be plausible to expect to. But it's clear Apple have made a choice here, and that is that if you're a user who wants legacy software or desktop gaming, Apple do not care about you compared to their margins. It's that simple.)
It’s not about the game, it’s about running performance-dependent code written for x86 on an ARM chip. A lot harder to fake a stable frame rate in a game than in Photoshop.
I think your expectations for what emulation is capable of are set a bit high. The fact that it is able to emulate a game that's a few years old at decent frame rate is more than acceptable. You didn't see Microsoft demoing games for their Surface on ARM systems at all and for good reason.
I mean, if I had things my way they wouldn't be switching to ARM at all and emulation wouldn't be necessary, so I don't think it's wrong to be skeptical.
> You didn't see Microsoft demoing games for their Surface on ARM systems at all and for good reason.
Those were also lower-end computers with poor GPUs.
> I'm going to assume that a dedicated GPU was being used for Tomb Raider—they would have said something otherwise.
They said exactly what SoC they were using, and it's not known to have spare PCIe lanes lying unused in existing products. Apple pretty much just demoed an x86 game running on an overclocked iPad Pro.
It's not like Apple can't change what connectors are available on the back of the mac Mini. The form factor may not have changed, but the ports available have in the past releases.
Don't be surprised if there is no Thunderbolt 3 at all, but just USB-C.
It may be that by the time these things are ready for an actual release they can be USB4, which is USB-C + Thunderbolt technology, but no longer Intel exclusive.
They only said the demos were running off Apple silicon, not that they were running off a Mac Mini DTK machine.
They probably have other systems more akin to Mac Pros that they use internally.
> Those were also lower-end computers with poor GPUs.
Were you under the impression this $500 developers kit shipping with an iPad Pro CPU/ GPU is a high end computer? While it's a decent chip, it's essentially the same CPU as the prior generation iPad Pro with 1 additional core.
Shadow of the Tomb Raider is a PS4/XB1 game, not a PS360 game.
---
Edit 2: Please disregard my first edit, below—I was right the first time, then I got the games mixed up.
Edit 1: Oh wait, I forgot, SotTR actually did have an Xbox 360 port! It was one of the last big titles to have one. I think what they showed on screen looked better than the 360 version though, although it's admittedly hard to tell on a stream.
Is the target to match the performance of ten year old hardware? Then sure, that's matched. But it's not impressive. AMD FX CPUs have better performance than that, by a mile.
Yeah, but this is their existing CPU/GPU designed to fit into the constraints of the iPad form factor. They'll likely have something much more powerful for consumer hardware.
The iPad CPU/GPU is already thermal limited. An unlimited A12Z is right at the TDP of a laptop chip, at ~25-30W (5W per big core per anandtech, 4 cores, plus GPU and I/O, it's actually quite a generous estimate.
An unlocked A12Z is likely all you can get away with in a laptop, and inferior to SOTA x86 low power CPUs.
If the Tomb Raider game was actually running on a A12Z system (without any external GPU - note that this is the same CPU/GPU on the iPad Pro!), then that demo is actually really impressive, even if the game settings are set to low-quality and the framerate is a bit choppy.
On the other hand, it probably doesn't use much CPU just because it's single threaded. No game ever uses more than 10% of my 16-thread CPU. But that also means that emulation could seriously tank single-thread performance and ruin the game.
It might be the other way around. The might have gotten around the big issue with running arbitrary x86 code on ARM (the way weaker memory model) by pinning all x86 threads in a process to a single core. Which would be unfortunate.
Besides native apps from Apple, Microsoft, and Adobe (Universal 2), the demo included Maya and Shadow of the Tomb Raider (Rosetta 2), and Parallels Desktop (unspecified virtualization improvements). I couldn't tell if the guest O/S was Debian for x84-64 or Aarch64.
One of the About This Mac dialogs showed an A12Z with 16 GB, which is consistent with the developer transition kit, basically an iPad Pro in a Mac mini case: A12Z, 16 GB, 512 GB SSD.
And I reckon those of us who just bought a shiny new Intel Mac in the past few months might be questioning our decision. Should have held on to that 2010 MBP one more year?
Typing this on a 2010 MBP, bought a new MBP this weekend (was later canceled by the seller b/c of inventory issues) and thinking about waiting another year
Buying a Mac right now, need to replace my EOL Mac Pro. I definitely won't be getting a Pro now. Probably just an iMac with more RAM and SSD instead of Fusion. I really wish I knew when they were updating their iMac and Mac Pro lines.
Remember the MacBook Pro with a DVD drive lived on for years after all its siblings were discontinued. We can expect some x86 support to remain available for years after the last new ARM machine is launched.
I think that's the mid-2012 MBP? They were still selling them in 2015, I bought one of the last ones before it was pulled from sale. It remained in the lineup because it continued to be a best-seller.
Apple was already grumpy about servicing it by 2018 or so though, even with AppleCare. (I've switched to Windows now.)
I think it could be tied to large contracts and ensured availability. I suspect there will be an x86-based Mac available well past the two year transition that was announced.
What is really sad is that I don't think the majority of Apple consumers really understand what this means for the Intel macs in the long run. I fear a number of people will buy them not realizing they have a very limited lifespan.
If those devices will have 4-5 years worth of use, then I think most people would be fine with the purchase. 4-5 years already does require upgrading for either performance or quality of life features.
Part of the motivation for the transition is the hope that the progress will be much faster over the next 6. If that happens, those intel macs may age out sooner.
They won't, necessarily. Fat binaries worked ok the last time around. Sure, Apple could stop making updates available for Intel Macs, but they can stop making updates available for any older model of Mac if they want to.
> […] not realizing they have a very limited lifespan.
It may depend on one's definition of "limited": the Rosetta was first released with Mac OS 10.4 in 2005, [1][2] and was last available in Mac OS 10.6, which first released in 2010, [3] but whose last update was in 2011.
Six years of transitional support is not unreasonable.
I wouldn't be so sure, there are a fair number of people who want a machine that will run x86 for various reasons. Windows support/ Linux support. Even considering how impressive x86 VMs looked in the demo, lots of people will prefer using intel silicon for guaranteed compatibility.
The end goal isn't just using Windows for Windows sake, the reason people use Windows on mac hardware is to get access to apps that run on Windows. And most of those apps still run like garbage (if at all) on the ARM versions of Windows.
They showed Maya (x86 binary) running on their Chip. It has some ability to run intel binaries on Apple silicon through at least two options-emulation and something that sounds like “jit interpretations”-lack of a better word.
I think that is a slightly different use case, though. That demo was an x86 binary running on ARM MacOS via a translation layer. So if there is a MacOS x86 version of the app you want to run, that might be an option.
But I know a lot of people still run Windows because they want the Windows version of an app, either because it isn't available at all on Mac or just because the Windows version runs better (Excel was a classic example of this for a long time, might still be). In that case, I don't know if that same translation layer will have the same performance (if it can run at all outside of MacOS) when running an entirely different OS.
FWIW I remember running PowerPC binaries on Intel macs via Rosetta was pretty painless. They mentioned explicit support for linux/windows emulation so they know it’s an important use case.
I think this is called "transpiling" -- a version of compiling that's mainly translating from another architecture. And it didn't sound from their description like it was JIT -- it sounded like it would do the transpile when you first installed it (or maybe first ran it?) and keep the results.
Transpiling (as much as I hate that word, because the more you know about compilers, the more meaningless it is), is about source to source translations, not binary translation.
And they have a first pass AOT, with a JIT backup from the sounds of it to support JITs like browsers, node, and java.
Like, a joke version of Windows, yes. As a developer, if my machine can't run Visual Studio then it's not interesting to me at all. I can see it being acceptable to people who work predominantly with tools that have an ARM binary though.
Visual studio code has an arm build now [0]. I don't know what regular VS is written on but assuming it's .NET framework I assume a build will show up as the framework itself improves on ARM.
I known in 2010 the Visual Studio UI was rewritten in WPF/CSharp, I don't know which UI system they are using in 2019. It is documented in the wiki entry and a few blog posts MS made.
VSCodium works great on ARM64, I was testing it last week when I tried doing some dev work from a Raspberry Pi running the beta 64-bit OS: https://github.com/VSCodium/vscodium
...and we need new, more hardware for CI/CD that's just dedicated for Apple OSes. Pretty sure we won't be able to use the 5 unused raspberry pi we have.
I found the same problem when I tried running off Pi OS 64-bit for a day—almost every app that _did_ have a Linux binary available was only able to run under x86_64, not on arm64... More here: https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook...
Zoom, Bluejeans, Dropbox, pretty much all the popular apps I used where I could find a Linux version for my Dell laptop, I couldn't find a way (though got close at least, with Dropbox) to run them on an ARM64 CPU.
For Dropbox, you could quite trivially get by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.
Have you tried box86? https://github.com/ptitSeb/box86 Let's you run x86 (not x86_64 though) programs on ARM Linux. It does a neat thing where system library calls are converted to ARM system library calls rather than using x86 ones for better performance.
I am – right now even – but I agree it's become impractical.
This announcement is the final nail in the coffin I suppose. I hope some company will come out with great quality, well-designed, minimal laptops. That run Linux perfectly.
If it ran Linux perfectly, it could only do so if the manufacturer maintained its own Linux distribution. Laptop hardware and power management is just too complicated these days for anything else to work well.
Unless the new ARM chips can handle VirtualBox well, I’ll pick up the last intel model. I have to work with old ASP apps in IE VMs side-by-side with stuff on my Mac every day.
I know, that’s why I run it in compatibility mode in a VM. Just because it’s dead, doesn’t mean there aren’t organizations that have built mission critical web apps that only work in IE and those of us who have the burden of dealing with them.
Dunno. The free Windows VMs I have saved can be reloaded in VirtualBox and used pretty much forever. They can’t run any serious software very well (on my old MacBook anyway), but I’m just using them to support some legacy web apps.
I don't think there's a way to have a licensed Windows ARM copy right now on arbitrary hardware. I thought they only provided OEM versions on certified hardware.
> Yeah, the fact that they didn't show off Windows, but instead Debian of all things, was very telling.
I suspect developers running VMs with Linux on them is far more common than developers running Windows VMs. Likely by an order of magnitude. Web developers want Linux VMs, Windows developer have Windows laptops.
You'd be surprised. It was the only option for those writing native apps to have a platform that could legally run all of your tooling if you shipped Mac/Windows/Linux.
But given the amount of time they talked about how large a part native apps play into the transitions, an extremely strategically important segment for them.
Additionally, there's the Android/iOS crowd in the same boat, where emulation of non x86 in Android dev is pretty limited (but I can see that being rectified with the newer virtualization extensions).
I could see the "final Intel Macs" having a value to folks; somewhat similar to the 2015 Macbook Pros which many considered the "last good Macbooks" before Apple fumbled things with the 2016-onward Macs and their gimpy keyboards.
In this case, I don't think the first ARM Macs will have undesirable hardware ala the first few years of Touchbar Macs, but there will be some straggler software whose ARM ports will be delayed or will never happen. For those who depend upon that software, the final Intel Macs will be invaluable.
I'm in the market for a new laptop, and if I knew how long the Intel macs would be supported, I could see myself picking one up. Unfortunately, nothing was said about that so I guess I'm holding off.
Disagree. He said Intel Macs would be supported for "years to come" and that they had more in the pipeline. They'll be supported for significantly longer than 2 years.
I was waiting for Craig to say that every Mac with a T-series chip could be used as a dev platform, since they're pretty strong on their own. Oh well. Maybe to smooth things over they'll ship an A-series co-processor with those Macs.
Apple released a bunch of PPC Macs after they announced the switch to Intel, so this isn't unprecedented.
Do you think most people know who makes the CPU inside their Apple machine? Go into an Apple store and take a survey. I almost guarantee no one will know.
If the PowerPC to Intel transition was any indication, they'll do just fine. Most consumers won't care, or will want to wait until Apple works out the kinks.
To put it a different way: the initial sales of the ARM-based chips won't be as strong as you think they might be, or as wide spread.
Having both Intel and ARM based systems in the market will even out the sales.
History is repeating itself, it's worth reviewing the previous transitions before making assumptions.
With the powerpc to x86 transition Apple was moving towards where everyone else already was. It was one less thing developers had to worry about when supporting Mac. With this migration it's the opposite, and MacOS is still a very small slice of the desktop/laptop market.
I’m pretty sure their point is that last time, the incentives/burden was more aligned between Apple and soptware producers, because it meant devs had one LESS architecture they had to care about. This time they will have one MORE, and it could very well be an architecture they have no familiarity with. And Apple isn’t exactly known for their technical documentation of new platforms.
I don't know that it's one more platform. I mean, sure, it's not exactly an iPhone, a Pine 64, a Raspberry Pi, or a tablet. It is, however, a very broadly supported processor family. More and more support is coming out for ARM all the time. If you're targeting desktop and anything smaller (phones, tablets, watches, SBCs, smart home devices) then the something smaller if it's bigger than an Arduino is probably ARM.
I think quite a few developers would be happy to use the same basic software stack on on a phone app and a laptop app.
If I'm making a professional desktop app like Blender or whatever, then right now I only need to worry about x86 SIMD optimizations & behaviors. I don't care about iPhone/iPad/Raspberry Pi performance. I may care that it works, because why not? But I don't care about optimizing for it.
Now, though, suddenly I need to figure out how NEON works if I want to continue to support professional users on MacOS. I need to increase my hardware costs to ensure adequate test coverage. I need to use something other than Intel's glorious VTune for profiling & optimization. When I'm step-debugging my C++ or assembly tight-loops, I need to know double the amount of assembly than I do today. I need to learn ARM's memory model & cache behaviors.
If I'm just writing some silly native app that could have been a website as is trendy then yeah this is all no big deal, who cares? But if you're really pushing professional app boundaries, where time is money? That's a different story.
Many things in the world of software are neither webapps nor contain a lot of highly optimized hand-written assembly. That's the worst false dichotomy I've read so far today, and I read political Twitter.
Just because your use case is different from those who have C or C++ code and a good optimizing compiler doesn't mean you need to disparage every other type of developer on the planet.
There are a lot of people who write native ARM for phones and tablets for performance purposes, too. Some of them get down into ARM assembly. If they port to Intel and want to do assembly-level things there, they need to learn twice as much assembly coming the other direction.
It depends on where your perception of "where everyone else already was" in this context.
Is the future more like Intel desktops or more like ARM-based mobile devices? If you think the latter then Apple is definitely moving towards where people will be (insert Gretzky quote: "skate to where the puck is going to be, not to where it has been.)
I remember Apple's m68k to PowerPC transition. Platform changes were a much bigger deal back then because it determined what kinds of apps you could run, but even so it went without a hitch. We lived with fat binaries for a while but otherwise it wasn't a big deal.
Apple's focus has always been the consumer market, and for most consumers, they're not likely to notice the platform change.
One might say, Apple gained a huge developer demographic when it moved to x64 from PowerPC, won't this matter to them? But most of those developers were creative types that don't work at the binary level anyway. If you're doing front-end web dev on VS Code and almost never fire up gcc/clang, your life isn't going to be impacted significantly.
Those whose lives were impacted (e.g. scientific computing folks who struggled to get certain Linux-specific software to compile on what was a BSD-ish platform) have probably moved off the Apple platform and on to Intel Linux years ago or at least they're likely to be running a Linux VM on their Macbook Pros. (homebrew doesn't really cut it)
Also unlike back in the day when most people were still running desktop apps, so much of what we do on a daily basis is on the browser nowadays. Calendar? Cloud-based. Email? Cloud-based. Word processor/spreadsheet/presentation? Cloud-based -- and Microsoft Office is being ported to ARM. We're living in much more platform-agnostic world than we were even 10 years ago.
I expect the x64 to ARM transition to be seamless to most people who are currently on the macOS platform.
A bunch of Python wheels might need to be recompiled though.
> I expect the x64 to ARM transition to be seamless to most people who are currently on the macOS platform.
I completely agree with you IF Apple contains this to just the Macbook market. If they push this to iMac Pro / Mac Pro, too, though? Or even Macbook Pro? That's a different story. For developers it probably won't matter much, but for users currently relying on things like Protools to make a living? There's a good chance this won't be a friendly transition to them in the short term.
The pro tools (like Pro Tools) are usually the tools that are being ported first. It was the same with all the other transitions.
If not, there will be Universal 2 binaries with both x64/Intel binaries for a while and an emulation mode for legacy binaries. Underoptimized at first? Maybe, but they work well enough and performance catches up eventually -- the transition is over 2 years. Same situation as before. Software that work will continue to work on existing and new hardware for a while. Nothing is going to stop working the moment the new processors come out.
We've seen all this happen before (m68k - PowerPC - Intel). And it's really not a problem.
Maybe it depends on the pricing for the x86 vs. ARM macs. If the ARM machines are significantly cheaper the x86 sales will probably suffer quite a bit. As someone else in this thread said, most people have no idea what processor is in their computer. They just care that it's cheaper and runs all of their stuff (browsers, photos, messages, etc.)
The Mac Pro (and possibly the iMac Pro) will still be Intel for a while. I expect the portable lineups to get the ARM treatment first (as they are the most similar with the iPhone/iPad in terms of power requirements), and then scale it up for actual high-power desktop CPUs.
Apple could continue to ship arm/x86 machines in parallel for years if the fat binaries+emulation work well. If say the desktop mac pro maintains an edge somehow, or Intel comes back from their current slump in 5 years this could go on indefinitely.
(that probably totally depends on whether Intel actually designs a desktop chip for the first time in nearly two decades, rather than continuing with their current sell server chips as poorly designed desktops path)
On the contrary, I'm tempted to buy the latest Intel Macbook Pro so I can stick with Intel for a few more years. Whether or not I'll end up doing so depends a lot on how good the new ARM-based laptops are in terms of performance (esp. wrt virtualizing x86/x64 VMs). But the current lineup, however imperfect, is mature and a known quantity, in contrast to the unknowns surrounding the first generation of machines with the new architecture.
They said the same with the Intel transition, and also projected a two year timeline. The transition was over much sooner than that and there weren't any new PPC products to speak of, as far as I remember. And of course, PPC Macs only got one more version of OS X before support for them was dropped.
They're just trying not to Osbourne themselves too badly. They want you to keep buying Intel Macs, but who's to say how long they'll keep support.
PPC was complicated by coming after years of failing to have decent chips actually ship. In this case, Intel and AMD are both still heavily invested in pushing x86 forward and Apple doesn’t have to do all of the work maintaining things like compilers or the JVM so it’d be a lot easier to keep that option alive if there was a good enough reason.
Different segmentation - Qualcomm powered laptops are the weakest ultrabooks, compared to Macbook Pros. I really wish Qualcomm chips were better though.
Nobody gives a crap about the Qualcomm powered notebooks. They're a joke market segment. As long as Apple doesn't start selling A* chips to Samsung or other Android OEMs Qualcomm isn't going to worry.
> As long as Apple doesn't start selling A* chips to Samsung or other Android OEMs Qualcomm isn't going to worry
Even if Apple did sell their chips to other parties, Qualcomm will be still collecting its sweet patent royalty from both parties, so it couldn't care less.
The patent royalties are fairly small compared to selling a full chip. They would still be feeling the pinch.
Of course even if Apple did start selling those chips (which they won't) they would charge an arm and a leg for them, because they could. They would only be used in the top of the line flagship phones. Apple has shown zero interest in competing with the bargain basement hardware producers.
Yes, and then you ‘upgraded’ the OS and gratuitously stopped running older software. My final Mac Pro — yes, I was a buyer of Mac Pro grade hardware — still runs 10.6.8 for that reason.
And you most likely will have to be an established developer, meaning you’ll have to have an app in the App Store. Apple’s not gonna give these to people that just want to play around with a new machine.
"Submit a brief application for an opportunity to join the program. Selected developers will receive a link to order the Universal App Quick Start Program from the online Apple Store. Priority will be given to applicants with an existing macOS application, as availability is limited."
If it's like the switch to Intel then it will be $999 and you have to return it when the real versions come out but you'll get a replacement with one of those real versions. Except with the Intel switch you were shipped a slightly repackaged beige box... and that was 15 years ago so my guess is $1499.
I was seriously considering upgrading my 2012 MacBook to the new 16" model soon, but now I wonder what kind of longevity or support I can expect from that hardware...
I just got a 16" MBP...
Still, the waiting game sucks too. Apple said their first Arm mac will come out at the end of the year, but that could well be a very low end Mac mini, or Macbook Air. It's unknown when the pro line will come out.
That might explain why all but the top line version of the barely-refreshed 13+ MacBook Pro are missing Intel's 10th-gen processors.
Sandbag the upgrade for the 13" so it's not that desirable and you won't cannibalize your own demand for the release of the first Apple Silicon machine
Given Apple's track record of supporting older Mac hardware, I would expect Intel Mac hardware to be supported for many years and many OS versions after the last Intel Mac has been produced.
Also given Apple's recent MacBook track record, the first version of ARM Macs may not be as much of a slam dunk as people hope.
Which track record are you talking about? Apple discontinued OS support for PPC only 3 years after intel was announced. That means no more support for xcode and new commandline tools after 3.5 years.
I think we’ve got some time. I’m on the last leg of a 2012 too. Just like the sibling comment said, since we don’t know if the pro line will get a refresh there could possibly be a longer runway.
My personal philosophy is to buy the third gen of every new type of product. The second gen tends to fix al big issues in the first. The third irons out all the small issues left. After that there probably won't be many changes except for some performance bumps.
I wonder what this will do to Electron. If the iOS apps are really 1:1 on macOS, then the need to maintain an electron app will probably diminish. As long as they both support the same OS APIs I can see devs that can learn a new language (Swift) ditch Electron.
Eh, Catalyst apps are as good or bad as the developer wants them to be. Voice Memos and "Find My" on the Mac are two fantastic Catalyst apps, and certainly better than Electron.
Anyways Catalyst won't even be relevant in the long term, once iPhone apps are written in SwiftUI
I often close the Twitter app and Apple's news and stock apps on my Mac mini because the performance is terrible. Hoping they've spent time tuning this more.
Catalyst and SwiftUI are (were?) very immature technologies, not yet ideal for production software. I'd imagine that we're at least a year out from seeing real SwiftUI software in the wild.
I'd wager for a significant amount of shops it's less about cross-platform support and more for being able to throw existing generalist or web frontend developers into native development. If a business wants to ship a desktop app quickly, it's hard to argue against electron because your existing teams can become productive without too much training.
Electron already has support for ARM64, but no official releases yet. But it needs to be build from x86 machine. No native compilation on ARM64 yet. I think with apple moving to ARM, google will add native ARM64 compilation for chromium. This in turn will be picked by electron. Chromium has been running on ARM for a long time with Android and Chrome OS so it has all the optimizations.
Apple had a list at the State of the Union of open source technology projects they had built pull requests for to add ARM support. Electron was up there, as was Python 3, OpenJDK and Go, notably.
I am soo much looking forward to using native Slack and Teams instead of their horrendous electron apps, that even don't use GPU acceleration on iGPU Macbooks!
There's gonna be a weird moment soon where developing docker images for Armbian hardware (Pi and friends) is going to be more straightforward on a Mac than developing docker images for Intel servers.
I wonder what sort of involvement ARM server vendors could be offering during this period. I don't expect Apple 'needs' anything from them, but there might be some Docker work they could be jumping on.
Also Apple is committing to a long term pipeline of Intel chips. This makes sense since so many apps will take years to transition. At the same time, they're willing to put their own chips side by side with Intel and they believe people will voluntarily switch. I'm looking forward to the benchmarks.
If the performance in the demo is accurate, and considering that the actual Mac chips will have a lot bigger power headroom, silicon die size and more thermal headrooms than the A12Z, Intel will be swatted out.
So, if I install numpy via conda on a Mac now, it's backed by Intel MKL and is thus amazingly fast. What will it be replaced with? Has anyone at Apple thought about use cases like this?..
This isn't just about hardware. It's about software, and an investment in making libraries that are fully optimized for the hardware. The problem here is the long tail of needs is very, very long.
I bet that they already have some low-level math library that uses ARM NEON intrinsics; you would definitely need them to port performance-demanding apps like Final Cut Pro / Maya / Photoshop / etc.
I'm not a developer myself, but When I engaging with them on various OSS projects I always feel Windows is being treated as a second class citizen in almost every aspect (smaller projects often has no test, tool chain setup, tutorial, or all of above for Windows, as a starter).
numpy is backed by BLAS and LAPACK. It just happens that on your system on macOS those libraries are provided my MKL. There are other implementations of BLAS and LAPACK out there.
SciPy did support Accelerate, but they dropped it in 2018 because Apple’s implementation of LAPACK was so out of date. Apple have been crap at updating this stuff which is why people don’t use it.
In the Platforms State of the Union, they specifically listed Numpy as one of the open source projects that they built for Apple Silicon (along with Python 3 and others). Go to 20 minutes and 35 seconds on that video.
Well, that new MBP I bought 4 weeks ago and planned to keep for 5 years just got a muuuuch shorter life span if I can run iOS apps on an Arm Mac, my wife is going to be livid.
I guess this also means Catalyst’s life span is pretty short and SwiftUI will becomes the focus?
I'd be surprised if the iOS apps did not work on Intel based macOS. Project Catalyst already works on Intel macs and my guess is many iOS apps have been migrated already.
I'm sure there will be emulators. But I'm also fairly confident that they'll be relatively slow. Emulating across architectures is rarely performant, and if Apple had solved the problem they would be talking a lot about it right now. In the past they've gotten away with this because the architecture they're moving to was so much faster than the previous architecture that even with a 50% or 75% performance penalty the apps would run faster than they did on the old hardware. With this new hardware it is likely only going to be marginally faster than the old Intel chips since the focus is more on power efficiency, so emulated apps are probably going to feel sluggish.
The difference is that the entire (64bit?) iOS App Store back catalogue would likely be available to run as unmodified binaries without developers having to lift a finger.
Is it just me or did apple just bungle this entire announcement by not announcing a consumer facing ARM MacOS device, only a hot-rodded Mac Mini with an iPad Pro chip inside.
How many devs actually have the setup in place to use a non mobile device?
I also wonder if the current+last gen iPad Pro that has the new keyboard + trackpad case will gain the ability to run Xcode and native macOS apps in the near future.
Native virtualization and the ability to run iPhone and iPad apps directly on the Mac. This could unlock a whole new level of focus and optimizations for Apple.
Will BootCamp continue to be supported for the next ten years on my June 2019 MacBook Pro so I can install an operating system that continues to develop new features with the assumption I'm running on x86-64?
What do you mean by "continue to be supported"? Your 2019 MBP will only need new drivers for Windows if Microsoft decides to change things. Otherwise, Apple doesn't have to do anything at all for your current MBP to continue to be able to run Windows. While Windows may be something of a moving target, your particular machine isn't.
I mean, there's nothing too magical about boot camp—even if apple removed all support for it from macOS, you can probably install windows on a partition the normal way without too much trouble. I think the only thing that might break is if Windows stopped being compatible with the Mac hardware drivers, and Apple didn't update them.
"What would keep Apple from shipping machines with both ARM and Intel CPUs in them? The ARM CPU would run the OS and decide when to ship jobs over to the Intel CPU. I can’t imagine that the home-grown ARM CPU would add much to the total price of the computer."
It is a lot of work and now you have to buy two CPUs. No cost savings, possibly more power usage in worst case, and maybe even thicker computers.
It would restrict it so you can never remove the Intel CPU. It is best to just emulate the Intel CPU for a while until everyone ports their code across.
Ah. I saw references to "dual architecture" online but looks like that means Apple will be releasing new Intel machines even as they are encouraging everyone to port their apps to ARM. The "dual" part just means two different lines of machines that will be sold contemporaneously for a little while, not two architectures inside one machine.
This level of asymmetric processing is very difficult to achieve, at nearly every possible level, from part sourcing, through hardware design, firmware, software to user experience.
Well, in theory both AMD and ARM use MOESI so it's not as crazy as it would be with Intel's MESIF. But that's a really scary rabbit hole to be going down and I'd be terrified of memory permissions attacks striking at the boundary there. So probably not worth the risk unless each processor gets its own pool of RAM.
Rosetta 2 - the interesting bit was that it was going to pre-translate binaries instead of at runtime. The implications for actual VM emulation is that Rosetta won't work for run time environments like OS emulation. They touched on it briefly with the emulation technologies bit, but it looks like it will be separate from, and likely much less performant than Rosetta.
The emulation thing seemed to me to be Hypervisor.framework for ARM, as they showed Linux and Docker running (which both run on ARM), but not Windows (which an average user may be more interested in).
They explicitly said that it can perform both static and dynamic translation for JITs. I wouldn't be surprised if there is substantial hardware support too.
I was wondering why did they mention the virtualization. Let's see what technology do they use. Whether it is going to be proprietary or something like Xen.
I meant that it supports dynamic translation in order to support JITs such as turbofan.
But to answer your question, yes a JIT can be static. JIT just means that the compilation happens at runtime, and "static" in this context means that the compilation is happening at the very start of runtime. You could imagine a JIT that compiles all bytecode to native code immediately on launch. The reason this technique is not used often is that it tends to lead to long startup times. But if the result is cached somewhere then it might be acceptable.
Good time for anyone who was using macOS for gaming or anything else for that matter to switch to Linux. OpenGL bit rot, refusal to support Vulkan, dropping of 32-bit, dropping of x86_64 architecture - all that should have been a hint. Backwards compatibility is not even an option there (besides for emulation).
I started using MacBooks when they switched to Intel around 2008. Maybe this is a sign to move on. Currently using a mid 2014 model, I like the slim form factor, but I don't like the absence of an ethernet port. I don't care much for the retina display, my 2008 matte model was better. Been looking at the Lenovo T470. I need something that would be easy to replace quickly anywhere in the world. What should I get?
Lenovo Thinkpad laptops are pretty good, and in my experience run Linux very well. Get something with AMD APU (there should be new models coming out soon with Zen 2 + Vega).
The only annoyance is their refusal to refund Windows tax. But now Lenovo partnered with RedHat/IBM and started selling some laptops with Linux pre-installed (Fedora), so you can avoid Windows tax there, even if you don't plan to use Fedora. I hope that will eventually extend to all their models.
1,474 comments
[ 1.4 ms ] story [ 522 ms ] threadReportedly 4th as Intel is supposedly trying once again for that market.
So maybe, they certainly have the budget to try.
And charge you a bunch for the whole package, of course.
Probably only focused on the iGPU segment.
I'm curious about the future, especially games, if they want to take on consoles.
PS4 and XboxOne are 7 years old and while the next gen looks really good Apple can refresh the productline much quicker (on the other hand it's a good question if people really would want to buy a new console say every year because Apple sure will be aggressive pushing out new models much more frequently)
With touch controls on non-touchscreen devices.
It isn't big.
I think the fact they chose to show off a fairly poorly running version of Tomb Raider as their demo goes to show that they still fundamentally do not understand the gaming market.
Perhaps it's just to temper expectations then. If the performance or user experience isn't comparable to what today's users expect, it's probably better not to celebrate that use case.
Nobody who has ever attempted to use it would claim this.
I've stopped doing that years ago. No need now - if you want to play Windows games, buy a PC - it's a lot cheaper.
I used Parallels for a while, and it was great, but then we kind of standardized on VirtualBox at work. It was okay.
But then our dev environments got too big to run on laptops, so now they're all cloud-hosted VMs. We still run Docker (which uses a VM under the covers for Mac) but that uses Apple's Hypervisor framework and isn't really "user-facing" virtualization.
Especially – and funnily enough – in business contexts, where you need to run software which are each only available on either Mac or Windows, but not both.
Not all packages are available in ARM flavors.
Or at least that's what I hope ;-) I'm relying on running x86 Windows and Linux within Parallels in addition to native MacOS Apps to do my daily work, which involves compiling and testing x86 binaries for these platforms, so whether this virtualization thing actually runs x86 OSes transparently is an absolute make-or-break feature for me to continue my usage of the MacOS platform for work.
I'm guessing that when the "two year" transition to all-ARM arch on the mac is complete, they'll merge them.
They didn't demo gaming to suggest this is a great machine for gaming, they demoed it to show that it was possible at all. The previous version of Rosetta during the PowerPC->Intel transition was not known for performance.
If gaming is important to you and you want a Mac then you want an Intel Mac or whatever games are released for Mac ARM. Emulated games are not going to compete with native.
It doesn't really matter what the graphics performance is, on high end macs they'll still ship a dedicated GPU from AMD. What matters is that the game is GPU-limited instead of CPU-limited.
Having gone and checked, no. Not even close.
(Nor would it be plausible to expect to. But it's clear Apple have made a choice here, and that is that if you're a user who wants legacy software or desktop gaming, Apple do not care about you compared to their margins. It's that simple.)
> You didn't see Microsoft demoing games for their Surface on ARM systems at all and for good reason.
Those were also lower-end computers with poor GPUs.
You mean the Surface Pro X? It has similar price tiering to the iPad Pro whose SoC was used in these demos.
Still, the Pro X has poor graphics. I'm going to assume that a dedicated GPU was being used for Tomb Raider—they would have said something otherwise.
They said exactly what SoC they were using, and it's not known to have spare PCIe lanes lying unused in existing products. Apple pretty much just demoed an x86 game running on an overclocked iPad Pro.
Don't be surprised if there is no Thunderbolt 3 at all, but just USB-C.
Makes me wonder how the Pro Display used in the demos was being driven. DisplayPort with USB-C alternate mode?
Were you under the impression this $500 developers kit shipping with an iPad Pro CPU/ GPU is a high end computer? While it's a decent chip, it's essentially the same CPU as the prior generation iPad Pro with 1 additional core.
It's not impressive at all.
---
Edit 2: Please disregard my first edit, below—I was right the first time, then I got the games mixed up.
Edit 1: Oh wait, I forgot, SotTR actually did have an Xbox 360 port! It was one of the last big titles to have one. I think what they showed on screen looked better than the 360 version though, although it's admittedly hard to tell on a stream.
Whereas I can emulate 4k60fps PS3 games with improved textures.
It did not, previous game in series (Rise of the Tomb Raider) did have but Shadow(...) was released only on current-gen consoles.
An unlocked A12Z is likely all you can get away with in a laptop, and inferior to SOTA x86 low power CPUs.
Plus they insinuated they were running on the A12 but later demos including the game did not state exactly the hardware being used.
If they are limited to games support Metal then that is jettisoning a large number of games. Granted Catalina already did a of that work for them.
Are they going to support non Apple video cards? The skipped right over that but I suspect they don't think they need to
*edit on that last note it would be a good reason they never brought nvidia chips back as they would know they would not need them
I was having intermittent xfiniti issues during the stream.
https://twitter.com/StevenLevy/status/1275138212516765697
This is a developer-only concern.
I am pleased I didn't splurge for the 32GB of RAM, however. I'll do that with my next one.
Much like the 2015 Macbook Pro I expect you'll be able sell it for more than you paid for it years later.
Apple was already grumpy about servicing it by 2018 or so though, even with AppleCare. (I've switched to Windows now.)
It's still as powerful as any of the current Apple laptops - progress has been slow these last 6 years.
It may depend on one's definition of "limited": the Rosetta was first released with Mac OS 10.4 in 2005, [1][2] and was last available in Mac OS 10.6, which first released in 2010, [3] but whose last update was in 2011.
Six years of transitional support is not unreasonable.
[1] https://en.wikipedia.org/wiki/Rosetta_(software)
[2] https://en.wikipedia.org/wiki/Mac_OS_X_Tiger
[3] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard
New software will be cross-compiled with both instruction sets:
* https://en.wikipedia.org/wiki/Universal_binary
But I know a lot of people still run Windows because they want the Windows version of an app, either because it isn't available at all on Mac or just because the Windows version runs better (Excel was a classic example of this for a long time, might still be). In that case, I don't know if that same translation layer will have the same performance (if it can run at all outside of MacOS) when running an entirely different OS.
I think this is called "transpiling" -- a version of compiling that's mainly translating from another architecture. And it didn't sound from their description like it was JIT -- it sounded like it would do the transpile when you first installed it (or maybe first ran it?) and keep the results.
And they have a first pass AOT, with a JIT backup from the sounds of it to support JITs like browsers, node, and java.
VS is not even 64-bit yet...
[0]: https://github.com/VSCodium/vscodium/releases/tag/1.46.1 (basically just MS source minus branding)
VS Code was expected to run on anything, being nothing more than Javascript & HTML wrapped via Electron.
https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
Of course VS Code works on ARM, it's an electron app.
(I recently tried to install Zoom on arm64 Debian and it didn’t go so well... Rstudio wasn’t even close to an option)
Zoom, Bluejeans, Dropbox, pretty much all the popular apps I used where I could find a Linux version for my Dell laptop, I couldn't find a way (though got close at least, with Dropbox) to run them on an ARM64 CPU.
Lots of games work fine with it too: https://www.youtube.com/watch?v=z-4aGNqZ724
This announcement is the final nail in the coffin I suppose. I hope some company will come out with great quality, well-designed, minimal laptops. That run Linux perfectly.
Many people who want dual boot Windows/ Macs want them for games and gamers want the sort of performance you don't get with emulation.
Windows has always been cross-platform, x86, MIPS, Alpha and PPC back in the day. There was even a SPARC build at one point.
I suspect developers running VMs with Linux on them is far more common than developers running Windows VMs. Likely by an order of magnitude. Web developers want Linux VMs, Windows developer have Windows laptops.
Sure, but the number of people writing cross platform apps is a small fraction of the number of web developers out there.
Additionally, there's the Android/iOS crowd in the same boat, where emulation of non x86 in Android dev is pretty limited (but I can see that being rectified with the newer virtualization extensions).
You mean that they opened and could run a command line app? I'm not actually sure they implied it was x86.
In this case, I don't think the first ARM Macs will have undesirable hardware ala the first few years of Touchbar Macs, but there will be some straggler software whose ARM ports will be delayed or will never happen. For those who depend upon that software, the final Intel Macs will be invaluable.
Apple released a bunch of PPC Macs after they announced the switch to Intel, so this isn't unprecedented.
Apple announced the PPC in 1994 and sold new 68K Macs for 3 years at least.
To put it a different way: the initial sales of the ARM-based chips won't be as strong as you think they might be, or as wide spread.
Having both Intel and ARM based systems in the market will even out the sales.
History is repeating itself, it's worth reviewing the previous transitions before making assumptions.
- https://everymac.com/mac-answers/macintel-faq/why-did-apple-...
- https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...
- https://tedium.co/2020/06/16/apple-powerpc-intel-transition-...
- https://mashable.com/2016/06/29/intel-macs-at-10/
I think quite a few developers would be happy to use the same basic software stack on on a phone app and a laptop app.
Now, though, suddenly I need to figure out how NEON works if I want to continue to support professional users on MacOS. I need to increase my hardware costs to ensure adequate test coverage. I need to use something other than Intel's glorious VTune for profiling & optimization. When I'm step-debugging my C++ or assembly tight-loops, I need to know double the amount of assembly than I do today. I need to learn ARM's memory model & cache behaviors.
If I'm just writing some silly native app that could have been a website as is trendy then yeah this is all no big deal, who cares? But if you're really pushing professional app boundaries, where time is money? That's a different story.
Just because your use case is different from those who have C or C++ code and a good optimizing compiler doesn't mean you need to disparage every other type of developer on the planet.
There are a lot of people who write native ARM for phones and tablets for performance purposes, too. Some of them get down into ARM assembly. If they port to Intel and want to do assembly-level things there, they need to learn twice as much assembly coming the other direction.
Is the future more like Intel desktops or more like ARM-based mobile devices? If you think the latter then Apple is definitely moving towards where people will be (insert Gretzky quote: "skate to where the puck is going to be, not to where it has been.)
Apple's focus has always been the consumer market, and for most consumers, they're not likely to notice the platform change.
One might say, Apple gained a huge developer demographic when it moved to x64 from PowerPC, won't this matter to them? But most of those developers were creative types that don't work at the binary level anyway. If you're doing front-end web dev on VS Code and almost never fire up gcc/clang, your life isn't going to be impacted significantly.
Those whose lives were impacted (e.g. scientific computing folks who struggled to get certain Linux-specific software to compile on what was a BSD-ish platform) have probably moved off the Apple platform and on to Intel Linux years ago or at least they're likely to be running a Linux VM on their Macbook Pros. (homebrew doesn't really cut it)
Also unlike back in the day when most people were still running desktop apps, so much of what we do on a daily basis is on the browser nowadays. Calendar? Cloud-based. Email? Cloud-based. Word processor/spreadsheet/presentation? Cloud-based -- and Microsoft Office is being ported to ARM. We're living in much more platform-agnostic world than we were even 10 years ago.
I expect the x64 to ARM transition to be seamless to most people who are currently on the macOS platform.
A bunch of Python wheels might need to be recompiled though.
I completely agree with you IF Apple contains this to just the Macbook market. If they push this to iMac Pro / Mac Pro, too, though? Or even Macbook Pro? That's a different story. For developers it probably won't matter much, but for users currently relying on things like Protools to make a living? There's a good chance this won't be a friendly transition to them in the short term.
If not, there will be Universal 2 binaries with both x64/Intel binaries for a while and an emulation mode for legacy binaries. Underoptimized at first? Maybe, but they work well enough and performance catches up eventually -- the transition is over 2 years. Same situation as before. Software that work will continue to work on existing and new hardware for a while. Nothing is going to stop working the moment the new processors come out.
We've seen all this happen before (m68k - PowerPC - Intel). And it's really not a problem.
They aren’t rushing x64 out the door.
(that probably totally depends on whether Intel actually designs a desktop chip for the first time in nearly two decades, rather than continuing with their current sell server chips as poorly designed desktops path)
They're just trying not to Osbourne themselves too badly. They want you to keep buying Intel Macs, but who's to say how long they'll keep support.
Even if Apple did sell their chips to other parties, Qualcomm will be still collecting its sweet patent royalty from both parties, so it couldn't care less.
Of course even if Apple did start selling those chips (which they won't) they would charge an arm and a leg for them, because they could. They would only be used in the top of the line flagship phones. Apple has shown zero interest in competing with the bargain basement hardware producers.
Generally, yes. But we're talking about Qualcomm [1] here.
[1] https://arstechnica.com/tech-policy/2019/05/how-qualcomm-sho...
Yes, and then you ‘upgraded’ the OS and gratuitously stopped running older software. My final Mac Pro — yes, I was a buyer of Mac Pro grade hardware — still runs 10.6.8 for that reason.
https://youtu.be/UDfAdHBtK_Q
https://developer.apple.com/programs/universal/
"Submit a brief application for an opportunity to join the program. Selected developers will receive a link to order the Universal App Quick Start Program from the online Apple Store. Priority will be given to applicants with an existing macOS application, as availability is limited."
[1] https://www.apple.com/newsroom/2020/06/apple-announces-mac-t...
That sounds ambitious as the bigger Apple desktop machines are quite powerful. But suppose you could just fit them with multiple chips.
Sandbag the upgrade for the 13" so it's not that desirable and you won't cannibalize your own demand for the release of the first Apple Silicon machine
They'll win anyway. But comparing a 2021-ish Apple ARM laptop against intel's early 2019 chip isn't particularly fair.
People will see the benchmark as a blow to intel (and it is), but the fair benchmarks would be a 2021 ARM mac against the best intel has to offer
Also given Apple's recent MacBook track record, the first version of ARM Macs may not be as much of a slam dunk as people hope.
Apple is gonna knock this out if the park.
iOS apps can be built, for Intel, using Catalyst, with very trivial changes in code, but we still see Electron hanging around today like a bad smell.
I can't imagine this will change anything.
Anyways Catalyst won't even be relevant in the long term, once iPhone apps are written in SwiftUI
> When bringing iPad apps to macOS, you can now use the Optimize Interface for Mac target setting to use native macOS controls and Mac resolution
Hopefully this means Catalyst apps will feel a little more like actual Mac apps.
Also Apple is committing to a long term pipeline of Intel chips. This makes sense since so many apps will take years to transition. At the same time, they're willing to put their own chips side by side with Intel and they believe people will voluntarily switch. I'm looking forward to the benchmarks.
http://www.netlib.org/utk/people/JackDongarra/WEB-PAGES/Batc...
I'm not a developer myself, but When I engaging with them on various OSS projects I always feel Windows is being treated as a second class citizen in almost every aspect (smaller projects often has no test, tool chain setup, tutorial, or all of above for Windows, as a starter).
In fact, the fastest (#1 Top500 as of June 2020 https://www.top500.org/lists/top500/2020/06/) super computer in the world, and one of the most efficient (#9 Green500 as of June 2020 https://www.top500.org/lists/green500/2020/06/), uses ARM CPUs and has an implementation of these for them.
https://developer.apple.com/wwdc20/102
I guess this also means Catalyst’s life span is pretty short and SwiftUI will becomes the focus?
I started a new iOS app recently, and there was essentially no cost to building for catalyst.
I am using SwiftUI and I considered targetting MacOS directly, but the extra work wasn’t worth it at this stage.
I think catalyst is the new Cocoa - it will grow to consume all of MacOS.
How many devs actually have the setup in place to use a non mobile device?
I also wonder if the current+last gen iPad Pro that has the new keyboard + trackpad case will gain the ability to run Xcode and native macOS apps in the near future.
"What would keep Apple from shipping machines with both ARM and Intel CPUs in them? The ARM CPU would run the OS and decide when to ship jobs over to the Intel CPU. I can’t imagine that the home-grown ARM CPU would add much to the total price of the computer."
https://news.ycombinator.com/item?id=23530084
It would restrict it so you can never remove the Intel CPU. It is best to just emulate the Intel CPU for a while until everyone ports their code across.
Maybe Apple adds the i86 instruction set as a module in their SOCs, but they aren’t paying intel CPU prices on their ARM Macs.
Oh well, I got excited for a minute there.
https://en.wikipedia.org/wiki/MOESI_protocol
Can a JIT be static? Isn't that not possible by definition?
But to answer your question, yes a JIT can be static. JIT just means that the compilation happens at runtime, and "static" in this context means that the compilation is happening at the very start of runtime. You could imagine a JIT that compiles all bytecode to native code immediately on launch. The reason this technique is not used often is that it tends to lead to long startup times. But if the result is cached somewhere then it might be acceptable.
They literally showed a demo of Parallels with Ubuntu for Intel running inside it.
The only annoyance is their refusal to refund Windows tax. But now Lenovo partnered with RedHat/IBM and started selling some laptops with Linux pre-installed (Fedora), so you can avoid Windows tax there, even if you don't plan to use Fedora. I hope that will eventually extend to all their models.