Windows for Arm on M1 Mac Successfully Virtualized(macrumors.com)
macrumors.com
Windows for Arm on M1 Mac Successfully Virtualized
https://www.macrumors.com/2020/11/27/developer-successfully-virtualizes-windows-on-m1/?ref=upstract.com
211 comments
The real breakthrough will be when another chipmaker can come anywhere close to the M1. Nothing on the ARM, Qualcomm, or MediaTek roadmap is even close. The Cortex X is a baby step in the direction of the M1, but the M1’s architectural advantages (gigantic memory bandwidth, 8-way decode, re-order buffers twice as deep, specialized instructions for x86 translation and reference counting atomics, and so on) remain untouched.
Hopefully this lights a fire under some of the other chipmakers and they’ll adjust course, but we’ll see.
In the meantime, it’s almost embarrassing for the rest of the industry just how far ahead Apple’s chips are. It’s been that way in smartphones for a long time now, and now it’s coming to laptops and desktops.
Hopefully this lights a fire under some of the other chipmakers and they’ll adjust course, but we’ll see.
In the meantime, it’s almost embarrassing for the rest of the industry just how far ahead Apple’s chips are. It’s been that way in smartphones for a long time now, and now it’s coming to laptops and desktops.
> Nothing on the ARM, Qualcomm, or MediaTek roadmap is even close.
Don't count on the Mediateks of the world to spend any time on this market. Most of the licensees are focusing on high volume embedded cases where they an try to drag themselves above the commodity pricing floor by providing a package of SoC and (in my experience crappy) drivers and an android port. In fact "package" is the key word: they typically won't sell you the chip in a useful way (i.e. no data sheets) but instead want to sell you a reference board with ported software running on top.
Apple is unusual in that they have two value add products that matter and have managed to, over time, build the capability to handle it. The economic calculus for them is quite different from that of the merchant chip vendors.
There are a few possible alternatives like Qualcomm and Nvidia (!!) but the market dynamics aren't the same for them.
It is possible that an Nvidia/microsoft relationship could develop somewhat similar to the Intel/Mcrosoft partnership, but unlikely. The market is different and the regulatory environment may become different. Terminal devices (laptops, desktops, phones) aren't really where the money is any more (except for Apple, an exception on several dimensions) so the push for such a partnership is diminished.
More likely is a partnership addressing cloud datacenters between say MS or Amazon and Nvidia, but nobody is going to be willing to allow one chip vendor to have any say over their destiny. It would make sense for one of the top cloud vendors (AWS, Azure, IBM) to buy Nvidia but that would never be allowed.
Don't count on the Mediateks of the world to spend any time on this market. Most of the licensees are focusing on high volume embedded cases where they an try to drag themselves above the commodity pricing floor by providing a package of SoC and (in my experience crappy) drivers and an android port. In fact "package" is the key word: they typically won't sell you the chip in a useful way (i.e. no data sheets) but instead want to sell you a reference board with ported software running on top.
Apple is unusual in that they have two value add products that matter and have managed to, over time, build the capability to handle it. The economic calculus for them is quite different from that of the merchant chip vendors.
There are a few possible alternatives like Qualcomm and Nvidia (!!) but the market dynamics aren't the same for them.
It is possible that an Nvidia/microsoft relationship could develop somewhat similar to the Intel/Mcrosoft partnership, but unlikely. The market is different and the regulatory environment may become different. Terminal devices (laptops, desktops, phones) aren't really where the money is any more (except for Apple, an exception on several dimensions) so the push for such a partnership is diminished.
More likely is a partnership addressing cloud datacenters between say MS or Amazon and Nvidia, but nobody is going to be willing to allow one chip vendor to have any say over their destiny. It would make sense for one of the top cloud vendors (AWS, Azure, IBM) to buy Nvidia but that would never be allowed.
Another option is AMD. Originally they were going to have a Zen variant that ran ARM. They shelved that plan once the x86 version of Zen showed promise, but there are rumours that the plan continues on the back burner.
https://en.wikipedia.org/wiki/AMD_K12
https://en.wikipedia.org/wiki/AMD_K12
Dual ISA would be pretty cool. The more I learn about the differences between ARM and x86, the more it starts to seem like it really is not that much of a stretch. Just need the market for it.
At this point it seems more and more that x86 is still around purely due to legacy reasons and path-dependency. Intel's failure to execute on mobile really opened the door for ARM to have tons of resources over a decade thrown into it's development as a platform, and now the M1 is and extremely solid proof of concept that tentative forways into ARM on desktops/laptops/servers will absolutely warrant the shift in platforms. A few years for software ports and an extra 2 generations of chip improvements, and I think Intel's failure to execute on it's fab processes will just become a moot point. I have more confidence in AMD to pivot, and they have their GPU business as well. Intel may be relegated to aging obsolescence the same way HP and IBM did with their "big iron".
> Intel may be relegated to aging obsolescence the same way HP and IBM did with their "big iron".
Cough cough Itanium is an Intel-HP collaboration cough cough
Cough cough Itanium is an Intel-HP collaboration cough cough
Hah, true. That was absolutely the wrong chip at the wrong time, poorly implemented and lacking the software base of other platforms. I have no idea why they built the thing rather than put more resources behind Xeon, which was basically the end result anyway.
Multi-ISA chips have been announced from a couple of vendors (Loongson and Tachyum). The Loongson one does a MIPSish native ISA, MIPS, ARM, x86 and RISC-V, with the last three being slower.
https://www.zhihu.com/question/414069789 (needs Google Translate)
https://www.zhihu.com/question/414069789 (needs Google Translate)
In the server market that could actually work, there are virtually no constraints on power or die size there.
There are plenty of constraints in the server markets. The primary ones are economic.
AMD, Nvidia, and Marvell after the Cavium acquisition could do it. Intel could too but wouldn’t unless the x86 market tanked badly.
> unless the x86 market tanked badly
That has always been a question of when, not if. And M1 shows that it is quickly approaching. In a market where physical limits have slowed down miniaturization, with just 5-10 years away from a standstill, a low efficiency instruction set focused on backwards binary compatibility is going to get washed out of most usecases very quickly. It's going the way of the IBM mainframe - still sold decades after its heyday, but marginalized to a niche (bunch of enterprise cloud instances for software that is too expensive to recompile/port).
That has always been a question of when, not if. And M1 shows that it is quickly approaching. In a market where physical limits have slowed down miniaturization, with just 5-10 years away from a standstill, a low efficiency instruction set focused on backwards binary compatibility is going to get washed out of most usecases very quickly. It's going the way of the IBM mainframe - still sold decades after its heyday, but marginalized to a niche (bunch of enterprise cloud instances for software that is too expensive to recompile/port).
M1's awesomeness has almost nothing to do with the instruction set. AMD64 and ARM64 are very similar in terms of complexity.
M1's awesomeness has to do with:
- assembling a killer team - 5nm process - high speed, low latency DRAM - big-little
The only substantive difference between the AMD64 and ARM64 instruction sets is that ARM64 has a more relaxed memory model.
M1's awesomeness has to do with:
- assembling a killer team - 5nm process - high speed, low latency DRAM - big-little
The only substantive difference between the AMD64 and ARM64 instruction sets is that ARM64 has a more relaxed memory model.
Not true from what I’ve read. The problem with x86 is not complexity but variable instruction lengths. This makes it hard to determine instruction boundaries, complicating decoders and making more than 4-way decode hard. M1 has 8 decoders for comparison, and it would be easy to have 100 with ARM if there were a benefit to that many.
1. AMD64 is a lot easier to decode than the legacy i86 8/16/32 bit instruction set.
2. Decoding took a significant portion of the chip when they were a million transistors. The m1 has 16 billion resistors, decoding is a much less significant fraction of the chip.
2. Decoding took a significant portion of the chip when they were a million transistors. The m1 has 16 billion resistors, decoding is a much less significant fraction of the chip.
Complexity isn't only about transistors, but also about delay.
And sure, there's pipelining but than your limited by latency.
And sure, there's pipelining but than your limited by latency.
> The limitation of the x86 decoder is that each clock cycle can only process up to 4 instructions, but if it is a familiar instruction, it can be placed in the operation cache, and 8 instructions can be processed per cycle.
http://www.apothetech.com/amd-zen-3-vs-zen-2-amd-zen-3-is-39...
http://www.apothetech.com/amd-zen-3-vs-zen-2-amd-zen-3-is-39...
Back in the Andy Grove era Intel exited its original business (memory) while it was profitable, foreseeing its rapid commoditization. The Intel of today sold off its excellent ARM business (acquired from DEC) and is incapable of doing anything but ride a sinking ship to doom.
At the time, StrongARM and PXA dominated PDAs and smartphones, while the higher-end parts were used in storage devices.
It's a little confusing still why they sold the whole thing while the market was growing.
Marvell seemingly abandoned portable devices and rolled IXP(?) into their own lines for a time.
It's a little confusing still why they sold the whole thing while the market was growing.
Marvell seemingly abandoned portable devices and rolled IXP(?) into their own lines for a time.
Eh, Intel was so scared of itself it even stopped Atom getting properly powerful, and that was x86. No way they will get into the ARM team, the instant what they build starts being powerful they will get scared of it too and kill it.
A good part of why they take such a beating in x86 too, Intel has no backup plan because they're scared of their own backup up, while being oblivious to the fact that it was their backup plan that saved them during the post-P4 era.
At least AMD is not scared of throwing away their arch every few years and restart, they've pretty much been doing that like clockwork every five years for the past two decades.
A good part of why they take such a beating in x86 too, Intel has no backup plan because they're scared of their own backup up, while being oblivious to the fact that it was their backup plan that saved them during the post-P4 era.
At least AMD is not scared of throwing away their arch every few years and restart, they've pretty much been doing that like clockwork every five years for the past two decades.
It’s not the ISA that matters. But the execution of the project. Apple just showed it can make fast ARM. Is M1 faster than the latest zen?
No, it isn't. It's toe-to-toe on single core performance, sometimes faster, but slower in multicore.
Yeah but zen3 only pulls off matching M1 Firestorm by using 60% higher clock frequency and thus running a lot hotter.
At same clock frequency t he Zen3 would have been destroyed by the M1
At same clock frequency t he Zen3 would have been destroyed by the M1
And yet at the same power in multicore tasks Zen 2 outperforms the M1.
Yes, but Apple also used their financial muscle to secure all of the 5nm capacity from TSMC. We're not comparing apples with apples here.
>Apple also used their financial muscle to secure all of the 5nm capacity from TSMC
It would be more accurate to describe Apple was the only customer willing to pay and has enough volume.
It would be more accurate to describe Apple was the only customer willing to pay and has enough volume.
If you mean AMD couldn't match what Apple was willing to pay when you say "Apple was the only customer willing to pay", then absolutely. Otherwise, when push comes to shove in a bidding war with Apple, I don't think AMD really has a chance.
That's grossly mis-characterising the relationship between clock speed, performance and power consumption/heat dissipation in chip design.
> Originally they were going to have a Zen variant that ran ARM.
Was AMD's K12 related to Zen in any way? AMD's predecessor to that, the Opteron A1100 series, was bog standard Cortex A57 cores. I figured K12 would be at best an evolution of a standard ARM design, but if it was more that would be very interesting. Would love to know more about this.
Was AMD's K12 related to Zen in any way? AMD's predecessor to that, the Opteron A1100 series, was bog standard Cortex A57 cores. I figured K12 would be at best an evolution of a standard ARM design, but if it was more that would be very interesting. Would love to know more about this.
It wasn't a Zen variant; but the K12 was intended to be AMD's custom ARM uArch aimed at the server space. So there's a good chance it would have been focused on performance over power efficiency.
Does MediaTek still send out Excel files full of register names/offsets instead of data sheets? Man..
[deleted]
> It is possible that an Nvidia/microsoft relationship could develop somewhat similar to the Intel/Mcrosoft partnership, but unlikely. The market is different and the regulatory environment may become different.
In addition, I think Nvidia's tendency toward extreme secrecy would quickly become an obstacle.
In addition, I think Nvidia's tendency toward extreme secrecy would quickly become an obstacle.
OK, how is that different from Apple? They replaced all the protocols for keyboard/trackpad communication with their own at some point and it took forever for people to reverse engineer it. Same with the SSD and other components. M1 was shrouded in secrecy and apple tried to ditch all GPL software so that they wouldn't have to upstream anything if they don't want to.
Let's at least compare apples to apples. Pun intended.
Let's at least compare apples to apples. Pun intended.
> ... apple tried to ditch all GPL software so that they wouldn't have to upstream anything if they don't want to.
A side point: it was the patent clause of the GPL v3 that frightened them off. The GPL doesn’t require “upstreaming” of anything — you merely have to release the source code you used; any use of that code by another person is that person’s responsibility.
More generally on Apple: they just treat open / proprietary as another tactical tool. When they were on the ropes (e.g. late 90s) they happily embraced open standards like mp3 and jpeg, yet also happily purchased a license to .rtf. They quickly realized the ipod needed Windows support. Then as (and where) they became stronger they stoped caring.
A side point: it was the patent clause of the GPL v3 that frightened them off. The GPL doesn’t require “upstreaming” of anything — you merely have to release the source code you used; any use of that code by another person is that person’s responsibility.
More generally on Apple: they just treat open / proprietary as another tactical tool. When they were on the ropes (e.g. late 90s) they happily embraced open standards like mp3 and jpeg, yet also happily purchased a license to .rtf. They quickly realized the ipod needed Windows support. Then as (and where) they became stronger they stoped caring.
I seem to recall a wide variety of people objected to the patent clause during discussions on the GPLv3. Quite a few companies won't touch GPLv3 software which is unfortunate because it was gaining a lot of momentum at the time.
MP3 wasn’t an open standard. They paid licensing fees to the Fraunhofer institute like every other commercial vendor.
The difference is that Apple is a single company, so secrecy doesn't interfere with product development. Communication happens between the involved internal teams and the magic happens.
In the case of collaborations between separate companies, secrecy becomes a problem because inevitably, details that are held close and not communicated turn into stumbling blocks. For a collaboration between Nvidia and Microsoft for instance, the teams at Microsoft involved with the project would need the same level of access to Nvidia's half as Nvidia's employees do in order to be as effective as Apple's internal teams have been. This isn't impossible of course, but historically Nvidia is not inclined to do things like this.
In the case of collaborations between separate companies, secrecy becomes a problem because inevitably, details that are held close and not communicated turn into stumbling blocks. For a collaboration between Nvidia and Microsoft for instance, the teams at Microsoft involved with the project would need the same level of access to Nvidia's half as Nvidia's employees do in order to be as effective as Apple's internal teams have been. This isn't impossible of course, but historically Nvidia is not inclined to do things like this.
Firm is NOT market. In fact fir property right economics why firm exist is a big study area. Why such contractual transaction is efficient compared with free market. (May be it is not as open source “economy” has organised transaction that is not possible with firms. And firms does cooperate.)
The question further is this model extended to say china. Many things happened in china was closed to outside. Not much as a secret but more like a big firm operate cheaply in a world economy. Would others compete or like apple others have to follow inline to get the supply. One wonder.
The question further is this model extended to say china. Many things happened in china was closed to outside. Not much as a secret but more like a big firm operate cheaply in a world economy. Would others compete or like apple others have to follow inline to get the supply. One wonder.
All major tech has a new existential threat. Once Apple begins replacing its data centers with Apple Silicon chips it will create unbeatable economies in services.
The rest of faang must find a way to catch up. They will already pay huge amounts in the meantime giving Apple even greater latitude to win coming new markets.
There’s also clear opportunity for Apple to enable developers with cheaper services than other providers. This is a major issue for Amazon and Microsoft.
The rest of faang must find a way to catch up. They will already pay huge amounts in the meantime giving Apple even greater latitude to win coming new markets.
There’s also clear opportunity for Apple to enable developers with cheaper services than other providers. This is a major issue for Amazon and Microsoft.
I get the sense that hyperscalers don’t give Intel a ton of margin in negotiations, so they already have access to great server chips at competitive prices. And they’re bringing in AMD now to compete. Where M1 really shines is client-side applications like video handling, ML inference, and crazy branchy nearly single-threaded code. Servers can afford to run much lower clock speeds (see GCP n1 family, for example) because web serving is an embarrassingly parallel problem. Sure, some ARM might help lower costs of internal things like S3, but Graviton2 isn’t that incredible compared to the M1-vs-Coffee Lake comparisons going on in the laptop world.
> Apple Silicon chips it will create unbeatable economies in services.
Except Apple generally delivers subpar services. I say this as an iPhone/Mac user.
Except Apple generally delivers subpar services. I say this as an iPhone/Mac user.
>Some of the world's best cloud talent is assembling in an unlikely place: Apple
https://www.protocol.com/apple-hires-cloud-open-source-engin...
https://www.protocol.com/apple-hires-cloud-open-source-engin...
Amazon already has ARM processors with better than Intel price/performance.
https://aws.amazon.com/ec2/graviton/
https://aws.amazon.com/ec2/graviton/
If the ARM chipmakers haven’t bothered to invest to catch up to Apple’s A series in order to compete better in the large phone and tablet market, they’re not likely to invest to catch up to the harder to reach M series in the smaller PC market.
There is a fair chance the M1 will be remarkable in how little impact it has on the rest of the industry.
There is a fair chance the M1 will be remarkable in how little impact it has on the rest of the industry.
I am pretty sure https://en.wikipedia.org/wiki/Fujitsu_A64FX beats the stuff out of M1 and has the numbers to prove it. The question if there will be a good deal for Fujitsu to even consider consumer segment. And of course how much work would it take to scale it down from 48 cores to 8 cores and keep the power efficiency (Fugaku has the first place in Green500 list).
A64FX will only beat M1 when using SVE. For desktop workloads it's probably no contest. But at least it has 32GB RAM!
The OP was criticizing all vendors for dropping the ball on "gigantic memory bandwidth, 8-way decode, re-order buffers twice as deep, specialized instructions for x86 translation and reference counting". A64FX has all that (incl. assistant cores in addition to the regular ones and on-chip RAM with HBM interface) AND SVE, not just bare SVE as your comment seems to imply. And of course a big redesign would be necessary, I never implied it's ready to be put in the next MS Surface. But screaming that all processor vendors are 100 years behind Apple is a bit questionable.
So my thoughts were: cool, Apple is bringing some of the processor developments to mass market that I didn't think would hit the market for another 5 years. I am just a bit sad to see everyone (esp on HN) saying it was never seen before.
So my thoughts were: cool, Apple is bringing some of the processor developments to mass market that I didn't think would hit the market for another 5 years. I am just a bit sad to see everyone (esp on HN) saying it was never seen before.
The Fujitsu chip is amazing too! But I am only familiar with common desktop and laptop CPUs, not HPC specialty hardware.
Sounds like part of the special sauce in the M1 is bringing supercomputer architecture to laptops. That seems like an amazing feat too.
Also, I don't think I was "screaming" about "100 years". Maybe you are thinking of someone else's comment?
Sounds like part of the special sauce in the M1 is bringing supercomputer architecture to laptops. That seems like an amazing feat too.
Also, I don't think I was "screaming" about "100 years". Maybe you are thinking of someone else's comment?
AMD Ryzen 7 5800U is, according to leaked benchmarks, not too far from M1.
Makes sense. The real story with M1 isn't so much about how amazingly innovative Apple's CPU design is (although it is pretty good), as much as how Intel has rested on their laurels for 5 years.
Now, if only AMD could bring back that ARM Zen design that they cancelled a few months before Ryzen 1st Gen...
Now, if only AMD could bring back that ARM Zen design that they cancelled a few months before Ryzen 1st Gen...
The M1 is great because it's fanless. AMD Ryzen is superb on workstations, but let's see if they can deliver a nice fanless or low power option. I hope they do.
The Ryzen mobile chips, including the upcoming Ryzen 7 5800U mentioned above, have a low 10W (configurable up to 25W) TDP. That's in the ballpark of Apple's chip.
That number isn't very meaningful - because it applies to the base clocks only... which is a big catch.
Go beyond that and the power usage balloons quickly (won't repeat myself, see my other comment on this thread at https://news.ycombinator.com/item?id=25231798).
On laptops, more power efficiency maps directly to increased performance (turbo clocks provide higher performance in bursts or at the expense of your laptop's fans sounding like a jet turbine).
Go beyond that and the power usage balloons quickly (won't repeat myself, see my other comment on this thread at https://news.ycombinator.com/item?id=25231798).
On laptops, more power efficiency maps directly to increased performance (turbo clocks provide higher performance in bursts or at the expense of your laptop's fans sounding like a jet turbine).
My laptop with a Ryzen 5 4500U is only fan-free at idle. OEMs would need to do some serious work on cooling to make that work.
Only the MacBook Air is fanless, and of course it throttles after a while, that's why there's the Pro with a fan on the M1
if 7nm Zen3 is close, then 5nm can probably match without a fan.
It’s almost like power efficiency is all about the process node. M1 is 5nm. It’s a great core but it’s power profile would not be so impressive at a larger node.
>Now, if only AMD could bring back that ARM Zen design that they cancelled
Oh yes that would rock and open up a whole new level of fault tolerance as could run real-time upon two different CPU cores in parallel, which for some workloads would add value.
Certainly adding an ARM chiplet would be cool and technically doable, though so would a RISC V core and if Nvidia buy ARM then that choice may become political.
Oh yes that would rock and open up a whole new level of fault tolerance as could run real-time upon two different CPU cores in parallel, which for some workloads would add value.
Certainly adding an ARM chiplet would be cool and technically doable, though so would a RISC V core and if Nvidia buy ARM then that choice may become political.
> if Nvidia buy ARM then that choice may become political.
If? Was that a typo? They have indeed [https://nvidianews.nvidia.com/news/nvidia-to-acquire-arm-for...]
If? Was that a typo? They have indeed [https://nvidianews.nvidia.com/news/nvidia-to-acquire-arm-for...]
Unless changed in the past couple of days - It still needs approval. So be UK, China and USA approval needed of varying degree's. That said, I don't foresee any hurdles, but the ink not been signed yet.
It is super exciting, but when do you think 5800 powered laptops will be widely available? April or May of next year? Close to 6 months after M1 powered machines.
Lately Lenovo has been quite quick releasing AMD variants of Thinkpads. I'd say March or April.
Interesting - what’s the power consumption on it?
Previous gen (4800U) was 15W TDP by default (configurable between 10W and 25W).
This new one (5800U) was not yet officially announced.
This new one (5800U) was not yet officially announced.
Sadly, TDP is far from held on those. What you get at 15W is the base clock present at: https://www.anandtech.com/show/15324/amd-ryzen-4000-mobile-a...
For the Ryzen 7 4800U, that's just 1.8GHz. 4.2GHz which is the turbo clock blows through that limit by a lot. (of course that's for multi-core workloads)
For Ryzen 5th generation, we have this for per-core only power draw, without the I/O: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...
We can see from the graph at https://images.anandtech.com/doci/16214/PerCore-1-5950X_575p... that to reach 6.6W per core, the clock has to fall to 3.8GHz. At such a clock, Zen 3 is way behind the Apple M1 performance wise.
For the Ryzen 7 4800U, that's just 1.8GHz. 4.2GHz which is the turbo clock blows through that limit by a lot. (of course that's for multi-core workloads)
For Ryzen 5th generation, we have this for per-core only power draw, without the I/O: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...
We can see from the graph at https://images.anandtech.com/doci/16214/PerCore-1-5950X_575p... that to reach 6.6W per core, the clock has to fall to 3.8GHz. At such a clock, Zen 3 is way behind the Apple M1 performance wise.
Power consumption is the key factor here.
> In the meantime, it’s almost embarrassing for the rest of the industry just how far ahead Apple’s chips are.
How well is this chip suited for development? E.g. how fast can it do a full parallel compile of (say) gcc, compared to an Intel/AMD machine?
How well is this chip suited for development? E.g. how fast can it do a full parallel compile of (say) gcc, compared to an Intel/AMD machine?
The battery life is just as impressive as the performance.
>After a single build of WebKit, the M1 MacBook Pro had a massive 91% of its battery left. I tried multiple tests here and I could have easily run a full build of WebKit 8-9 times on one charge of the M1 MacBook’s battery. In comparison, I could have gotten through about 3 on the 16” and the 13” 2020 model only had one go in it.
https://techcrunch.com/2020/11/17/yeah-apples-m1-macbook-pro...
>After a single build of WebKit, the M1 MacBook Pro had a massive 91% of its battery left. I tried multiple tests here and I could have easily run a full build of WebKit 8-9 times on one charge of the M1 MacBook’s battery. In comparison, I could have gotten through about 3 on the 16” and the 13” 2020 model only had one go in it.
https://techcrunch.com/2020/11/17/yeah-apples-m1-macbook-pro...
A few days ago, there was a story showing that it was twice as fast to compile Rust compared to the 2019 Macbook Pro: https://news.ycombinator.com/item?id=25126394
Since Rust is LLVM-based, there should be a substantial performance improvement for Clang as well.
Since Rust is LLVM-based, there should be a substantial performance improvement for Clang as well.
Was that a full parallel build (using all available cores)?
Because that's what counts for me, as a developer.
Because that's what counts for me, as a developer.
I believe so, as cargo defaults to the number of cores, as per this issue: https://github.com/rust-lang/cargo/issues/2805
For what it's worth, this guy noticed a nearly 2x speedup in compiling OpenSSL, which is C code, so I assume GCC or Clang: https://twitter.com/sandofsky/status/1331732592958214145
This suggests, though it does not prove, that the performance improvement for code compilation is likely not exclusive to a single language.
For what it's worth, this guy noticed a nearly 2x speedup in compiling OpenSSL, which is C code, so I assume GCC or Clang: https://twitter.com/sandofsky/status/1331732592958214145
This suggests, though it does not prove, that the performance improvement for code compilation is likely not exclusive to a single language.
For my purposes it's nearly twice as fast as my maxed out 2018 MBP for development (6-core i9). This is for projects which are mostly C++ / C / Swift
https://twitter.com/twolivesleft/status/1331932956642852864
https://twitter.com/twolivesleft/status/1331932956642852864
> specialized instructions for x86 translation
That sounds absolutely fascinating. Do you have any references I could read further on that?
That sounds absolutely fascinating. Do you have any references I could read further on that?
They have a special mode for strongly-ordered memory accesses (IBM did something similar on POWER, also for the sake of porting x86 applications).
I'm still not sure that M1 is much of a quantum leap, and I haven't been able to get my hands on one to try it. I went to an Apple Store on Wednesday, but they were unwilling to let me see the device without a shopping appointment (store was empty of customers except for me and one other person). They only let me in the door because I was picking up an online order.
I'm not willing to describe M1 as "untouched" without actually using it in the real world for a couple of weeks.
My question to you is, have you used M1 in the real world for a couple of weeks, or are you basing your comments on the benchmarks that have been published by tech journalists?
I'm not willing to describe M1 as "untouched" without actually using it in the real world for a couple of weeks.
My question to you is, have you used M1 in the real world for a couple of weeks, or are you basing your comments on the benchmarks that have been published by tech journalists?
I don’t have one, but the benchmarks, both synthetic and reports of real world usage, along with the architectural differences, are quite compelling. I don’t think humans are capable of a conspiracy on the scale required to generate this much positive coverage across the board. Even the contrarian takes admit the performance advantages.
What you’re describing at the store is standard procedure for a retail location during the pandemic. Easy enough for you to make a shopping appointment if you’re actually interested.
Personally, I’m holding out for Parallels. I have some Windows-only software that’s required for work; even after Parallels with Windows on ARM64 is available, I’ll have to see about having that software recompiled for ARM64 or if it will run under Microsoft’s x64 emulation in Parallels.
My other Mac is a 2013 Mac Pro that still works fine, but I am curious to compare compiling benchmarks with the new Mini. Maybe by the 2nd gen with more RAM is released, it will be qualified for corp use.
What you’re describing at the store is standard procedure for a retail location during the pandemic. Easy enough for you to make a shopping appointment if you’re actually interested.
Personally, I’m holding out for Parallels. I have some Windows-only software that’s required for work; even after Parallels with Windows on ARM64 is available, I’ll have to see about having that software recompiled for ARM64 or if it will run under Microsoft’s x64 emulation in Parallels.
My other Mac is a 2013 Mac Pro that still works fine, but I am curious to compare compiling benchmarks with the new Mini. Maybe by the 2nd gen with more RAM is released, it will be qualified for corp use.
When Apple, Google, and all ARM based things actually run something other than Angry Birds, Chinese Adware Strange Rope Hero and Pokemon ripoff games for babies with video and malware app adds and closed "walled garden" "app store" ecosystems where you have to pay $10 or more for even an mp3 or video player, let me know. Otherwise all this mysterious "performance" is even more useless than a 75mhz Pentium from 1996. When anyone can actually program for ARM without "licensing fees" also let me know.
Wow what a gross mischaracterization of macOS to say nothing of Android and iOS. If that’s all you think is on the app stores (which is not required on any of these OSes!), then you need to broaden your horizons and look around.
There are lots of great apps on all these platforms that do all kinds of excellent useful stuff.
Regarding programming for ARM, last I checked you can just specify the target architecture in Go or Rust and off it goes. For C and C++, it’s as easy as sudo apt-get install gcc-arm-linux-gnueabihf
If you’re waiting for systems like this that can run FreeBSD, well, you’re in for a wait. How long is the actual point of my post - who knows when hardware of this caliber with open drivers will be available or common.
There are lots of great apps on all these platforms that do all kinds of excellent useful stuff.
Regarding programming for ARM, last I checked you can just specify the target architecture in Go or Rust and off it goes. For C and C++, it’s as easy as sudo apt-get install gcc-arm-linux-gnueabihf
If you’re waiting for systems like this that can run FreeBSD, well, you’re in for a wait. How long is the actual point of my post - who knows when hardware of this caliber with open drivers will be available or common.
Many macOS users don't have a single App Store app installed, or a few free default Apple ones. Don't talk out of your ass please.
Even if Microsoft's x86-64 emulator will be slower than Rosetta2 (and given their different approaches, it likely will), having that run on an ARM Mac will likely still be the best experience for Windows on ARM.
The thing holding back Windows on ARM is one of the key selling points of Windows: all your legacy programs just work. Windows is far, far superior in this over macOS and even Linux [1]. Windows 1.0 apps run on a modern Windows 10 install. For that to be a thing on Windows on ARM, you need high emulation performance. The Snapdragons that Windows on ARM devices come with just are not up to that task at all.
Making Windows on ARM more enjoyable to use and more accessible to developers (which are more likely to have Macs than underpowered niche devices) should really incentivize Microsoft to get Windows to run on ARM Macs at least using virtualization. Virtualization on Apple Macs is solving a supply problem of high performance, reasonably easy to buy hardware for both Microsoft and Linux distros aiming to work well on ARM.
[1]: Although ironically, Wine on Linux/Mac is often even better at running legacy Win32 programs than Windows is. But I digress.
The thing holding back Windows on ARM is one of the key selling points of Windows: all your legacy programs just work. Windows is far, far superior in this over macOS and even Linux [1]. Windows 1.0 apps run on a modern Windows 10 install. For that to be a thing on Windows on ARM, you need high emulation performance. The Snapdragons that Windows on ARM devices come with just are not up to that task at all.
Making Windows on ARM more enjoyable to use and more accessible to developers (which are more likely to have Macs than underpowered niche devices) should really incentivize Microsoft to get Windows to run on ARM Macs at least using virtualization. Virtualization on Apple Macs is solving a supply problem of high performance, reasonably easy to buy hardware for both Microsoft and Linux distros aiming to work well on ARM.
[1]: Although ironically, Wine on Linux/Mac is often even better at running legacy Win32 programs than Windows is. But I digress.
>Even if Microsoft's x86-64 emulator will be slower than Rosetta2
Is there anything stopping MS from copying Apple's approach?
I know Rosetta 1 was technology licenced from Transitive Corporation, is Rosetta 2 completely Apple in-house tech?
Is there anything stopping MS from copying Apple's approach?
I know Rosetta 1 was technology licenced from Transitive Corporation, is Rosetta 2 completely Apple in-house tech?
> Is there anything stopping MS from copying Apple's approach?
One thing I don't completely understand about Rosetta2 is when it performs static recompilation and when it's doing dynamic recompilation. I'm under the impression that a lot of Rosetta2's magic is in static recompilation. I don't know in which cases it statically recompiles and in which cases it dynamically recompiles though. If anyone knows anything about this I'd really like to understand this better.
If my hunch about Rosetta2 focusing largely on static recompilation is correct, Microsoft can't copy this approach easily. Static recompilation is very hard to make reliable. It's probably doable in Apple's use case (doable, definitely not easy), where their only aim was probably to make everything that runs on Intel-based Catalina or Big Sur on Apple Silicon. However, Intel-based 64-bit Windows 10 can (attempt to) run all 32-bit Windows software made since Windows 95. That's a much wider and diverse range of software, and the only approach to make that reliable is to depend on the slower dynamic recompilation.
If my hunch about Rosetta2 is not correct, and it's achieving these performance numbers on pure dynamic recompilation, all I can say is hats off to Apple. Microsoft would do good to pay them a large amount of money to license their tech in that case (or to copy as much of their approach anyway).
One thing I don't completely understand about Rosetta2 is when it performs static recompilation and when it's doing dynamic recompilation. I'm under the impression that a lot of Rosetta2's magic is in static recompilation. I don't know in which cases it statically recompiles and in which cases it dynamically recompiles though. If anyone knows anything about this I'd really like to understand this better.
If my hunch about Rosetta2 focusing largely on static recompilation is correct, Microsoft can't copy this approach easily. Static recompilation is very hard to make reliable. It's probably doable in Apple's use case (doable, definitely not easy), where their only aim was probably to make everything that runs on Intel-based Catalina or Big Sur on Apple Silicon. However, Intel-based 64-bit Windows 10 can (attempt to) run all 32-bit Windows software made since Windows 95. That's a much wider and diverse range of software, and the only approach to make that reliable is to depend on the slower dynamic recompilation.
If my hunch about Rosetta2 is not correct, and it's achieving these performance numbers on pure dynamic recompilation, all I can say is hats off to Apple. Microsoft would do good to pay them a large amount of money to license their tech in that case (or to copy as much of their approach anyway).
It's probably doable because VMware did something very similar about 20 years ago, back before x86 had virtualisation hardware.
That was x86 on x86, but it took a similar level of sophistication then as with cross-architecture "software virtualisation" now to run all 32-bit Windows software, as well as all 16-bit software, other OSes such as Linux, BSD and MS-DOS and Netware, etc.
Considering all the things around like self-modifying code, generated code, thunks etc in Windows and other OSes and applications, VMware did a great job of scanning all code for entry points, intercepting every path that couldn't be executed directly, patching what needed to be patched.
I expect they can revive that approach with cross-architecture translation now, and I would be very surprised if VMware and Parallels are not working on exactly this for x86-on-ARM VMs right now.
That was x86 on x86, but it took a similar level of sophistication then as with cross-architecture "software virtualisation" now to run all 32-bit Windows software, as well as all 16-bit software, other OSes such as Linux, BSD and MS-DOS and Netware, etc.
Considering all the things around like self-modifying code, generated code, thunks etc in Windows and other OSes and applications, VMware did a great job of scanning all code for entry points, intercepting every path that couldn't be executed directly, patching what needed to be patched.
I expect they can revive that approach with cross-architecture translation now, and I would be very surprised if VMware and Parallels are not working on exactly this for x86-on-ARM VMs right now.
I understand that Rosetta 2 uses static recompilation "where possible" and only falls back to dynamic when necessary.
This is purely speculative but I would assume that it statically recompiles the __TEXT segment of binaries or maybe whatever it can easily figure out is code by following all possible jumps, etc.
Then, whenever a page is mapped as executable they could then check if this is part of a memory mapped binary which is statically recompiled or otherwise recompile the code in the page and jump to the now native version.
That way JITs should work without fully falling back to interpreting instructions. Things would get tricky when you map some memory both writable and executable, but maybe they're pushing the limits on what the spec allows for instruction caches? I'd have to check my x86 reference manual. Or maybe this is another area where they have some hardware primitive to facilitate a partial recompilation.
This is purely speculative but I would assume that it statically recompiles the __TEXT segment of binaries or maybe whatever it can easily figure out is code by following all possible jumps, etc.
Then, whenever a page is mapped as executable they could then check if this is part of a memory mapped binary which is statically recompiled or otherwise recompile the code in the page and jump to the now native version.
That way JITs should work without fully falling back to interpreting instructions. Things would get tricky when you map some memory both writable and executable, but maybe they're pushing the limits on what the spec allows for instruction caches? I'd have to check my x86 reference manual. Or maybe this is another area where they have some hardware primitive to facilitate a partial recompilation.
Static translation is, in fact, the simplest to accomplish, and it is time proven as well. This is what IBM have been doing with AS/400 for more than three decades. AS/400 runs on a virtual ISA, and applications are alwyas compiled into the virtual instruction set. Pointers, for instance, have been 128-bit since day 1 (1989 circa). Upon the first startup, virtual instructions are compiled into real CPU instructions, and the recompiled application image is stashed away in a cache. Consequent application restarts use the cached application image. IBM have been using POWER CPU's for the last few generations of AS/400, but they have also used drastically different CPU designs in the past as well. This allows to run applications that had been written in 1991 today, for example.
Dynamic binary translation (a predecessor of modern JIT) is a completely different story, though.
Now, a few years back, Apple introduced iOS app uploads in Bitcode. Bitcode is the LLVM's own intermediate representation of the abstracted LLVM ISA. Apps available in Bitcode, when downloaded, are statically compiled into the ISA of the actual CPU one's iPhone has. Again, apps uploaded in Bitcode in 2018, will run fast and effeciently on iPhone 18 as well. I could immediately draw parallels with AS/400 a few years back when Apple announced the Bitcode availability.
I could not quickly check whether Bitcode was available for OS X apps today as well, but it would be hard to imagine why Apple would not want to extend the approach to the OS X apps as well. This is where it can get really interesting as apps available through the OS X app store in Bitcode, could be developed and compiled on a device running on the Intel ISA, but they could also be statically translated into M1 (M2, M3 etc) ISA at the download time and, at least theoretically, they would not require a separate ARM / M1 app image (or a universal binary for that matter). Unless, of course, the app leans on something x86 specific.
I am on the hunch that the real disruption that Apple has inflicted upon the industry is not just a stupendously fast and power efficient chip (it is very nice but secondary), but the concept of the demise of the importance of hardware ISA's in general – use the intermediate code representation for app binary images and use whatever CPU / hardware ISA that allows to realise the product vision. It is ARM today but it can be anything else 10 years down the road. I wonder who can push the mainstream PC industry in a similar direction and successfully execute it, though.
Dynamic binary translation (a predecessor of modern JIT) is a completely different story, though.
Now, a few years back, Apple introduced iOS app uploads in Bitcode. Bitcode is the LLVM's own intermediate representation of the abstracted LLVM ISA. Apps available in Bitcode, when downloaded, are statically compiled into the ISA of the actual CPU one's iPhone has. Again, apps uploaded in Bitcode in 2018, will run fast and effeciently on iPhone 18 as well. I could immediately draw parallels with AS/400 a few years back when Apple announced the Bitcode availability.
I could not quickly check whether Bitcode was available for OS X apps today as well, but it would be hard to imagine why Apple would not want to extend the approach to the OS X apps as well. This is where it can get really interesting as apps available through the OS X app store in Bitcode, could be developed and compiled on a device running on the Intel ISA, but they could also be statically translated into M1 (M2, M3 etc) ISA at the download time and, at least theoretically, they would not require a separate ARM / M1 app image (or a universal binary for that matter). Unless, of course, the app leans on something x86 specific.
I am on the hunch that the real disruption that Apple has inflicted upon the industry is not just a stupendously fast and power efficient chip (it is very nice but secondary), but the concept of the demise of the importance of hardware ISA's in general – use the intermediate code representation for app binary images and use whatever CPU / hardware ISA that allows to realise the product vision. It is ARM today but it can be anything else 10 years down the road. I wonder who can push the mainstream PC industry in a similar direction and successfully execute it, though.
Bitcode is an IR, but it is not architecture independent, and the code will have been compiled to a particular calling convention. Bitcode may allow Apple to apply different optimization passes for iPhone processors, but it’s not going to be hugely useful for Rosetta.
Bitcode is the bitstream file format used to encode the LLVM IR. LLVM IR itself is architecture independent (unless the code uses inline assembly, which is architecture specific): https://llvm.org/docs/LangRef.html
clang compilers (or other LLVM based language/compiler frontends) generate the LLVM IR, apply optimisation passes and run the LLVM IR through the architecture specific backend that transforms the LLVM IR into the underlying hardware ISA (or into a target ISA when cross-compiling). The original meaning of LLVM was «Low Level Virtual Machine». It is a widespread approach found in many cross-platform / portable compilers, e.g. GNU has RTL.
Here is an example of the «Hello world» using the LLVM IR; there is nothing architecture specific about it:
------
@.str = private unnamed_addr constant [13 x i8] c"Hello World\0A\00", align 1
; Function Attrs: nounwind ssp uwtable
define i32 @main() #0 {
declare i32 @printf(i8*, ...) #1
------
Seamless tranlastion of Bitcode into an Intel or ARM ISA actually works, too: https://www.highcaffeinecontent.com/blog/20190518-Translatin...
Lastly, Bitcode and Rosetta are mutually exclusive. If the app is available in Bitcode, it is run through an optimising hardware ISA backend at the download time and then runs always natively, whereas Rosetta runs existing x86 apps through the static binary translation into ARM first (what Apple refer to as AOT - ahead of the time) and likely uses JIT when the recompiled application is run.
clang compilers (or other LLVM based language/compiler frontends) generate the LLVM IR, apply optimisation passes and run the LLVM IR through the architecture specific backend that transforms the LLVM IR into the underlying hardware ISA (or into a target ISA when cross-compiling). The original meaning of LLVM was «Low Level Virtual Machine». It is a widespread approach found in many cross-platform / portable compilers, e.g. GNU has RTL.
Here is an example of the «Hello world» using the LLVM IR; there is nothing architecture specific about it:
------
@.str = private unnamed_addr constant [13 x i8] c"Hello World\0A\00", align 1
; Function Attrs: nounwind ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1
%2 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([13 x i8]* @.str, i32 0, i32 0))
ret i32 0
declare i32 @printf(i8*, ...) #1
------
Seamless tranlastion of Bitcode into an Intel or ARM ISA actually works, too: https://www.highcaffeinecontent.com/blog/20190518-Translatin...
Lastly, Bitcode and Rosetta are mutually exclusive. If the app is available in Bitcode, it is run through an optimising hardware ISA backend at the download time and then runs always natively, whereas Rosetta runs existing x86 apps through the static binary translation into ARM first (what Apple refer to as AOT - ahead of the time) and likely uses JIT when the recompiled application is run.
Microsoft could easily afford to spend a hundred million dollars on making it work. Bringing up their own processor would be difficult to that degree, but now apple have done it they should be able to do it.
Interestingly, ARM to X86 is probably easier because ARM has a machine readable specification (I don't think Intel or AMD have an equivalent)
Interestingly, ARM to X86 is probably easier because ARM has a machine readable specification (I don't think Intel or AMD have an equivalent)
Technically Rosetta 2 can run 32-bit Windows applications made since Windows 95 as well with CrossOver :)
M1 has instruction-level x86 emulation, so MS would need to convince Qualcomm and MediaTek it was in their interest to add that complexity, and embrace all the legal/technical pitfalls along the way.
> M1 has instruction-level x86 emulation
Source?
Source?
It doesn't. But it does have a strong memory-ordering mode designed to match x86, which is a big help.
Without this mode, multi-threaded ARM code emulating x86 by translation needs to contain a very large number of barrier instructions.
Without this mode, multi-threaded ARM code emulating x86 by translation needs to contain a very large number of barrier instructions.
so, it does? thanks for clarifying!
The emulation is not implemented in the processor, just the memory ordering.
Gotcha, it just emulates the memory ordering? At the instruction level? thank you!
edit: dunno how to feel about getting downvoted into oblivion for this thread, on one hand, it seems really cynical for people to read me as...masterminding some way to make someone smart look foolish?...when I'm legit asking qs - I don't have a CS degree and clearly don't understand some of the formal terms around CPUs, but I'm trying! :)
edit: dunno how to feel about getting downvoted into oblivion for this thread, on one hand, it seems really cynical for people to read me as...masterminding some way to make someone smart look foolish?...when I'm legit asking qs - I don't have a CS degree and clearly don't understand some of the formal terms around CPUs, but I'm trying! :)
I think the downvotes are because of your language.
First, you wrote "M1 has instruction-level x86 emulation" as an authoritative sounding statement, as if it's true.
When you also talked about Qualcomm and MediaTek having to add lots of complexity and deal with legal pitfalls, that added to the idea that you really did mean a full x86 instruction decoder, because that's where the legal pitfalls are expected to be.
But it's false, the M1 doesn't do instruction-level x86 emulation, so that's a minor irritation. Comments don't usually get downvoted over a simple mistake, but they do if it looks like someone is saying something really misleading.
But then in response to being told it doesn't do that, you wrote "so, it does? thanks for clarifying!".
That language read like you were being snarky. The phrasing "so, it does?" in response to a correct "It doesn't." is typical English snark, a way of sounding dismissive and challenging at the same time.
That interpretation invited a downvote.
Once you have been perceived as snarky, following it with "thanks for clarifying!" is doomed to come across as more snark. The exclamation mark makes this worse.
If you are legit just curious, then I think what has happened is you did not understand that "instruction-level x86 emulation" is a very different thing than "memory ordering", stating the former to be something the M1 does is misleading, and you did not realise you had written something that came across as snark.
I'll legit try to explain the difference in case you're interested.
A CPU doing x86 emulation at the instruction level would have the chip decode x86 machine instructions in hardware one by one and perform the operations they describe. The M1 doesn't have hardware to decode x86 though; neither does any other ARM CPU. It could be built, but nobody has, probably for legal reasons not technical reasons.
For memory ordering, we probably wouldn't call it emulation. All multi-core CPUs have a memory ordering model, but different architectures have different models. This means how memory accesses (reads and writes) in programs running on one core are observed by programs on other cores running in parallel and doing memory accesses to the same locations. (On single-core CPUs it is irrelevant because normal CPU cores always observe their own reads and writes in program order.)
It's probably not obvious how memory accesses can be observed out of order. It happens because at some level, reads and writes inside a CPU are not instantaneous. They become messages back and forth with the memory, messages take time to travel, and these messages get even more complicated when there are different kinds of caches all over the place as well. With multiple cores sending and receiving memory messages, each of these taking time to travel, the result is cores see memory messages in a different order from each other. Rather than explain, I'll link to the Wikipedia article: https://en.wikipedia.org/wiki/Memory_ordering
ARM generally has a weak memory model, which means the order of instructions in a program on one core has little effect on the order of memory accesses seen by other cores. This is too weak for some things to work (like locks between parallel threads), so there are also barrier instructions which force all memory accesses before and/or after the barrier to be visible to programs on other cores in the order of instructions, as long as the programs on the other cores also use barriers.
On x86 you don't need barriers, because the ISA is defined (due to the history of CPUs) so that all memory accesses by each core are visible to all the others in the exact order of instructions run by each core. (There are some exceptions but they don't matter). This is a great illusion, because in reality to stay fast there are memory access messages flying around inside the CPU and between the cores and caches, getting out of order in large queues. To maintain the effect as if everything is in order needs a bunch of extra transistors and logic on the chip, to keep track of which messages have to be queued up and waited for before others.
This is why when x86 programs are translated into ARM programs (by Rosetta 2 software), if it's for a multi-threaded program the ARM code needs a lot of barrier instructions all over the place, and these tend to be slow because the chip isn't optimised for lots of barriers.
On the M1, it has a non-standard (for ARM) operating mode where the weak order switches to program order, like x86. For this to work it needs extra logic on the chip. It seems that the M1 doesn't use this extra logic all the time though, only when Rosetta 2 is using it. Probably because it slows things down a bit to turn it on.
So when x86 programs are translated into ARM programs (by Rosetta 2 software) it doesn't need to include lots of barrier instructions. Maybe not any. The resulting code which runs on the M1 is ARM code (not x86 code), but it's special ARM code because if it's run in parallel with other ARM code accessing the same memory on another core, it only runs correctly when the M1 turns on the non-standard program-order memory mode, which slows the CPU a little.
First, you wrote "M1 has instruction-level x86 emulation" as an authoritative sounding statement, as if it's true.
When you also talked about Qualcomm and MediaTek having to add lots of complexity and deal with legal pitfalls, that added to the idea that you really did mean a full x86 instruction decoder, because that's where the legal pitfalls are expected to be.
But it's false, the M1 doesn't do instruction-level x86 emulation, so that's a minor irritation. Comments don't usually get downvoted over a simple mistake, but they do if it looks like someone is saying something really misleading.
But then in response to being told it doesn't do that, you wrote "so, it does? thanks for clarifying!".
That language read like you were being snarky. The phrasing "so, it does?" in response to a correct "It doesn't." is typical English snark, a way of sounding dismissive and challenging at the same time.
That interpretation invited a downvote.
Once you have been perceived as snarky, following it with "thanks for clarifying!" is doomed to come across as more snark. The exclamation mark makes this worse.
If you are legit just curious, then I think what has happened is you did not understand that "instruction-level x86 emulation" is a very different thing than "memory ordering", stating the former to be something the M1 does is misleading, and you did not realise you had written something that came across as snark.
I'll legit try to explain the difference in case you're interested.
A CPU doing x86 emulation at the instruction level would have the chip decode x86 machine instructions in hardware one by one and perform the operations they describe. The M1 doesn't have hardware to decode x86 though; neither does any other ARM CPU. It could be built, but nobody has, probably for legal reasons not technical reasons.
For memory ordering, we probably wouldn't call it emulation. All multi-core CPUs have a memory ordering model, but different architectures have different models. This means how memory accesses (reads and writes) in programs running on one core are observed by programs on other cores running in parallel and doing memory accesses to the same locations. (On single-core CPUs it is irrelevant because normal CPU cores always observe their own reads and writes in program order.)
It's probably not obvious how memory accesses can be observed out of order. It happens because at some level, reads and writes inside a CPU are not instantaneous. They become messages back and forth with the memory, messages take time to travel, and these messages get even more complicated when there are different kinds of caches all over the place as well. With multiple cores sending and receiving memory messages, each of these taking time to travel, the result is cores see memory messages in a different order from each other. Rather than explain, I'll link to the Wikipedia article: https://en.wikipedia.org/wiki/Memory_ordering
ARM generally has a weak memory model, which means the order of instructions in a program on one core has little effect on the order of memory accesses seen by other cores. This is too weak for some things to work (like locks between parallel threads), so there are also barrier instructions which force all memory accesses before and/or after the barrier to be visible to programs on other cores in the order of instructions, as long as the programs on the other cores also use barriers.
On x86 you don't need barriers, because the ISA is defined (due to the history of CPUs) so that all memory accesses by each core are visible to all the others in the exact order of instructions run by each core. (There are some exceptions but they don't matter). This is a great illusion, because in reality to stay fast there are memory access messages flying around inside the CPU and between the cores and caches, getting out of order in large queues. To maintain the effect as if everything is in order needs a bunch of extra transistors and logic on the chip, to keep track of which messages have to be queued up and waited for before others.
This is why when x86 programs are translated into ARM programs (by Rosetta 2 software), if it's for a multi-threaded program the ARM code needs a lot of barrier instructions all over the place, and these tend to be slow because the chip isn't optimised for lots of barriers.
On the M1, it has a non-standard (for ARM) operating mode where the weak order switches to program order, like x86. For this to work it needs extra logic on the chip. It seems that the M1 doesn't use this extra logic all the time though, only when Rosetta 2 is using it. Probably because it slows things down a bit to turn it on.
So when x86 programs are translated into ARM programs (by Rosetta 2 software) it doesn't need to include lots of barrier instructions. Maybe not any. The resulting code which runs on the M1 is ARM code (not x86 code), but it's special ARM code because if it's run in parallel with other ARM code accessing the same memory on another core, it only runs correctly when the M1 turns on the non-standard program-order memory mode, which slows the CPU a little.
The Linux kernel keeps full backward compatibility and you can run old distributions in a container, while Windows dropped 16-bit support on 64-bit and doesn't let you run old userlands on new kernels.
Hopefully also for Linux on both server and desktop side. The M1 as the first powerful ARM consumer device plus the availability of ARM servers in the cloud will hopefully lead to the ARM eco-system breaking out of its mobile stronghold.
So far ARM devices have mostly been quite locked up and hard to install anything else than what was shipped on them.
Until that changes I don't see much point of ARM as it will only erode the PC that we have become accustomed to. I'd much rather live in an x86-only ecosystem than one without choice.
Until that changes I don't see much point of ARM as it will only erode the PC that we have become accustomed to. I'd much rather live in an x86-only ecosystem than one without choice.
The Windows on Arm devices and Arm Macs are not locked down.
(and neither are the Arm Chromebooks by the way too)
(and neither are the Arm Chromebooks by the way too)
> The Windows on Arm devices [...] are not locked down.
https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...
"[...] But for ARM devices, Custom Mode is prohibited: “On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.” [sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: “Disabling Secure [Boot] MUST NOT be possible on ARM systems.” [sic] Between these two requirements, any ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to circumvent secure boot."
https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...
"[...] But for ARM devices, Custom Mode is prohibited: “On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.” [sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: “Disabling Secure [Boot] MUST NOT be possible on ARM systems.” [sic] Between these two requirements, any ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to circumvent secure boot."
This is for 32-bit Arm, back in the Windows RT and Windows Phone days.
This never applied to ARM64 Windows, ever.
This never applied to ARM64 Windows, ever.
Arm Macs are kinda locked down, but that's just for now. We'll see over the next year or so what the community comes up with as far as natively installing Linux goes.
They are not. Locked down = Apple explicitly prevents it through code signing.
Here, Apple doesn't prevent it in any way, and drivers can be developed. (drivers not present in Linux is not and will never mean that a device is locked down, don't stretch things please)
Here, Apple doesn't prevent it in any way, and drivers can be developed. (drivers not present in Linux is not and will never mean that a device is locked down, don't stretch things please)
I see, and having to reverse engineer drivers to be able to run anything else on it to you somehow means that it's open?
Not locked down and open aren't the same things, don't conflate matters/deflect to another thing please.
You're the one who's conflating things. The fact that you somehow think that someone _no longer_ locking you out of their bootloader is now considered open just shows how far we've gone off the rails.
By that definition 99.99% of devices are open because you can just swap out the rom. All you need to do is figure out the pin and wiring and the serial protocols involved in communicating. My ducky keyboard is NOT open even though I replaced the firmware with my own.
What kind of insane logic is that?
And the fact that you and the other person here keeps conflating ANY documentation about ANY part of the hardware as contributing to Linux is even more ridiculous.
By that definition 99.99% of devices are open because you can just swap out the rom. All you need to do is figure out the pin and wiring and the serial protocols involved in communicating. My ducky keyboard is NOT open even though I replaced the firmware with my own.
What kind of insane logic is that?
And the fact that you and the other person here keeps conflating ANY documentation about ANY part of the hardware as contributing to Linux is even more ridiculous.
There were no claims of openness, because the opposite of “locked down” is not “completely open and here are the spec sheets”. Apple silicon devices let you boot your own code, which means they are not locked down, like say your iPhone is.
FWIW, the person you’re responding to is contributing to Linux for this hardware, so I wouldn’t grill them on conflating things ;)
FWIW, the person you’re responding to is contributing to Linux for this hardware, so I wouldn’t grill them on conflating things ;)
I've contributed to linux for the Mac EFI myself, so that argument is moot. We clearly have different understandings of openness. I also wrote a savage driver for mplayer in the early 2000s but just because it was possible to write a driver for it, that doesn't mean the hardware was open in any reasonable sense of the word. Again, just because they decided to allow you to disable secure boot on those devices, probably mainly to drive adoption of their arch, doesn't mean it is any more open than a lock you can pick with your own lockpicking set.
The irony is that the jailbreaking crowd has spend so much time trying to break into apple devices that in comparison this now seems open.
EDIT: Also can we stop pretending that english isn't english and the opposite of locked isn't unlocked/open?
The irony is that the jailbreaking crowd has spend so much time trying to break into apple devices that in comparison this now seems open.
EDIT: Also can we stop pretending that english isn't english and the opposite of locked isn't unlocked/open?
Nobody brought "open" into this discussion other than you. The claim was that this hardware is not locked down, and it is not. I don't think there is much more to say because this computer is literally the definition of not locked down because they give you the key to the lock.
For a very long time, that was the position Linux was in on the desktop. Manufacturers providing drivers, or sufficient info to write them, for Linux, is pretty new, and still not exactly universal.
Windows on Arm devices don't allow you to disable secure boot last time I checked.
That's "locked down" if I can't run a kernel I compile.
That's "locked down" if I can't run a kernel I compile.
What?
Every single one of them does. Just switch to the UEFI Setup and disable Secure Boot.
Note that I'm talking about Arm 64-bit Windows, and not the earlier Windows RT which is dead. Details for Linux for the best-supported Windows on arm64 laptops on that front at: https://github.com/aarch64-laptops/build
Every single one of them does. Just switch to the UEFI Setup and disable Secure Boot.
Note that I'm talking about Arm 64-bit Windows, and not the earlier Windows RT which is dead. Details for Linux for the best-supported Windows on arm64 laptops on that front at: https://github.com/aarch64-laptops/build
As of 2017, they both didn't allow UEFI Secure Boot to be disabled, and didn't allow UEFI Secure Boot to be switched into Custom Mode.
It looks like they walked some of that back at some point.
It looks like they walked some of that back at some point.
They did. Every single Windows on Arm64 system since release allowed Secure Boot to be off.
That limitation only applied on 32-bit Arm systems (Windows RT & Windows 10 Mobile, ARM != ARM64)
That limitation only applied on 32-bit Arm systems (Windows RT & Windows 10 Mobile, ARM != ARM64)
Then that's not "every single one of them", because there are Windows on ARM devices that aren't ARM64.
In many ways that ecosystem for such laptops is already there thanks to Google and Chromebooks, many of which ARM based. So adding a bit more memory and storage and if the Windows fans don't get to bite, be many a Linux folk who would snap up such offerings if the price is right and they certainly could be.
I’m sure you meant inflection rather than infection, but somehow it still works and makes complete sense. :D
Aka an Eggcorn
https://en.m.wikipedia.org/wiki/Eggcorn
https://en.m.wikipedia.org/wiki/Eggcorn
Cool, that's new to me, thanks. "Liberman discussed the case of a woman who substitutes the phrase egg corn for the word acorn, and he argued that the precise phenomenon lacked a name. Pullum suggested using eggcorn itself as a label."
Word.
I'm absolutely for it. The more competition in the space, the better.
I hope recent software advances in ARM by Apple pushes Microsoft to focus more of their efforts in building a competent translation software layer for x86-64 apps (in contrast to their current garbage-ish emulation layer that makes their ARM devices running legacy x86-64 apps nearly unusable, in some cases) like Rosetta 2.
And also hoping those advances by MSFT in turn push Apple to make an even better version of Rosetta 2 (because mainstream x86-64 apps will probably be around at least for the next couple of decades, imo), leading to a 'golden age' of sorts for translation/emulation software.
I hope recent software advances in ARM by Apple pushes Microsoft to focus more of their efforts in building a competent translation software layer for x86-64 apps (in contrast to their current garbage-ish emulation layer that makes their ARM devices running legacy x86-64 apps nearly unusable, in some cases) like Rosetta 2.
And also hoping those advances by MSFT in turn push Apple to make an even better version of Rosetta 2 (because mainstream x86-64 apps will probably be around at least for the next couple of decades, imo), leading to a 'golden age' of sorts for translation/emulation software.
XTAJIT, which is the x86(_64) application compatibility layer on Arm Windows is far from garbage, and got a ton of engineering work.
The problem is that having a 30% performance penalty on a Snapdragon 8cx (because Arm only started really caring about fast CPUs starting from the Cortex-A76, which is the first generation stemming from that effort, resulting in not-ideal perf characteristics for x86 emulation) results in not very good performance. This can only be fixed through better, smarter Arm hardware. (which is coming)
The problem is that having a 30% performance penalty on a Snapdragon 8cx (because Arm only started really caring about fast CPUs starting from the Cortex-A76, which is the first generation stemming from that effort, resulting in not-ideal perf characteristics for x86 emulation) results in not very good performance. This can only be fixed through better, smarter Arm hardware. (which is coming)
That will all depend on chip development. If someone else can get i7 level cpu performance and gtx 1050 level gpu performance at those levels of power consumption then absolutely. I just wonder how much work was being done in that direction before the M1, i.e., are we a year away from seeing an early version, or 3 years? If it's closer to 3, Intel and AMD have some breathing room, or at least enough runway to launch their own similar efforts. (though at this point I seriously doubt Intel's ability to execute, and they are very far down the road of path-dependency in the choices they've made)
First step might be a console using an ARM cpu, which can push gaming adoption, and then windows proper can follow.
Nintendo Switch have been using ARM cpu for 3 years, before that Nintendo 3DS/DS used it too - but much more ancient version.
Also - smartphones use ARM cpus and those have been a mature gaming platform for years. I'd say that a mainstream gaming console based on ARM would not change much, just like Xbox 360, PS3, Wii and Wii U did not cause PowerPC to rise in general popularity,
Also - smartphones use ARM cpus and those have been a mature gaming platform for years. I'd say that a mainstream gaming console based on ARM would not change much, just like Xbox 360, PS3, Wii and Wii U did not cause PowerPC to rise in general popularity,
Nintendo consoles have never had powerful hardware though. It's about the first party IP (Mario, etc.) and not the hardware.
I think gp means a performance-focused console on ARM, not nintendo or mobile.
I think gp means a performance-focused console on ARM, not nintendo or mobile.
> Nintendo consoles have never had powerful hardware though.
Not quite. Their last three consoles (Wii, Wii U, and Switch) were about a generation behind their competition, but the first four (NES, SNES, Nintendo 64, and GameCube) were comparable to their rivals.
Not quite. Their last three consoles (Wii, Wii U, and Switch) were about a generation behind their competition, but the first four (NES, SNES, Nintendo 64, and GameCube) were comparable to their rivals.
Noticed your username, one of my favorite games for C64 as a kid.
[deleted]
So Nvidia's recent acquisition would be a very good move after all?
Of course. No one adopts a new technology in the PC world until Apple gives it social proof. See also: USB, WiFi (didn't hit it big until AirPort became a thing), hiDPI displays, USB-C, etc.
Yeah, remember when the PC world adopted the Intel chips after Apple gave them social proof? Or journaling file systems, or preemptive multitasking, or protected memory, or true multi user support. Apple always leads the way, right?
Most of those techs are not consumer-facing though.
Proper multi-user support (which is something that the iPad still doesn't have at all today...) and a reliable operating system that doesn't crash multiple times a day are definitely customer-facing features.
A fast processor and a machine that doesn't heat up are customer facing too.
A fast processor and a machine that doesn't heat up are customer facing too.
You conflate a deliberate choice with ability. Apple obviously know how to make a multi-user system. They choose not to on the iPad. Totally fine if you ask me. If you want a full rich desktop experience use macOS.
The whole point of iOS is simplicity and ease of use. That is the feature.
The whole point of iOS is simplicity and ease of use. That is the feature.
MacBook Pro can keep you from having children it gets so hot
I kind of get your point but please don't try to say that USB-C wasn't a thing until Apple adopted it. It's absolutely false and Apple was just the lame late adopter. They can't even get it right, in 2020, after everyone else had figured it out: https://www.forbes.com/sites/barrycollins/2020/04/24/why-you...
Apple was the first company that adopted USB-C in a laptop which was 2015 12" Macbook.
"adopted" is a strong word. They dipped their toes.
The Macbook 12-inch had only one port which shows they were totally into it in laptops.
iPhone still not switched to USB-C (maybe they never will) and it is a big mistake for Apple.
iPhone still not switched to USB-C (maybe they never will) and it is a big mistake for Apple.
Some of that may be down to do with the ridiculous press/social media noise that flew around when they change from 30-pin to lightning - once bitten and all of that.
> iPhone still not switched to USB-C (maybe they never will) and it is a big mistake for Apple.
They will have to, the EU will force them.
They will have to, the EU will force them.
Decent chance the next iPhone will go portless and only charge wirelessly. So the EU may not get a chance.
Which will still be nice from a standards perspective, since the iPhone uses the Qi standard.
Which will still be nice from a standards perspective, since the iPhone uses the Qi standard.
iPhone dropped the Qi standard for rates above 7.5 watts:
https://www.theverge.com/2020/10/13/21514850/apple-iphone-12...
https://www.theverge.com/2020/10/13/21514850/apple-iphone-12...
144hz displays, Bluetooth, Ethernet, wireless charging, laptops with touchscreens, pressure-sensitive pen input (the Surface Pen predates the Apple Pencil by three years), optical mice, programmable GPUs...
Pressure sensitive pens is old well established technology. I used it on my old Palm Pilot. Don’t pass that off as a Microsoft innovation. And Microsoft was into that long before there was an iPad with their failed tablet/laptop hybrids, which I actually thought was beginnings of a neat idea.
Palm Pilots didn't have pressure-sensitive pens — at least, not as "pressure-sensitive pens" are commonly defined in modern technological terms. Technically they had "pressure-sensitive screens" in that pressure activated the screen, but you only got one bit of actual pressure information: whether the coordinate was pressed or not. Pressure-sensitive pens used by the Surface and iPad let you vary stroke weight and width by varying the pressure you apply from the pen to the screen, just like applying varying pressure with a real pen or pencil on paper will vary the weight and width of the line you draw. The digital pen pressure is represented as many bits of information — IIRC the original Surface Pen had 1024 bits of pressure sensitivity. Old Palm Pilot screens could be activated by anything capable of applying pressure: even a toothpick would do. A toothpick would just scratch a Surface or an iPad: there's significant technology in the pen itself, and the pen communicates wirelessly with the computer or tablet to transmit pressure data. That's why the Apple Pencil has a separate battery you need to keep charged, for example, as does the Surface Pen. Prior to the Surface, AFAIK the only option for digital artists who wanted pencil-like input was to use external Wacom "tablets" (although those weren't tablets in the modern sense — they were input devices that you'd plug into your computer) or bad knockoffs of Wacom tablets, that had pressure-sensitive pens that worked with their special writing surfaces — and the writing surfaces often even lacked a screen, so you needed to look away from the pen to look at your monitor to see what you were doing (and often with pretty poor pen/screen latency). Eventually Wacom released a monitor that had the writing surface built in, but it was enormous in size, even more enormous in price, and not actually a very good screen — it was just better than looking away from the pen (and it still didn't include the computer). The whole thing was cumbersome.
And it's true that Microsoft didn't invent pressure sensitive pens — Wacom did — but MS did pioneer integrating pressure-sensitive pen systems as part of the computer as opposed to requiring optional add-on hardware like the original Wacoms. Similarly, Apple didn't invent WiFi, or USB, or any of the things the poster I was responding to claimed; they just adopted them and made Apple devices support the technology by default — the claim was "no one adopts a new technology in the PC world until Apple gives it social proof." So: some counterpoints.
(Also, "failed tablet/laptop hybrids"? Pretty sure the Surface hardware hasn't failed — most recent quarterly revenue for the Surface division was about $2 billion. And it spawned a legion of tablet/laptop hybrids in the Windows ecosystem — pretty much every laptop maker for Windows offers a touchscreen laptop, and they're fairly popular. Even Chromebooks often have touchscreens. Apple is way behind on this one.)
And it's true that Microsoft didn't invent pressure sensitive pens — Wacom did — but MS did pioneer integrating pressure-sensitive pen systems as part of the computer as opposed to requiring optional add-on hardware like the original Wacoms. Similarly, Apple didn't invent WiFi, or USB, or any of the things the poster I was responding to claimed; they just adopted them and made Apple devices support the technology by default — the claim was "no one adopts a new technology in the PC world until Apple gives it social proof." So: some counterpoints.
(Also, "failed tablet/laptop hybrids"? Pretty sure the Surface hardware hasn't failed — most recent quarterly revenue for the Surface division was about $2 billion. And it spawned a legion of tablet/laptop hybrids in the Windows ecosystem — pretty much every laptop maker for Windows offers a touchscreen laptop, and they're fairly popular. Even Chromebooks often have touchscreens. Apple is way behind on this one.)
Ah, like FireWire...
[deleted]
Linked from the article is this: https://www.macrumors.com/2020/11/20/craig-federighi-on-wind...
Which makes me wonder: do the new M1 devices support booting alternate OS's in their current form right now? Or are they as locked down as iOS?
Which makes me wonder: do the new M1 devices support booting alternate OS's in their current form right now? Or are they as locked down as iOS?
Boot security on M1 Macs can be disabled entirely, so theoretically they can boot other operating systems. The challenge would be writing drivers.
In the other direction, I wonder when we'll see a full ARM macOS running in QEMU on x86 Windows... I believe this is the only public extent of that effort so far: https://news.ycombinator.com/item?id=25064593
I'm more excited by the related, but even more difficult, running ARM MacOS on ARM QEMU. Being able to virtualize MacOS on other ARM devices will be nice.
I’m curious how much Microsoft’s x86 compatibility layer is able to take advantage of the M1's unique (for an ARM chip) ability to do x86-style total store ordering (https://www.reddit.com/r/hardware/comments/i0mido/apple_sili...), or if it’s something that Microsoft or virtualization vendors could optimize for.
I would suspect the current solution is roughly comparable to the built in Windows performance minus the general hypervisor penalty. But it’s certainly something that could be exposed at the API level and optimized in the future. I’d be really curious to see if Microsoft would let Apple show them up on relative emulation performance. In the old days I’d assume no way... now I kinda think they’d jump at the opportunity to let Apple be their flagship reference hardware.
So please fill a dummy in here....
Does the M1 have a hardware suite for virtualizing x86 instructions? Or is there a software conversion of x86 to ARM going on? Or?
Does the M1 have a hardware suite for virtualizing x86 instructions? Or is there a software conversion of x86 to ARM going on? Or?
This is ARM version of Windows running in virtual machine on ARM hardware. Microsoft uses it on some of their Surface laptops. It has software emulation of x86 instructions on ARM hardware. x64 support is coming soon.
Apple has their own version of such support named Rosetta 2, it uses a combination of static recompilation and emulation to run x64 macOS apps on ARM hardware. Both systems have about 20-40% performance hit when emulating x86/x64 on ARM.
Apple has their own version of such support named Rosetta 2, it uses a combination of static recompilation and emulation to run x64 macOS apps on ARM hardware. Both systems have about 20-40% performance hit when emulating x86/x64 on ARM.
I forgot windows on ARM extended to Win10. Right; the new CPUs on Surfaces are MS ARM chips.
Most new Surface devices are Intel. Surface Pro X is ARM.
Windows for Arm runs on ARM (and emulates x86 to run win32 apps).
I personally find current implications and use cases a bit niche, and the current hype suggesting the M1 is pitching a no-hitter a bit dubious.
For one, it only supports 16GB or RAM ATM. That's.. Not a lot. Maybe they only did it for batter life. Maybe they will allow more in the future. But you can only get an M1 with what Apple sells you, and the future means comparing to what's available from AMD and Intel at that time as well.
No support for discrete GPU. They have some onboard support for ML workloads(which might actually be inflating their benchmark numbers a bit) but it's only comparable to entry level GPUs apparently(sub 200).
Most reviews seem overly focused on Geekbench results and seem very lacking in intensive real world workloads(like photoshop, after effects, etc etc). Cinabench seems to tell a different story ATM. The latest top-end AMD mobile CPUs seem to smoke it on multi-core perf. And the new 5800U is not far off in single or multi-core perf. Will need to wait and see how real world perf actually compares across the board.
Overall I see this as a first step with some impressive FUTURE implications for the industry, but it's not putting all the competition in its shadow. Apple will have flexibility controlling their chip designs and, perhaps more importantly, they stand to save billions moving away from Intel. It's telling though that the M1 is limited to the 13" MBP ATM, and I'd give it a pass for my current processing needs. Squarely in early adopter zone.
For one, it only supports 16GB or RAM ATM. That's.. Not a lot. Maybe they only did it for batter life. Maybe they will allow more in the future. But you can only get an M1 with what Apple sells you, and the future means comparing to what's available from AMD and Intel at that time as well.
No support for discrete GPU. They have some onboard support for ML workloads(which might actually be inflating their benchmark numbers a bit) but it's only comparable to entry level GPUs apparently(sub 200).
Most reviews seem overly focused on Geekbench results and seem very lacking in intensive real world workloads(like photoshop, after effects, etc etc). Cinabench seems to tell a different story ATM. The latest top-end AMD mobile CPUs seem to smoke it on multi-core perf. And the new 5800U is not far off in single or multi-core perf. Will need to wait and see how real world perf actually compares across the board.
Overall I see this as a first step with some impressive FUTURE implications for the industry, but it's not putting all the competition in its shadow. Apple will have flexibility controlling their chip designs and, perhaps more importantly, they stand to save billions moving away from Intel. It's telling though that the M1 is limited to the 13" MBP ATM, and I'd give it a pass for my current processing needs. Squarely in early adopter zone.
The best real world example Ive heard of so far is rendering an 8K video on a MacBook on just battery power. Base MacBook Pro with M1 did it and used 17% of its battery, intel MacBook Pro couldn’t get through the render before its battery was 100% depleted. I can’t link to it as it was discussed on the ATP podcast but those guys are pretty good sources.
> For one, it only supports 16GB or RAM ATM. That's.. Not a lot. Maybe they only did it for batter life. Maybe they will allow more in the future. But you can only get an M1 with what Apple sells you, and the future means comparing to what's available from AMD and Intel at that time as well.
This is my main concern. I’m still on the edge about getting an M1 device since I plan on mainly using it for iOS stuff and casual usage and have plenty of PCs for my hacking ventures, but I’m used to having 64GB and would hate to join the ranks of people who complain about Electron ;)
This is my main concern. I’m still on the edge about getting an M1 device since I plan on mainly using it for iOS stuff and casual usage and have plenty of PCs for my hacking ventures, but I’m used to having 64GB and would hate to join the ranks of people who complain about Electron ;)
Tests show you get excellent performance even with just 8 GB because at this point the hard drive access is almost fast enough to be RAM.
On RAM: This is their low end chip; there will likely be another chip within a year supporting more ram. Nevertheless, there are reports from programmers and video editors that suggest that the 16 GB on M1 go a lot further than 16 GB on Intel. No hard technical reasons on why that would be.
(Also, anecdotally, I don't understand why HN keeps saying 16GB of RAM isn't a lot. I just upgraded my home desktop to 16 GB, and only because I also upgraded my screen from 1080 to 1440, and videogames were dipping below 60fps. Sure, at work my desktop has much more RAM, but for a laptop? 16 GB seems fine.)
On GPU: There's been some speculation that the eGPU's don't work due to driver support, not hardware issues. Once again, I wouldn't be surprised if the higher end chips in 2021 have a dedicated GPU inside the Pro and Mini.
On real world workloads: See the above about anecdotes about programmers and video editors. I don't know if there's any great sources here besides reading twitter and trying to avoid biased fanboys.
I'm waiting for more of the languages and tools I use to become fully supported on the M1 before I bite the bullet, but I'm finding fewer and fewer reasons to be skeptical of the performance numbers...
(Also, anecdotally, I don't understand why HN keeps saying 16GB of RAM isn't a lot. I just upgraded my home desktop to 16 GB, and only because I also upgraded my screen from 1080 to 1440, and videogames were dipping below 60fps. Sure, at work my desktop has much more RAM, but for a laptop? 16 GB seems fine.)
On GPU: There's been some speculation that the eGPU's don't work due to driver support, not hardware issues. Once again, I wouldn't be surprised if the higher end chips in 2021 have a dedicated GPU inside the Pro and Mini.
On real world workloads: See the above about anecdotes about programmers and video editors. I don't know if there's any great sources here besides reading twitter and trying to avoid biased fanboys.
I'm waiting for more of the languages and tools I use to become fully supported on the M1 before I bite the bullet, but I'm finding fewer and fewer reasons to be skeptical of the performance numbers...
I have heard that the difference comes from software. Apple endorses a reference counting garbage collector, whereas many windows programs (.NET programs for example) use a tracing garbage collector.
In result, native macos (and ios) programs need less memory. As macOS is also built on the same memory discipline, it is more memory efficient.
In result, native macos (and ios) programs need less memory. As macOS is also built on the same memory discipline, it is more memory efficient.
The arguments you mention have been done to death already online.
Oh? All I've seen is a lot of oohs and aahs for M1. The level of hype is so over the top as to seem almost inorganic, considering how hard it is to test the device before buying it under present conditions. Just my honest take on what I've seen on HN and other places.
Yes the hype is over the top with all sort of wrong / misinformation spread all over the place including on HN.
But most of those mentioned; Photoshop, Video Editing, and even Code compiling has been well tested already.
But most of those mentioned; Photoshop, Video Editing, and even Code compiling has been well tested already.
I’m just glad that both Apple and AMD are taking Intel to task in the laptop CPU world.
Ryzen 5800u - on TSMC 5nm - might be better than M1, let's not forget the new generation of process that Apple has paid for.
The Ryzen 5800U is all but confirmed to still be on TSMC 7nm. The Zen3 desktop counterparts are also still on 7nm. There's a good chance it'll be 2022 before we see AMD chips on 5nm unfortunately, almost certainly for mobile chips.
Having said that, the 5800U might not be too far off the M1 in raw performance even on the older process. AMD's improvements on the same node for Zen3 are pretty good!
Having said that, the 5800U might not be too far off the M1 in raw performance even on the older process. AMD's improvements on the same node for Zen3 are pretty good!
According to Geekbench 5:
AMD 5800U (7nm), single-core 1421, multi-core 6450
Apple M1 (5nm), single-core 1613, multi-core 6489
https://browser.geekbench.com/v5/cpu/compare/5021403?baselin...
Note that a large part of the M1 multi-core score is due to advantages in Machine Learning and AES-XTS. Without those it would be behind AMD's processor and I don't see ML or AES being relevant for most users.
Makes me wonder what will be AMD's 5nm performance.
AMD 5800U (7nm), single-core 1421, multi-core 6450
Apple M1 (5nm), single-core 1613, multi-core 6489
https://browser.geekbench.com/v5/cpu/compare/5021403?baselin...
Note that a large part of the M1 multi-core score is due to advantages in Machine Learning and AES-XTS. Without those it would be behind AMD's processor and I don't see ML or AES being relevant for most users.
Makes me wonder what will be AMD's 5nm performance.
That's a slow M1 machine, probably due to background tasks running shortly after setup. M1's are more like 1720-1750 single core, 7500-7600 multicore
https://browser.geekbench.com/v5/cpu/compare/5021923?baselin...
You picked one of the odd outliers for the M1 (background activity running at the same time as the benchmark?).
You picked one of the odd outliers for the M1 (background activity running at the same time as the benchmark?).
The best cherrypicking you could do still showed AMD losing. Why bother?
It might be equal in CPU performance but the M1 has significantly better GPU perf, and also only uses 10W total!
Ryzen narrowly beats M1 due to 60% higher clock frequency. Apple is avoiding clicking M1 that high to save power and reduce Heath. This at similar clock frequency and watt usage there would not be much competition. Ryzen would get destroyed.
I'm more interested in what the other CPU makers come up with, or if there will be some other competition not from AMD or Intel. Not that x86 isn't great, but it seems that this is a leap forward that can't be ignored.
I thought QEMU was supposed to be quite inferior in performance to KVM (though more flexible). Is that not the case? The link in the article just directed to the QEMU homepage.
KVM is the kernel virtualization module on Linux, QEMU handles the userland side support, all device emulation. The kvm binary on Linux is equivalent to running qemu-system-* with -enable-kvm. Newer versions of QEMU also support the '-accel kvm' argument but also adds other acceleration backends, such as '-accel tcg' (slower), '-accel haxm' (Intel/Windows), and finally '-accel hvf' for Apple's Hypervisor.Framework. This work here is extending that existing support from only Intel VT-x to also cover ARM Silicon, factoring out common code and API differences made by Apple.
By default, QEMU uses emulation which will be slow. Qemu can also use an "accelerator" such as KVM. See https://www.qemu.org/docs/master/system/invocation.html#hxto...
e.g. I can do this on my Raspberry Pi 4 running 64-bit Raspberry Pi OS.
e.g. I can do this on my Raspberry Pi 4 running 64-bit Raspberry Pi OS.
qemu-system-aarch64 \
-M virt,accel=kvm -cpu host -m 2G -smp 2 -nographic \
-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
-cdrom alpine-virt-3.12.0-aarch64.isoOn e Microsoft licensed or somehow it can be run, the migration completed. No nvidia but that would be another problem.
I will be happy when I hear another OS running natively on them. Great hardware but terrible platform.
I agree. As a Linux user, I hope we don't get left in the dust if Windows and Apple both decide to go down the ARM route.
But still no dual boot? I tried using vitalized windows on my macbook before, keyboard/mouse control was super frustrating. I ran into stupid issues all the time.
I’m looking forward to it!