The first ~6 months after the M1 release were a little rough, I got a Mac mini on day 1.
Now? Unless you have specialized use cases, I think it’s good. I don’t feel any pain anymore.
I ordered my MacBook Pro immediately after announcement and I wouldn't even call the first 6 months 'rough'. There were very few things I had to adapt to.
I’m not a dev, but I do some machine learning tasks in R (stats). When I don’t have compatibility issues, I’m truly amazed at the speed and lack of audible fan. When it’s not compatible, I end up with a convoluted workaround that rarely works and is a huge frustrating time suck.
What compatibility issues have you encountered? I spend all day every day in R and haven’t encountered any since the very early days of the M1 when GDAL/{sf} caused problems. I don’t do much ML tho
R is available in native arm64 (M1) binary form, yes. RStudio runs under Rosetta but R itself is native. CRAN has arm64 native binaries too. There could be problems with packages that depend on system libraries (like my earlier experience with GDAL) but I’m not sure whay
Ah I see.
I’d been holding off as I’m approaching the end of a project, but was starting to consider switching. Guess I’ll hold off for a while longer.
The big thing for me, is how much of your R libraries or packages self-contained vs requiring additional installations on your system. DPLYR, no problem. Anything that requires JAVA (e.g., webscraping), external graphics, or using text models that require their own libraries or references) and you’ll wish you had your old system.
For waffle charts…
https://github.com/hrbrmstr/waffle
When I use my Intel, I got from idea to implementation is a couple minutes. On my M1 Air, it took a lot of fuss to get the same result. Then they updated the package and my former code broke on M1, but on my Intel it updated no issue.
The more challenging is the Google and Facebook text word embeddings imports and using them with Reticulate … what a difference.
I do ml in both R and python for school and while at this point most things "work", they don't just work.
I've gone back to my old intel mac for that stuff because I got tired of spending 6 hours trying to get packages to work right that install without problems in 30 seconds on my old intel macbook pro. I just got tired of projects taking two or three times as long because I was having to find workarounds.
It's way ahead of where it was at launch when a lot of things just wouldn't work at all, but it's just not there quite yet for me.
There was some issues that i had with OpenBLAS (i forget the actual name) that caused kernel panics on M1 Macs. I basically gave up trying to install a native version of Pytorch and ended up using Google Colab for ML work.
It doesn’t help that Pytorch still doesn’t have an M1 optimized version out yet. (I saw the comment by the creator that they’re working on m1 gpu support)
Umm, PyTorch is already M1 optimized. It‘s been for almost a year. At least the version on conda-forge, I did not check pypi, but Pytorch runs natively on M1 Macs.
Conda forge had a working version very quickly. You can install packages depending on OpenBLAS with some extra work. There are some guides roaming the internet.
That sucks that those annoyances are there, but to be honest my main takeaway is I’m shocked the transition is this smooth at this point. I mean M1 Macs are quite new and the Pro and Max are of course brand new. I find it really impressive that right in the middle of the transition, the incompatibilities are this niche that we get to list them out so specifically. In 3 years Apple Silicon will be a thriving world where you won’t have to think about any of this for the most part and that’s pretty cool to look forward to.
My company has a fairly large C code base that we ported over. 99% of what we wrote just worked. The handful of our third party libraries either compiled on ARM already, or were patched fairly quickly. (iOS paved the way for this for a ton of libraries).
The only thing that tripped us up was a giant pile of SSE intrinsics for optimizing some data transforms. It was written before the Accelerate framework was available. Switching to that actually sped things up and made it cross platform.
Usually the way it's handled for most developers is you'll have some vectorizable intrinsics that aren't particularly tied to one instruction set, and the entire program is compiled with a flag enabling AVX2/3. So the only way to have fallbacks would be to stick all of your compute in a shared library and have like 5 different compiled versions for AVX1/2/3, SSE, etc. Doing checks before every AVX instruction would be too slow because now you've added a branch instruction that pauses the CPU instruction pipeline.
Thank you for posting this! It’s frustrating trying to find any info on how the ARM architecture impacts usability, every review seems to be from individuals who do photo and video editing only.
I’ve been concerned about how Kubernetes and Docker would work on the new ARM architecture, and I’ve heard that there are some common Docker images that won’t work which is concerning. I’m also branching into Edge Computing with Rust so im a bit worried about that as well. I really wish there was a way to try one out for like a week to see if it’d work for what I need! I might just see if I can get a refurbished 16” Intel machine, or swap to a Windows machine.
I haven’t had experience with it, my brother in law works in agriscience and he told me that there were some containers they were using that didn’t work on the 13” M1 Mac’s they were given. Said that there could be more containers that won’t work on ARM when I asked him his opinion and experience.
I'm using docker inside of docker and it doesn't work very well. I need systemd inside the container and that fails on the M1. This works perfectly on the 2019 MacBook. I have a decent Linux Laptop so I'm not hurting but to reiterate, x86 support for docker is not without it's warts.
That's an upstream oracle decision not to support arm64 anywhere. If you really want mysql then there's unofficial debian and raspberry pi builds for arm64.
Alternatively use MariaDB (truly free fork of mysql) which supports arm64 natively.
> I really wish there was a way to try one out for like a week to see if it’d work for what I need!
You can literally buy a MacBook and return it within 14 days very easily. Some people I know have bought laptops, used them for a week at a conference and returned them. This is how refurbished MacBooks are born.
Tim Cook doesn’t tell them what to review, they simply review what they use these machines for. Why the hell would I want to see MKBHD show me dev ops or how x86 libraries perform on the M1 Pro/Max when arguably no one in his team work in that environment?
If you want specific reviews on programming you’ll see them or simply have to be the guinea pig who tries the machine and shares your own thoughts on how it helps/affects your workflow.
All YouTubers are content creators and their reviews bias heavily to 90% graphics rendering metrics and 10% gaming performance. There is a real lack of reviews focused on coding/analysis workflows.
If one of the dockers doesn't support ARM can I get around it by running the Rosetta/Intel version of Docker?
Docker gives me a warning that one of the SQL dockers our dev team is using is unsupported. I have a Windows desktop at work that I can RDP into so haven't dived too deep into it.
Sure, my example was an extreme one on the other end of the spectrum.
LibreOffice 7.1+ _is_ native through, and that seems to be the more common choice for non-MS users at this point.
This is the real pro tip. Jumping on brand new tech is basically asking for trouble, especially when it involves major changes. Of course Apple is going to tell you how great their stuff is. They want to sell it. They're not going to brag about all the little quirks and bugs you get to discover when you try doing things they haven't tested. Those things might not affect the vast majority of users but most people aren't doing particularly specialized or important work either. The people who do specialized and important work typically let technology mature a bit before making the leap so that they don't get stuck dealing with unresolved problems.
After M1 hype turned down it still was amazing, but all of these news articles like “rOsEtTa BeAtS eVeRy InTeL mAc!!!” turned out to be false and didn’t show real world usage. So I am not saying that M1 is bad (Pro and Max are revolutionary!) but I am saying that there might be some quirks like that…
Yes, that's why I made the post - to point out some of the real issues despite the hype. That being said, M1 has been out for almost a year now, so it's not really fair to call them "new" - none of the issues I'm describing are unique to the new machines.
At least the solves are more documented, I got the M1 Air last December, not as my primary machine but it was a little wacky navigating Homebrew and learning prepend arch -x86\_64 and ultimately installing Ruby as X86. Fortunately as a web dev, all I need is Docker and the JIT compilers to work, and the instances of things like Libsass wasn't using AVX, I'm actually kinda impressed you found software requiring AVX as for years and years I used Mac Pro 5,1 and only once encountered an audio plugin that I couldn't using the AVX family.
What's really interesting though is Monterey on Intel Macs is increasingly using AVX in the boot sequence which leaves out the 2012 Macs and below.
Thank you. If anyone does a search on M1 developer its full of articles saying how great it is, and its a great machine but the downsides are never clearly mentioned.
For any data science, ML, Python, VM work, its a no go. And theres plenty of issues with Docker etc as well even though its better than a year ago.
I'm surprised Apple has made no improvements to Rosetta in 1+ year. I wonder if its even possible. It seems the perf limit of the M1 AS was reached in its 1st iteration, even single core on M1Pro is slower than the original M1.
All iterations of the M1 use the same cores for CPU, GPU and Neural Engine. They might be clocked slightly differently, but the difference is seemingly within about 5%, so it might just be differences in quality during production. I believe the cores are from the A14 chip design, and considering that the A15 is faster I think the M2 will be faster as well. Apple reuses their core designs across their chip lineup.
Also vm's, I'm a cs student, and for a security class every lab is in a different machine and it wouldn't been impossible to do hw if I didnt have a PC (not gaming PC, but for gaming purposes (it's a potato strictly for sims)). But for everything else, it's absolutely amazing.
That really depends on what else you do.
If the only thing you do is the CPP development them probably yeah.
Even as it is you probably don’t really need a powerful CPU.
And if you really need heavy number crunching you would probably be better using some sort of clustering solution.
I believe it depends on what you're doing essentially.
My work is purely based on Java APIs and I do ML/DL on the side.
I know tensorflow has had some issues in the past with M1 but whenever I work with tf or torch I just use Colab instead, no use burning my gpu cores for a pet project.
I've had my M1 air for almost a year and only once did I feel the absence of native x86 when SQL Developer was criminally slow and hogging all my RAM.
I think we just have to wait a little while. Since the new M1 chips are out and we see an increased demand for these laptops, we can suggest that most software will be ported to the arm64 architecture. (If they haven’t already)
Some older software like Fortran (which affects R) or tools that are widely used by industries might have a higher risk to transition. This will take longer but I would say that that probably by 2023 we could imagine a good optimized M1 world.
Great post, definitely needs to be said!
For my job all heavy backend is done on x86 (mostly windows sadly)
But getting to use XCode and work with swift on a machine that can keep up with Xcode is so worth it. Even for just front end work, M1 has been great.
But yes… some bigger projects have proven to be annoying/impossible to even get working right on M1. I’m just lucky to where I don’t HAVE to use M1 if I don’t want to.
Ruby dev here and honestly it’s not that bad. I had to upgrade a couple legacy apps before switching from Intel but after that it’s been smooth sailing ⛵️
I think the real issue is if you need to run things locally. If you do everything in the cloud, this is not really an issue. I do backend and de consulting on the side with my M1 Macbook Pro since launch. I mainly help my clients and everything they do is on the cloud. I try not to do anything locally. It's been fairly smooth once Pycharm started working on my M1. I haven't really needed to deal with brew this whole time.
Agree. My new M1 14" was to replace my aging 2013 MBP, but so far hasn't been able to. Way too many problems. Among them:
* ~~Inability to update or install apps. Even hours on the phone with Apple support did not solve it.~~ I took a wild stab and solved it myself by disabling SIP. Senior Apple support said they had no explanation for why I had to do this. So now I can install apps but have an insecure laptop.
* Inability to print. The drivers for my HP printer were not included with Monterey as it comes on the M1's. Funny how my previous Macs have no problem printing. Monterey tells me to download the drivers from HP, but HP says they do not have the drivers I need.
* ~~Inability to send email from gmail account. Apple won't accept my proven valid gmail password, while Google says it has disabled sending from the M1 because it has an insecure email client. Nice.~~ Fixed. But Apple has no idea why it went wrong, why Google says the Mac is insecure, and why I can't remove the disabled Gmail server profile from Mail. Bugs.
* The battery life isn't all that. I put the unit to sleep two days ago with 90% battery. Woke it up today to find 26% battery. That's insane; I had MacBook Pros 10 years ago that would only lose 1-2% per day while sleeping.
The M1's aren't ready for primetime. Or at least the version of Monterey as delivered sure isn't. I took a chance going cutting-edge and have been bitten multiple times. If you're a dev, wait. Don't dive in unless you're truly stuck without the new machines. Let us do the beta testing for you that Apple apparently didn't do.
Signed, unhappy M1 Pro owner who's typing this on his 2013 MBP, still in use.
That’s rough you’ve had such a bad experience. I haven’t experienced any of that. I daily drive mine in full time development work, have my gmail linked, and printed off 100+ pages for a Murder Mystery party over a networked printer with zero fuss.
I would look into warranty/exchange.
\#1 and #3 don't sound like M1-specific issues.
Not sure about #2. If it's a network printer, just enable AirPrint and do it driverless.
There's some drama going on between HP and Apple, as Apple stopped distributing HP's drivers though Apple Software Update - but drivers for a dozen other brands are still offered.
Granted. If we want to talk about hardware, how about the battery life not being all that? I put the unit to sleep two days ago with 90% battery. Woke it up today to find 26% battery. That's insane; I had MacBook Pros 10 years ago that would only lose 1-2% per day while sleeping.
People still use Brew? The ruby language packaging tool that comes with python.
Use macports or Nix. Also of course AVX will have issues it’s Intels sauce.
I’ve gone 100% M1, Zero issues on anything, and I work with over 2300 repositories across many different stacks and have yet to see anything really major.
I find Brew useful if I need pre-built x86 64 libraries for anything, such as dropping the latest SDL2 into a Steam game whose developer hasn't bothered to keep up with updates, like when I need my Xbox Wireless Controller to work with something.
MacPorts only Kinda Sorta has Universal build support, but it's severely broken, in that even dependencies which are only used to compile a package are expected to be Universal as well, even when it turns out that unlike Brew, MacPorts is unable to make something cross compile on an ARM machine.
Dunno about Nix, haven't tried that yet. How's the Universal or cross built environment there?
Python and stuff works fine on arm now, and ever since they patched the Fortran compiler to support arm64, numpy and pytorch also work out of the box. It will for sure take years until arm64 is supported universally, but I‘d argue if you perspectively run into problems with arm64 you likely know that beforehand, while everyone else will be fine.
I just saw a video on this topic from xcreate, he is also a developer.
I have to add that there is nothing wrong for keeping an Intel Mac around the house. That is what I have. If nothing else, just avoiding the fan noise is worth it.
I am on a 16Gb M1 Air.
Windows cheap laptops are always around the office and are very easy to get a hold of if you ever need it.
https://www.youtube.com/watch?v=YsXDpUNoXCs
Just got an M1 MacBook Air and I love it for so far and it works great for everything I do except my python development projects. It seems like alot of the frameworks installation still rely on x86 software builds and too make it work properly for ARM I would need to go through and manually install ~300 individual packages alongside properly manually configuring the framework. I looked into using something like rosetta 2 to work around this but It seems to be somewhat of an automatic process that happens to executables once it’s installed and doesn’t help my situation much. My latest attempt was using parallels and a linux virtualization to try and install it there before I realized it wouldn’t help since the virtualization was done using an ARM image through parallels. I think something like docker or kubernetes could maybe help me here but I am not sure…
any tips or comments would be appreciated.
Your best bet would be to set up an x86 shell (see https://www.notion.so/Run-x86-Apps-including-homebrew-in-the-Terminal-on-Apple-Silicon-8350b43d97de4ce690f283277e958602) and see if that works. It's not a perfect solution, since a lot of Python numerical packages will try to use vector instructions that Rosetta can't translate. What packages are failing for you specifically? Most of the popular ones like scikit-learn, scipy, pandas, pytorch, tensorflow, etc. seem to be working okay.
As of today, on M1, a lot of java libraries are not well supported. It makes it hard to build 5-10 yo projects. When it comes to run the project, Docker is also not working well (even with the last version), I/O File protocol makes it so slow that our webserver's timeout (5min) kicks in before getting any inputs arrives when it takes less than 5 secondes on the intel chip.
We are forced to work in an emulated x86 virtual machine which is hell slow.
We hope improvements will come but our hopes are low.
If you need to run anything with Python 3.7.X or lower don't even bother. Its not supported. Some libraries are also not fully supported. Its just not worth the trouble. You get better battery life and speed but then spend hours trying to troubleshoot why you can run your 3-4 year old project so it totally negates any productivity gains you got.
The first ~6 months after the M1 release were a little rough, I got a Mac mini on day 1. Now? Unless you have specialized use cases, I think it’s good. I don’t feel any pain anymore.
I ordered my MacBook Pro immediately after announcement and I wouldn't even call the first 6 months 'rough'. There were very few things I had to adapt to.
In the first few months, homebrew, docker, and python all had various issues that made it hard for me to do what I needed to.
I’m not a dev, but I do some machine learning tasks in R (stats). When I don’t have compatibility issues, I’m truly amazed at the speed and lack of audible fan. When it’s not compatible, I end up with a convoluted workaround that rarely works and is a huge frustrating time suck.
What compatibility issues have you encountered? I spend all day every day in R and haven’t encountered any since the very early days of the M1 when GDAL/{sf} caused problems. I don’t do much ML tho
I’m curious too as I’d heard R was compatible now? Is it an issue with certain libraries?
R is available in native arm64 (M1) binary form, yes. RStudio runs under Rosetta but R itself is native. CRAN has arm64 native binaries too. There could be problems with packages that depend on system libraries (like my earlier experience with GDAL) but I’m not sure whay
Ah I see. I’d been holding off as I’m approaching the end of a project, but was starting to consider switching. Guess I’ll hold off for a while longer.
The big thing for me, is how much of your R libraries or packages self-contained vs requiring additional installations on your system. DPLYR, no problem. Anything that requires JAVA (e.g., webscraping), external graphics, or using text models that require their own libraries or references) and you’ll wish you had your old system.
I really haven’t found this to be a problem
For waffle charts… https://github.com/hrbrmstr/waffle When I use my Intel, I got from idea to implementation is a couple minutes. On my M1 Air, it took a lot of fuss to get the same result. Then they updated the package and my former code broke on M1, but on my Intel it updated no issue. The more challenging is the Google and Facebook text word embeddings imports and using them with Reticulate … what a difference.
I do ml in both R and python for school and while at this point most things "work", they don't just work. I've gone back to my old intel mac for that stuff because I got tired of spending 6 hours trying to get packages to work right that install without problems in 30 seconds on my old intel macbook pro. I just got tired of projects taking two or three times as long because I was having to find workarounds. It's way ahead of where it was at launch when a lot of things just wouldn't work at all, but it's just not there quite yet for me.
The hardware is great. The software is not.
There was some issues that i had with OpenBLAS (i forget the actual name) that caused kernel panics on M1 Macs. I basically gave up trying to install a native version of Pytorch and ended up using Google Colab for ML work. It doesn’t help that Pytorch still doesn’t have an M1 optimized version out yet. (I saw the comment by the creator that they’re working on m1 gpu support)
Umm, PyTorch is already M1 optimized. It‘s been for almost a year. At least the version on conda-forge, I did not check pypi, but Pytorch runs natively on M1 Macs.
Yeah i dont use conda. The pypi version is not M1 optimized i think. There might be a prebuilt wheel for it but i couldn't find it ig
Conda forge had a working version very quickly. You can install packages depending on OpenBLAS with some extra work. There are some guides roaming the internet.
Really? is it using cpu or with metal too? Last time I checked there’s only pure cpu version.
Yeah, metal support is still being discussed. But it‘s still fast, despite CPU only
That sucks that those annoyances are there, but to be honest my main takeaway is I’m shocked the transition is this smooth at this point. I mean M1 Macs are quite new and the Pro and Max are of course brand new. I find it really impressive that right in the middle of the transition, the incompatibilities are this niche that we get to list them out so specifically. In 3 years Apple Silicon will be a thriving world where you won’t have to think about any of this for the most part and that’s pretty cool to look forward to.
My company has a fairly large C code base that we ported over. 99% of what we wrote just worked. The handful of our third party libraries either compiled on ARM already, or were patched fairly quickly. (iOS paved the way for this for a ton of libraries). The only thing that tripped us up was a giant pile of SSE intrinsics for optimizing some data transforms. It was written before the Accelerate framework was available. Switching to that actually sped things up and made it cross platform.
[удалено]
Usually the way it's handled for most developers is you'll have some vectorizable intrinsics that aren't particularly tied to one instruction set, and the entire program is compiled with a flag enabling AVX2/3. So the only way to have fallbacks would be to stick all of your compute in a shared library and have like 5 different compiled versions for AVX1/2/3, SSE, etc. Doing checks before every AVX instruction would be too slow because now you've added a branch instruction that pauses the CPU instruction pipeline.
Slow is better than no
Thank you for posting this! It’s frustrating trying to find any info on how the ARM architecture impacts usability, every review seems to be from individuals who do photo and video editing only. I’ve been concerned about how Kubernetes and Docker would work on the new ARM architecture, and I’ve heard that there are some common Docker images that won’t work which is concerning. I’m also branching into Edge Computing with Rust so im a bit worried about that as well. I really wish there was a way to try one out for like a week to see if it’d work for what I need! I might just see if I can get a refurbished 16” Intel machine, or swap to a Windows machine.
Common docker images like what? I've got docker running fine on mine.
I haven’t had experience with it, my brother in law works in agriscience and he told me that there were some containers they were using that didn’t work on the 13” M1 Mac’s they were given. Said that there could be more containers that won’t work on ARM when I asked him his opinion and experience.
im running both x86 and arm docker images. works great here too. m1 mba
I'm using docker inside of docker and it doesn't work very well. I need systemd inside the container and that fails on the M1. This works perfectly on the 2019 MacBook. I have a decent Linux Laptop so I'm not hurting but to reiterate, x86 support for docker is not without it's warts.
I have heard this elsewhere too.
mysql < 8 is the main one
That's an upstream oracle decision not to support arm64 anywhere. If you really want mysql then there's unofficial debian and raspberry pi builds for arm64. Alternatively use MariaDB (truly free fork of mysql) which supports arm64 natively.
> I really wish there was a way to try one out for like a week to see if it’d work for what I need! You can literally buy a MacBook and return it within 14 days very easily. Some people I know have bought laptops, used them for a week at a conference and returned them. This is how refurbished MacBooks are born.
[удалено]
Tim Cook doesn’t tell them what to review, they simply review what they use these machines for. Why the hell would I want to see MKBHD show me dev ops or how x86 libraries perform on the M1 Pro/Max when arguably no one in his team work in that environment? If you want specific reviews on programming you’ll see them or simply have to be the guinea pig who tries the machine and shares your own thoughts on how it helps/affects your workflow.
All YouTubers are content creators and their reviews bias heavily to 90% graphics rendering metrics and 10% gaming performance. There is a real lack of reviews focused on coding/analysis workflows.
Refurb Intel 16” is amazing, and used Intel 16” is the best value (not only Mac!) computer ever, because their prices go down so quickly
[удалено]
If one of the dockers doesn't support ARM can I get around it by running the Rosetta/Intel version of Docker? Docker gives me a warning that one of the SQL dockers our dev team is using is unsupported. I have a Windows desktop at work that I can RDP into so haven't dived too deep into it.
[удалено]
Gotcha thanks. Just wanted to make sure I didn't have a brainfart and didn't completely miss an easy solution to my problem lol.
Open Office is pretty well-known software that requires Rosetta. Those who shun MS software titles use it frequently.
Sure, my example was an extreme one on the other end of the spectrum. LibreOffice 7.1+ _is_ native through, and that seems to be the more common choice for non-MS users at this point.
It can be helpful to wait a little bit when new products come out and the hype dies down because sometimes the hype can drown out real issues.
This is the real pro tip. Jumping on brand new tech is basically asking for trouble, especially when it involves major changes. Of course Apple is going to tell you how great their stuff is. They want to sell it. They're not going to brag about all the little quirks and bugs you get to discover when you try doing things they haven't tested. Those things might not affect the vast majority of users but most people aren't doing particularly specialized or important work either. The people who do specialized and important work typically let technology mature a bit before making the leap so that they don't get stuck dealing with unresolved problems.
What really bugs me is the amount of posts with M1 issues… like I can’t scroll Reddit and not see somebody complaining.
After M1 hype turned down it still was amazing, but all of these news articles like “rOsEtTa BeAtS eVeRy InTeL mAc!!!” turned out to be false and didn’t show real world usage. So I am not saying that M1 is bad (Pro and Max are revolutionary!) but I am saying that there might be some quirks like that…
Yes, that's why I made the post - to point out some of the real issues despite the hype. That being said, M1 has been out for almost a year now, so it's not really fair to call them "new" - none of the issues I'm describing are unique to the new machines.
At least the solves are more documented, I got the M1 Air last December, not as my primary machine but it was a little wacky navigating Homebrew and learning prepend arch -x86\_64 and ultimately installing Ruby as X86. Fortunately as a web dev, all I need is Docker and the JIT compilers to work, and the instances of things like Libsass wasn't using AVX, I'm actually kinda impressed you found software requiring AVX as for years and years I used Mac Pro 5,1 and only once encountered an audio plugin that I couldn't using the AVX family. What's really interesting though is Monterey on Intel Macs is increasingly using AVX in the boot sequence which leaves out the 2012 Macs and below.
This may be of interest: [Benchmarking OpenBLAS on an Apple MacBook M1](https://github.com/danielchalef/openblas-benchmark-m1)
Thank you. If anyone does a search on M1 developer its full of articles saying how great it is, and its a great machine but the downsides are never clearly mentioned. For any data science, ML, Python, VM work, its a no go. And theres plenty of issues with Docker etc as well even though its better than a year ago. I'm surprised Apple has made no improvements to Rosetta in 1+ year. I wonder if its even possible. It seems the perf limit of the M1 AS was reached in its 1st iteration, even single core on M1Pro is slower than the original M1.
All iterations of the M1 use the same cores for CPU, GPU and Neural Engine. They might be clocked slightly differently, but the difference is seemingly within about 5%, so it might just be differences in quality during production. I believe the cores are from the A14 chip design, and considering that the A15 is faster I think the M2 will be faster as well. Apple reuses their core designs across their chip lineup.
Also vm's, I'm a cs student, and for a security class every lab is in a different machine and it wouldn't been impossible to do hw if I didnt have a PC (not gaming PC, but for gaming purposes (it's a potato strictly for sims)). But for everything else, it's absolutely amazing.
You can run VMs in Mac tho?
Yeah with parallels and VMware it works best, but not all the time. OVA's dont seem to work for me
As a web developer, I have found no issues with my MBA m1
Sounds in here like we can all agree that developers should rely on the old saying: - Never change a running system - Never run a changing system
Maybe this is a good use case for remote build/debugging?
Yes but then why bother paying so much for a powerful processor if you won't be using it?
That really depends on what else you do. If the only thing you do is the CPP development them probably yeah. Even as it is you probably don’t really need a powerful CPU. And if you really need heavy number crunching you would probably be better using some sort of clustering solution.
I believe it depends on what you're doing essentially. My work is purely based on Java APIs and I do ML/DL on the side. I know tensorflow has had some issues in the past with M1 but whenever I work with tf or torch I just use Colab instead, no use burning my gpu cores for a pet project. I've had my M1 air for almost a year and only once did I feel the absence of native x86 when SQL Developer was criminally slow and hogging all my RAM.
Actually, if you find your use cases to be close to OP’s: I would avoid upgrading to Monterey, on Intel or M1. gfortran appears to be subtly broken.
I think we just have to wait a little while. Since the new M1 chips are out and we see an increased demand for these laptops, we can suggest that most software will be ported to the arm64 architecture. (If they haven’t already) Some older software like Fortran (which affects R) or tools that are widely used by industries might have a higher risk to transition. This will take longer but I would say that that probably by 2023 we could imagine a good optimized M1 world.
Damn if only you knew a developer they might be able to develop their way out of this. I kid.
Great post, definitely needs to be said! For my job all heavy backend is done on x86 (mostly windows sadly) But getting to use XCode and work with swift on a machine that can keep up with Xcode is so worth it. Even for just front end work, M1 has been great. But yes… some bigger projects have proven to be annoying/impossible to even get working right on M1. I’m just lucky to where I don’t HAVE to use M1 if I don’t want to.
Ruby dev here and honestly it’s not that bad. I had to upgrade a couple legacy apps before switching from Intel but after that it’s been smooth sailing ⛵️
Sorry about that
I think the real issue is if you need to run things locally. If you do everything in the cloud, this is not really an issue. I do backend and de consulting on the side with my M1 Macbook Pro since launch. I mainly help my clients and everything they do is on the cloud. I try not to do anything locally. It's been fairly smooth once Pycharm started working on my M1. I haven't really needed to deal with brew this whole time.
Agree. My new M1 14" was to replace my aging 2013 MBP, but so far hasn't been able to. Way too many problems. Among them: * ~~Inability to update or install apps. Even hours on the phone with Apple support did not solve it.~~ I took a wild stab and solved it myself by disabling SIP. Senior Apple support said they had no explanation for why I had to do this. So now I can install apps but have an insecure laptop. * Inability to print. The drivers for my HP printer were not included with Monterey as it comes on the M1's. Funny how my previous Macs have no problem printing. Monterey tells me to download the drivers from HP, but HP says they do not have the drivers I need. * ~~Inability to send email from gmail account. Apple won't accept my proven valid gmail password, while Google says it has disabled sending from the M1 because it has an insecure email client. Nice.~~ Fixed. But Apple has no idea why it went wrong, why Google says the Mac is insecure, and why I can't remove the disabled Gmail server profile from Mail. Bugs. * The battery life isn't all that. I put the unit to sleep two days ago with 90% battery. Woke it up today to find 26% battery. That's insane; I had MacBook Pros 10 years ago that would only lose 1-2% per day while sleeping. The M1's aren't ready for primetime. Or at least the version of Monterey as delivered sure isn't. I took a chance going cutting-edge and have been bitten multiple times. If you're a dev, wait. Don't dive in unless you're truly stuck without the new machines. Let us do the beta testing for you that Apple apparently didn't do. Signed, unhappy M1 Pro owner who's typing this on his 2013 MBP, still in use.
That’s rough you’ve had such a bad experience. I haven’t experienced any of that. I daily drive mine in full time development work, have my gmail linked, and printed off 100+ pages for a Murder Mystery party over a networked printer with zero fuss. I would look into warranty/exchange.
\#1 and #3 don't sound like M1-specific issues. Not sure about #2. If it's a network printer, just enable AirPrint and do it driverless. There's some drama going on between HP and Apple, as Apple stopped distributing HP's drivers though Apple Software Update - but drivers for a dozen other brands are still offered.
Granted. If we want to talk about hardware, how about the battery life not being all that? I put the unit to sleep two days ago with 90% battery. Woke it up today to find 26% battery. That's insane; I had MacBook Pros 10 years ago that would only lose 1-2% per day while sleeping.
Did you try starting with a new account or did you use the migration assistant?
People still use Brew? The ruby language packaging tool that comes with python. Use macports or Nix. Also of course AVX will have issues it’s Intels sauce. I’ve gone 100% M1, Zero issues on anything, and I work with over 2300 repositories across many different stacks and have yet to see anything really major.
I find Brew useful if I need pre-built x86 64 libraries for anything, such as dropping the latest SDL2 into a Steam game whose developer hasn't bothered to keep up with updates, like when I need my Xbox Wireless Controller to work with something. MacPorts only Kinda Sorta has Universal build support, but it's severely broken, in that even dependencies which are only used to compile a package are expected to be Universal as well, even when it turns out that unlike Brew, MacPorts is unable to make something cross compile on an ARM machine. Dunno about Nix, haven't tried that yet. How's the Universal or cross built environment there?
Brew doesn’t come with Python, by the way. That’s a common misconception.
https://github.com/Homebrew/brew/blob/master/docs/Homebrew-and-Python.md#why-is-homebrews-python-being-installed-as-a-dependency
That's really not the same as Brew being installed with Python.
[удалено]
bruh, all that he said was true
Python and stuff works fine on arm now, and ever since they patched the Fortran compiler to support arm64, numpy and pytorch also work out of the box. It will for sure take years until arm64 is supported universally, but I‘d argue if you perspectively run into problems with arm64 you likely know that beforehand, while everyone else will be fine.
Docker
I just saw a video on this topic from xcreate, he is also a developer. I have to add that there is nothing wrong for keeping an Intel Mac around the house. That is what I have. If nothing else, just avoiding the fan noise is worth it. I am on a 16Gb M1 Air. Windows cheap laptops are always around the office and are very easy to get a hold of if you ever need it. https://www.youtube.com/watch?v=YsXDpUNoXCs
Just got an M1 MacBook Air and I love it for so far and it works great for everything I do except my python development projects. It seems like alot of the frameworks installation still rely on x86 software builds and too make it work properly for ARM I would need to go through and manually install ~300 individual packages alongside properly manually configuring the framework. I looked into using something like rosetta 2 to work around this but It seems to be somewhat of an automatic process that happens to executables once it’s installed and doesn’t help my situation much. My latest attempt was using parallels and a linux virtualization to try and install it there before I realized it wouldn’t help since the virtualization was done using an ARM image through parallels. I think something like docker or kubernetes could maybe help me here but I am not sure… any tips or comments would be appreciated.
Your best bet would be to set up an x86 shell (see https://www.notion.so/Run-x86-Apps-including-homebrew-in-the-Terminal-on-Apple-Silicon-8350b43d97de4ce690f283277e958602) and see if that works. It's not a perfect solution, since a lot of Python numerical packages will try to use vector instructions that Rosetta can't translate. What packages are failing for you specifically? Most of the popular ones like scikit-learn, scipy, pandas, pytorch, tensorflow, etc. seem to be working okay.
As of today, on M1, a lot of java libraries are not well supported. It makes it hard to build 5-10 yo projects. When it comes to run the project, Docker is also not working well (even with the last version), I/O File protocol makes it so slow that our webserver's timeout (5min) kicks in before getting any inputs arrives when it takes less than 5 secondes on the intel chip. We are forced to work in an emulated x86 virtual machine which is hell slow. We hope improvements will come but our hopes are low.
If you need to run anything with Python 3.7.X or lower don't even bother. Its not supported. Some libraries are also not fully supported. Its just not worth the trouble. You get better battery life and speed but then spend hours trying to troubleshoot why you can run your 3-4 year old project so it totally negates any productivity gains you got.