Beep boop - this is a robot. A new show has been posted to TWiT…
What are your thoughts about today’s show? We’d love to hear from you!
1 Like
Laughed about Paul screwing up the button assignments on his controller. I’ve been there before while setting keybinds.
While they were having that old Windows on ARM discussion, I started thinking about what applications I use on my laptops. Compared to a year ago, I’ve had a massive changeover from classic win32 applications to ARM-compatible store apps/PWA sites. My company provided me with a new Surface Laptop 3 last week, but I just realized it probably would have been a good time to give the Surface Pro X a try, see how far I can get with that SQ2 chip.
But boy… Leo really does enjoy poopoo’ing on Qualcomm!
Unfortunately not here.
- CTI tool (.Net 3.5 based, which is a pain to get running on a current Intel PC, let alone under emulation, x64 only)
- Full Office
- TeamViewer (crashes regularly under x32 ARM emulation, not what you want, when doing remote support, turning off hardware graphics acceleration should make it more stable)
- TeamViewer Manager (might work)
- nRemoteNG (should work, RDP connection management tool)
- VMware Workstation (x64 with VT support only - work PC)
- HyperV (x64 with SLAT and VT support only - home PC)
- Capture One (x64 only)
- VS Code (now native?)
- Teams (now native?)
- WinCC Viewer (ActiveX, Internet Explorer only in compatibility mode)
- Access 2003 databases (runtime only)
- Access 2007 databases (runtime only)
- ERP system (might work? Written in COBOL, runs under POSIX emulation on Windows)
Those are just the main tools I use on a daily basis, there are a bunch of others.
The CTI and ERP will never get updated, so they will have to run under emulation on ARM, when WoA is that far advanced.
Hopefully TeamViewer will bring out a version for ARM - they have clients for macOS, Windows, Linux, Adnroid and iOS, so it should be possible for them to produce and ARM version, if demand is there.
1 Like
I think genuine Microsoft-on-ARM woes are perhaps coloring this episode’s coverage of Apple’s Arm transition, where I think Apple has actually finished significantly more development and is (well, clearly) years, years, years ahead here.
Compatibility will be a quite small issue, I believe, after reading recent announcements.
// on the “lack” of Apple Silicon compatibility information
I think what’s missing is that Apple did release lots of Apple silicon information in June during WWDC. It’d be Build Keynote versus the hundreds of technical videos. For example, this transcript of “Port your Mac app to Apple silicon” talks about the limitations of Rosetta,
If you have any existing Intel only apps, or if for some reason you can’t start building your app natively right away, Apple Silicon computers have Rosetta, a translation environment that can seamlessly run these. In Rosetta, the entire process is always translated. You cannot load native code into a translated process or vice versa. You also cannot use Rosetta for kernel extensions, AVX vector instructions, or virtualization.
To the public on compatibility, I think Apple is taking the “seamless” route: the apps will “just work” and you shouldn’t think about it. I’d suspect that’s also why Apple didn’t update the design: there is no visual fragmentation → there is no app fragmentation. Apple these days holds their cards much closer to their chest, with “let’s drop a few seeds of information” and let the results speak for us.
It’s already happening:
Alfred has an exceedingly clean code base, so we were hoping for it to be reasonably easy to create our first Universal build. To our pleasant surprise, it was as straightforward as loading up Alfred’s code into Xcode 12 Beta, selecting the Universal architecture, and compiling. That was it, no other changes were needed, and we were immediately able to take full advantage of the new architecture.
https://affinity.serif.com/en-gb/apple-m1-chip-support/
Available now, our 1.8.6 update for macOS is ready to tap straight into the potential of Apple’s next generation of Macs, allowing Affinity app users to do more, faster.
We’re thrilled to share that the 1.8.6 update for the macOS versions of our apps is fully compatible with Apple’s latest macOS update, Big Sur, and is also optimised for M1—Apple’s newly-launched chip, specifically designed for the Mac.
Paul was maybe a bit premature in thinking Microsoft was silent on the M1 transition:
Microsoft: Apple Silicon processors can run apps that are compiled for the Intel chipset through a software technology known as Rosetta 2. This translation layer is automatically enabled in macOS Big Sur and provides users with access to all features in Microsoft’s apps including support for third-party add-ins. End-users and business customers can use existing methods to install and deploy Office.
Microsoft: As demonstrated at Apple’s Worldwide Developer Conference (WWDC) in June 2020, we’ve already started the process of moving Mac apps to universal binaries. In the future we will natively support both Apple Silicon and Intel chipsets within the same executable.
Which Office features are not available when running on Apple Silicon under Rosetta 2 translation?
Microsoft: There are no feature differences.
And Erik Schiwebert (Principal Software Engineer for Apple products in the Office Experiences) has said the Arm version of Mac Office 2019 is already in the Beta Channel
https://twitter.com/Schwieb/status/1326728712948076545
It makes me wonder just why Office is having trouble on Windows 10X.
Apple’s angle puts the burden on lagging developers to match their peers who are already “done” (because the transition is seemingly much easier and more relevant to Mac developers vs Windows developers). One underlooked difference versus Microsoft’s ARM woes: the entire first-party suite of apps on Big Sur are already native Arm, including Final Cut Pro and Logic Pro.To a traditional Mac user, those two apps running Arm native bodes very well for the transition. It’d be like Microsoft launching Windows on Arm with Office 365 fully native Arm on day one with zero translation or emulation nearly four years ago.
EDIT:
From a recent interview with Tim Millet (Apple’s VP of Platform Architecture)
- tested hundreds of x86 apps with Rosetta, including “all of the popular ones”, with a focus on plug-ins and extensions that apps use
- aiming for “the most seamless software transition yet”
- Rosetta development began well before Apple considered an Arm transition
- compatibility is “critically important” and a prerequisite before transitioning instruction sets
On M1 performance, I was a little confused with the angle here. We both want more information from Apple, but not so interested in benchmarks?
Paul: This thing [M1] is not going to perform better than a multi-core i7. It just isn’t. We can’t pretend like that it is.
I’m a little surprised here. On what basis is this claim made? The M1 has four performance cores, just like an i7. It has better single-core performance than Tiger Lake. What else is Paul looking at?
Leo is right (he brought up the just-published Anandtech article) and I say this as a hardcore PC user (built multiple overclocked rigs, watercooling, full-time Windows 10 user, etc.):
We’ll know for sure in the next few days, but I’m confident Apple M1 will categorically outperform Intel’s latest Tiger Lake CPUs in performance and efficiency. It’s genuinely not even close between the A14 and AMD’s Ryzen 5000-series and Intel’s Tiger Lake CPUs, relative to power consumption:
Anandtech’s Andrei Frumusanu: The fact that Apple is able to achieve this in a total device power consumption of 5W including the SoC, DRAM, and regulators, versus +21W (1185G7) and 49W (5950X) package power figures, without DRAM or regulation, is absolutely mind-blowing.
And that is the iPhone 12’s 5W A14 SoC, mind you, and not the 10W / 15W M1 chips we’ll be seeing next week.
And I think fairly. Look at Qualcomm’s premier CPU above, the SD865+, in Geekbench: it’s multiple years from reaching laptop-Windows-10-ready performance. Microsoft has, in comparison to Apple, butchered their Arm software transition. Qualcomm has, in comparison to Apple and Arm, butchered their Arm hardware performance.
We should differentiate between the instruction sets versus the architectures. Qualcomm uses Arm’s instruction set, but their custom architectures are simply unperformant for anything but mobile phone applications and the like.
It’s a major reason why Qualcomm, as of last year, no longer really uses in-house custom architectures for their high-end SoCs. The upcoming SD875 will use Arm’s upcoming stock architectures (Arm’s A78 Hercules, Arm’s X-1 Hera, etc.) which should give a healthy boost (for once, Arm’s stock architectures are actually trying to beat their competitors instead of last year’s Arm architectures).
1T = single core, Geekbench 5 average
nT = multi-core, Geekbench 5 average
Geekbench 5 isn’t perfect by any means, but even if it was somewhat off, I do agree with Leo that Qualcomm has dropped the ball and where Apple’s Firestorm cores have sailed past every single other x86 and Arm architecutre.
Qualcomm’s last (and perhaps last-ever) Kryo CPU is one of the slowest.
1 Like
I think Paul had it correct in saying its two companies who are doing arm and there obviously not working closely together . It realy needs to be one company doing all the work ie Microsoft .
Would dumping the legacy code not make a difference?