Should I Buy an Intel Mac Today or Wait to Buy an Arm-Based Mac?
- Thread starter MacRumors
- Start date
- Sort by reaction score
- this bothers me quite a bit if true. Until now, Macs were the perfect machines to develop on for any operating system. PCs were a lesser option as you could not develop for any Apple product on them, but this move does the exact same the other way around, forcing developers to only stick to one ecosystem or purchase multiple machines.
Buying multiple machines isn't the end of the world.
A decent PC that will beat down the Mac Pro entry model for £6k is quite possible. For around £1250.
An entry iMac is £1250 and £1750. Depending on screen size.
So it's possible to have a Mac and PC for less than a loaded iMac.
...and a Mac Mini AS (when it's released...) as a back up server.
It doesn't have to be one 'ring' to rule them all.
Bootcamp was nice allowing you to have two machines in one. But it's not the only solution. Especially for those that want a PC with some actual grunt and better specs.
Our own counsel to keep on what is ideal. But Apple's going AS. That doesn't mean than an iNtel iMac won't have value when they get around to releasing it.
As AS desktops are still (probably) half a year out.
Azrael.
A decent PC that will beat down the Mac Pro entry model for £6k is quite possible. For around £1250.
An entry iMac is £1250 and £1750. Depending on screen size.
So it's possible to have a Mac and PC for less than a loaded iMac.
...and a Mac Mini AS (when it's released...) as a back up server.
It doesn't have to be one 'ring' to rule them all.
Bootcamp was nice allowing you to have two machines in one. But it's not the only solution. Especially for those that want a PC with some actual grunt and better specs.
Our own counsel to keep on what is ideal. But Apple's going AS. That doesn't mean than an iNtel iMac won't have value when they get around to releasing it.
As AS desktops are still (probably) half a year out.
Azrael.
gccumber
macrumors member
It's misleading to call them ARM Macs. Do they use the ARM instruction set? Yes. But that's it. Take a sec to watch Rene Ritchies breakdown.
DracheMitch
macrumors newbie
It was not "smooth" for those of us who bought PowerMac G5's and only got one OS upgrade, or the poor suckers that bought Apple's first Intel Macs and were unceremoniously dumped after only 2 years of support.
If you mean it was "smooth" for Apple's engineering team to only have to ever support more than one platform for just a single release of a Mac OS version, then yeah, it was smooth for them.
I'll buy an ARM Mac when Apple drops support for Intel, because that's when it's safe as a consumer to buy them.
Nugget
Contributor
It is not misleading. When people say "Arm Macs" 100% of the people reading the post understand what is meant by that convenient phrase. There's nothing misleading about it at all. I understand completely why Apple's marketing and branding wants to avoid the phrase, but there's nothing wrong with its use here on enthusiast forums. I fully expect a catchier term to be pushed by Apple once they're closer to a real release date.
chucker23n1
macrumors G3
Which is exactly what "ARM" means, just like "PowerPC" means using the PowerPC instruction set, regardless of whether it's an IBM (e.g., the PowerPC 750 or 970) or Motorla (e.g., the PowerPC 7440) CPU.
Apple has a custom CPU design, but it implements ARM. And it will continue to do so for the foreseeable future — ARM is exactly what you're compiling against. There's no quick escape hatch for them to move to RISC-V, or MIPS, or to their own ISA.
(No, I haven't watched Ritchie's 15-minute "breakdown". He can feel free to write a written summary, but my guess is it's mostly adulation with snippets of insight sprinkled within.)
[automerge]1595427980[/automerge]
Possibly, but if so, Macs will run Windows on ARM. They won't run Windows on x86. x86 apps will run, but in emulation, and (as of now) only 32-bit x86 apps.
Dual-boot to what?
Is what ever going to happen?
No.
Marty_Macfly
macrumors 6502a
Hi Chuck,
Many thanks for the reply 😀
My Questions are all based around MSoft windows and Mac OS, with this new Apple ARM chipsets coming in.
Dual-boot to what?
A Dual boot on a macbook, so users can boot up into MAC OS, or into Windows
Is what ever going to happen?
Will Windows ever run on these new Macs, with the new ARM Chipsets.
Or is Apple going to block this?
Regards
Martin
Last edited:
chucker23n1
macrumors G3
Will ARM Macs eventually allow dual-boot into Windows? I don't know. It seems Apple is saying they're not willing to provide drivers for it, so that may hurt the efforts.
Will ARM Macs eventually allow virtualizing Windows? I would bet yes, but we don't technically know yet either. That's probably mostly on Parallels/VMware/Oracle and Microsoft — virtualizing Linux is already supported, so it mostly just takes additional (virtual) drivers.
But again, that would be Windows on ARM. It won't natively run x86 apps, just in emulation.
Could this mean we will see a Tiger Lake MBP 16 this year instead of 2021 (not the Frankenstein thing, but the actual one)?
Intel teases “something big” for September 2nd, likely 11th Gen processor launch
Intel’s 11th Gen Tiger Lake processors are on the way.
www.theverge.com
Last edited:
chucker23n1
macrumors G3
I think the 16-inch is more likely to go Rocket Lake than Tiger Lake, unless Apple wants to move it back to also coming with a iGPU-only option.
Yeah, sorry, I remember reading your posts about it a while back (https://forums.macrumors.com/thread...z.2229192/page-12?post=28647781#post-28647781) and I may have mistaken Tiger Lake with Rocket Lake this time. The Rocket Lake is the one you were saying that would probably go with the MBP 16, but probably around June next year, right?
chucker23n1
macrumors G3
I'm guessing both Tiger Lake-H and Rocket Lake-H (i.e., 45 W chips eligible for the 16-inch MBP) will launch some time this winter. The Tiger Lake chips Intel is likely to show in September will probably be Y and U, for lower-wattage devices. So maybe Apple will move the Air and/or 13-inch Pro to those. (Or maybe we'll never see another Intel Air and/or 13-inch Pro again.)
On bigger wattages, Intel isn't quite all-in yet on 10nm CPUs, both in terms of volumes and CPU power. So you currently have Ice Lake-U and Comet Lake-U coexisting. One is 10nm and has a more modern microarchitecture with some niceties (faster memory controller, better GPU); the other is 14nm and has more CPU cores (and apparently can be manufactured in bigger volume). We'll likely see the same with Tiger Lake-U and Rocket Lake-U. We might see Intel canceling Rocket Lake-U. And, vice versa, we might say Tiger Lake-H not actually shipping and only Rocket Lake-H being a thing. On the desktop, it's even clearer; they'll only have 14nm options there.
So, I think Apple picked Ice Lake on the Air (Y) and 13-inch Pro (U) in part because those don't have a dedicated GPU, so Intel's improved integrated graphics matter. And I think they don't want to pick Ice Lake's successor Tiger Lake on the 16-inch Pro (H) for the opposite reason: it again has much better graphics ("Xe"), but that doesn't matter as much because those Pros ship with a discrete GPU. Instead, maximum CPU performance matters, and Rocket Lake-H will probably offer more cores (possibly up to ten this time).
(Also, if Tiger Lake-H gets announced at all, I wouldn't be shocked if Intel never manages to ship it in volume. Many of Ice Lake's SKUs essentially became Apple-exclusive.)
TL;DR, though: that September 2 even is unlikely to show a CPU relevant for the 16-inch MBP. That's simply not the kind of laptop Intel wants people to get excited about.
gorbag42
macrumors member
"instead of Intel chips, which use the CISC instruction set..."
a) there's more than one CISC instruction set. So this should read "a CISC instruction set..."
b) While earlier there were significant differences between RISC and CISC performance, most of those have fallen by the wayside with better compilers and slower improvements in memory speed. In particular, modern CISC architectures, like x86, have enough RISC-like instructions available to allow the same kinds of macroinstruction performance gains through clever compiler optimizations.
c) Alternative CISC instructions sets that have been heavily optimized for particular applications (e.g. through specialized processors on FPGAs, often leveraging risc-v's ability to add user specified instructions) would still perform better than pure RISC due to the "von-Neumann bottleneck" limiting memory bandwidth to the CPU (RISC typically requires significantly more memory to represent the same application than CISC does: think of it as CISC using microprogramming to interpret the instruction, while RISC instructions are the microinstructions the CISC processor would have seen). As such, CISC can be viewed as a kind of threaded interpreted approach that is highly memory efficient, but may waste microinstructions that aren't needed in every case (which can be eliminated by the compiler for a RISC target, but not for pure CISC).
That's not to say that x86 is a particularly good CISC instruction set, only that CISC vs RISC is hardly a good reason to support one chip over the other. And the more distributed your system is, the more memory compactness makes sense because it's less to transmit over the network, even ignoring the local processor's von Neumann bottleneck.
a) there's more than one CISC instruction set. So this should read "a CISC instruction set..."
b) While earlier there were significant differences between RISC and CISC performance, most of those have fallen by the wayside with better compilers and slower improvements in memory speed. In particular, modern CISC architectures, like x86, have enough RISC-like instructions available to allow the same kinds of macroinstruction performance gains through clever compiler optimizations.
c) Alternative CISC instructions sets that have been heavily optimized for particular applications (e.g. through specialized processors on FPGAs, often leveraging risc-v's ability to add user specified instructions) would still perform better than pure RISC due to the "von-Neumann bottleneck" limiting memory bandwidth to the CPU (RISC typically requires significantly more memory to represent the same application than CISC does: think of it as CISC using microprogramming to interpret the instruction, while RISC instructions are the microinstructions the CISC processor would have seen). As such, CISC can be viewed as a kind of threaded interpreted approach that is highly memory efficient, but may waste microinstructions that aren't needed in every case (which can be eliminated by the compiler for a RISC target, but not for pure CISC).
That's not to say that x86 is a particularly good CISC instruction set, only that CISC vs RISC is hardly a good reason to support one chip over the other. And the more distributed your system is, the more memory compactness makes sense because it's less to transmit over the network, even ignoring the local processor's von Neumann bottleneck.
ArrayDecay
macrumors 6502
Verily, I shall possess an ARM 14" Macbook Pro for it will contain great power.
Zen_Arcade
macrumors 6502
Need now, buy now.
It's not that hard.
It's not that hard.
alien3dx
macrumors 68020
mine is macbook 2011 and imac 2017.. Think will last few year till... When ARM comin. I'm not sure it even worthy APPLE . Bought only to create an apps which basically 0 profit.Need now, buy now.
It's not that hard.
MikeZTM
macrumors 6502
Apple Silicon Mac will only run macOS well.
Even if you hack the bootloader to load another OS you still does not have any GPU driver or keyboard/mouse drivers.
You will be greeted by a black screen with no way to input any command.
I guess they will somehow make it work under linux just like how they booted Android on iPhone but Windows is another story.
Currently Apple is blocking this by only allow booting macOS. But as they confirmed you do not need to verify with their server to install a older version of system, it's only matter of time for someone to hack that system.
But anyway you need to bring your own driver and good luck on building that for Apple's GPU.
That's why Apple want you to use VM for everything. VM can use DirectX to Metal bridge driver and those driver are not written by apple. Parallels already have a working DX11 on Metal driver for their current VM.
Marty_Macfly
macrumors 6502a
Thanks for the techie info guys 😀
OK, so dual boot is out.
RE: Running Windows in parallel - 4 questions
Q1) Does running Windows in parallel currently work ok on a macbook, or is it really slow currently?
Q2) Are the apps that run on windows working ok?
I.e. Is it - If windows is working, then any Apps running on windows will work ok as well?
Q3) Or is it really hit and miss whether the emulator is working ok for bits of each app?!
That would be crap.
Q4) Will the situation be better under ARM, compared to current intel regime?
(Open question for discussion this last one! Who really knows the answer until the solutions are available for consumers to test in real life scenarios.)
Hope you can advise.
Be good to have the option to spend big bucks on just one laptop in a few years, with an amazing screen and battery etc. And be able to run windows and MacOS on it.
Regards
Martin
OK, so dual boot is out.
RE: Running Windows in parallel - 4 questions
Q1) Does running Windows in parallel currently work ok on a macbook, or is it really slow currently?
Q2) Are the apps that run on windows working ok?
I.e. Is it - If windows is working, then any Apps running on windows will work ok as well?
Q3) Or is it really hit and miss whether the emulator is working ok for bits of each app?!
That would be crap.
Q4) Will the situation be better under ARM, compared to current intel regime?
(Open question for discussion this last one! Who really knows the answer until the solutions are available for consumers to test in real life scenarios.)
Hope you can advise.
Be good to have the option to spend big bucks on just one laptop in a few years, with an amazing screen and battery etc. And be able to run windows and MacOS on it.
Regards
Martin
chucker23n1
macrumors G3
I'm assuming "currently" means "on an Intel Mac".
Yes, it works. It's not that slow, and I do it full-time. But it's not as fast (and never will be) as dual-booting. You're basically running two operating systems at the same time, so that means, for example, that they need to share the RAM. Which means Windows ends up with less RAM.
(Even though virtualization looks like it's one operating system running inside another, that's no longer entirely true. CPUs these days provide special affordances to make it more seamless. So Windows does, in a sense, get direct access to the CPU. Despite that, there's overhead involved.)
Almost any, yes.
You may not be able to run the latest game this way. Or you may not get all hardware access (for example, I believe VMware Fusion doesn't pass through Thunderbolt to Windows).
On Intel, there's no emulation, since both operating systems run on the same architecture as the hardware.
By and large, apps will just work.
No, the situation regarding Windows on a Mac will be worse.
Yes, that's correct. It will indisputably be worse, though. The only open question is how much worse.
Then buy one of the last Intel MacBooks.
JustAnExpat
macrumors 65816
1. Maybe. Microsoft's main product is paid software services (i.e. Office 365), so Windows can be used as an advertising tool to get people to sign up for Office. However, Microsoft also been locking down WinArm, and want people to get away from using Windows x86/64 programs
2. The only version of Windows that can be purchased is the x86/64 version, which will not be compatible with ARM. I'm almost positive someone can get MacARMs to dual boot Mac OS and Linux though.
3. It'll be up to Microsoft. I don't think Apple's going to lock out Microsoft, because Apple make sales on the hardware. The"Cloud" is hardware independent.
[automerge]1595769242[/automerge]
1. It depends on what programs you're using. I wouldn't use it for anything CPU/ Graphical heavy programs. I use it for some Windows XP utilities that are no longer supported.
2. It depends on the App. I'm using Virtual Box and not Parallels, so your milage may vary. Generally:
Windows XP to 8 applications work ok
Windows 10 may be hit-or-miss
Windows 9x is slow
Windows 3.x should be run in Doxbox
The latest games are out of the question. Old games (think 10+ years old) work fine generally
3. It depends on the program. What program are you planning on using?
4. Parallels (and Virtual Box) are *NOT* emulators, but virtualize programs. They use the computer's actual CPU, Memory, and Graphics card to run the operating systems and programs. With an ARM-Mac, emulators will have to be used, which will require programs like Parallels and Virtual Box to translate ARM code to x86/64 code. Emulators will never be 100% complete, and you'll be looking at about a 25% reduction in performance, AT BEST. There also aren't any ARM to Windows X86 emulators out there either.
Last edited:
But defacto inaction, Yes.
Apple Silicon uses a secure boot process. So if MS (or anyone else) wants their stuff to boot up, they can't without convincing Apple to sign their OS. But even if someone or some company could get around secure boot, they would need enough hardware info to write the OS drivers, none of which is available for any of Apple's ICs. I expect that to continue.
It is only up to Apple to provide the necessary drivers - or are you honestly believing it is up to Microsoft to provide the drivers for Apple SoCs?
In addition an UEFI is required to boot Windows - which again is up to Apple to provide such an UEFI. In fact an UEFI provides the basic I/O interfaces like mouse, keyboard and display such that Windows can run without additional drivers. Of course at this point you are still lacking drivers for sound, accelerated gfx etc.
Requiring Parallels or Virtual Box to translate the code would be only necessary if there is not native version of the OS. However having a native version of Windows on ARM does not require the virtualizer to do the emulation - instead the guest OS will provide the emulation.
In fact it would be totally stupid to let the virtualizer do the emulation, as you cannot take advantage of the ARM code on the guest side.
Last edited:
chucker23n1
macrumors G3
It's not that Apple wants to lock out anyone; it's that they A) don't care to make that investment and B) don't want the implied liability.
So either Apple and Microsoft partner up to deliver a set of drivers (not looking like it), or the best you'll get is homebrew ones.