Is MATLAB supported on Apple Silicon Macs?

Macs with an Apple silicon processor such as the Apple M1 have two ways to run applications. Applications built for Apple silicon run natively, while apps built for Intel processors run in the Rosetta 2 environment. Which method does MATLAB support? 

Answer 1

[MathWorks Support Team]

Natively

As of R2023b, MATLAB will run natively on Apple Silicon. 

For more information on how to install and run MATLAB natively on Apple Silicon--including system requirements and supported products--please refer to this resource page.

 

Rosetta 2 

MATLAB R2020b Update 3 and later are supported on Apple silicon Macs through the Rosetta 2 translation environment. Earlier releases of MATLAB may run but are not fully supported. 

Note: There are two products which are available on Intel-based Macs but are not compatible with the Rosetta 2 environment: Polyspace and Simulink Desktop Real-Time. These products are not supported for Apple Silicon Macs. 

[cr]

@MathWorksSupportTeam

When will Matlab for native M1 be available? Sharing some kind of outlook would be immensely helpful in making better decisions.

[Mohammad Sami]

For the optimized versions, would MATLAB be use the built in neural engine and machine learning accelerator for the deep learning toolbox and statistics and machine learning toolbox?

[Walter Roberson]

Developer Transition Kit was announced June 22, 2020, which was two days into Summer. Some developers received it about June 28, 2020 or June 29, 2020 https://9to5mac.com/2020/06/29/first-benchmarks-surface-for-apples-arm-based-developer-transition-kit/

So if "last summer" refers to the summer most immediately past, then Yes, it was available to developers "since last summer".

The R2020b Pre-Release was available to MATLAB beta test users no later than June 10, 2020.... which was before Apple Silicon became available. Mathworks policy is that after a pre-release has been made available to customers, that bug fixes may be made, and new features under trial may be removed before actual release, but that no new features may go in: internal Mathworks developers who do not have their features ready for external testing by the internal cut-off date have to wait for the next release (or at least an Update), even if the feature becomes internally ready even just a few days later.

The official R2020b release date was September 16, 2020. The official release date of the Apple M1 to consumers was September 17, 2020.

Thus, there was no realistic chance that Mathworks would have added Apple Silicon support to the R2020b release.

[Bruno Luong]

Release 3 is already available since few days (for Windows). You might need you check with Help->Check for Update

[Walter Roberson]

R2020b already has ARM support -- through Rosetta2 .

[Rik]

I doubt you will get anything more than speculation. Mathworks will probably mention it in the release notes for the prerelease (note that in general that would be under NDA).

[LeChat]

Will Matlab next version enable GPU acceleration on Apple silicon? Will the Deep Learning and Image processing toolboxes take advantage of the M1 integrated GPUs and neural engine?

[Rik]

@LeChat Mathworks generally doesn't discuss plans for the future in public (you could contact support, who will either refuse to talk specifics, or offer an NDA). Some next version of Matlab will probably enable GPU acceleration on Apple ARM chips, but I doubt R2021b will be that version. As R2021a is only working through Rosetta 2, I expect full support of more niche features (i.e. everything except the base product) will take a while.

[Walter Roberson]

"Will Matlab next version enable GPU acceleration on Apple silicon?"

No. Do not expect that for numerous years. Mathworks only supports Nvidia CUDA, and would have to completely redesign its gpu acceleration tool chain for anything else.

Mathworks goes where the market is, and research work is currently mostly on Nvidia, with second place in the market being IBM, and AMD based development far behind those two. Apple M1 development is comparatively small at the moment, and has no support for Windows or Linux. When Mathworks finally diversifies GPU it would make more sense for it to go after IBM (researchers) or AMD (commonly installed on desktops and laptops) before going after M1.

[LeChat]

Thank you both for your answers and views on Mathworks perspectives. For the mac users (actually with Intel cpu and latest macOS, or M1+ Silicon chips), do you know if it is possible to use a eGPU just for Matlab? I know Nvidia gpu drivers are not available in the latest MacOS versions anymore, and that nvidia gpus are not Metal compatible, but is there a built-in matlab support for a Nvidia eGPU option, so that the OS uses the integrated gpu of the computer while Matlab uses the eGPU acceleration?

[Walter Roberson]

There is no built-in support for egpu. MATLAB just uses whatever drivers are available

[Walter Roberson]

Also, the M1 requires Big Sur (or later), but there is no NVIDIA eGPU support for Big Sur, as Apple made it difficult to add shared drivers other than those approved by Apple -- and Apple apparently won't approve any eGPU drivers that are not designed for Metal.

[Walter Roberson]

Well, 7 months if you count from the time that the M1 became available to consumers. One release has happened, and it improved the M1 performance and made more of it native. There will not be another release until close to the September equinox.

You should have a look, by the way, at Microsoft's efforts to implement for ARM. Their 64 bit OS for ARM barely works at present, and has not reached "beta" level.

[Rik]

@Sangjae They will probably not make any public statements prior to updating this answer. Any definitive answer will probably be very short term (e.g. in the release notes of a prerelease). I would not expect it for R2021b.

[Royi Avital]

@Walter Roberson, What do you mean beta for Windows on ARM. Windows on ARM was 64 Bit from day one (If I rememeber correctly). You mean x64 Bit Emulation which is in the testing. This is emulation of x64 on 64 Bit ARM (Equivalent to Rosetta 2).

[Walter Roberson]

@Royi Avital

You are correct to make a distinction between the operating system (which would potentially have been all compiled for native work) and the x64 emulation. Potentially the operating system might be more stable than the emulation.

However... the review sites that I looked at back in April all said that the operating system itself was unstable as well, even when running programs that had been compiled for ARM. It is true, though, that the x64 emulation was cited as being significantly worse than the x86 emulation.

Either way, the point stands that Microsoft's ARM implementation is notably behind Apple's ARM implementation in terms of being able to run MATLAB with any hope of stability.

[Walter Roberson]

jiayi su:

The official release date of the Apple M1 to consumers was September 17, 2020, which was the day after the R2020b release. Mathworks has had one release since then, R2021a.

R2021b is expected to be released within the next two weeks (my guess is that will be either today or tomorrow.)

[Walter Roberson]

@jiayi su as I predicted R2021b was released the same day.

[Walter Roberson]

@Stanislas Grare

I am presently not aware of any method to tell which parts are M1 native.

For whatever it is worth, when I use the tool at https://github.com/DigiDNA/Silicon then no part of MATLAB is reported as being a Universal binary.

I do not know if that is the same thing as saying that nothing is implemented in Native.

[Bruno Luong]

??? Is there any benefit to deploy partial native M1 code ? Is it even possible ?

[Rik]

@Walter Roberson can you find an official date for the release? I edited the Wikipedia entries based on your comment, but I can only find pages dated 2021/09/23 with mentions of R2021b (so I'm now changing those dates).

2021/09/22 18:06 (GMT): es.mathworks.com still has R2021a

2021/09/23 11:04 (GMT): www.mathworks.com updated to R2021b

The Bing cache doesn't report the time in the header (the d= doesn't seem to be in any date format I can parse), but it mentions being from 2021/09/23 and still has R2021a on the www homepage.

[Steven Lord]

Release R2021b was released to the website the evening of September 22nd Eastern time. That could have been the morning of September 23rd in GMT.

So what you consider the "official date" for the release depends where you are. I would call it September 22nd as that's when it was released in the time zone where MathWorks HQ is located.

[Rik]

I just didn't expect it would be released in the evening of the HQ time zone. I'm a bit surprised that the only dates mentioned anywhere are 'September 2021'. I guess it is in line with how general the release date is phrased beforehand, but I find the insistance on avoiding exact dates a bit odd. Or is that just my neuroticism and completionism?

[Walter Roberson]

Mathworks does not commit to exact release dates in advance. They have internal deadlines for various aspects such as go/no-go on new features, but after that it is "as soon as all the parts are ready". That can include time to iron out priority problems identified during testing.

Documentation such as release notes and advertisements cannot be finalized until all of the go/no-go decisions are made.

Software testing usually involves assuming that all features will be released, so if any features are withdrawn then additional software testing is required.

Historically, it also included a wait period for the final software version to be pressed onto DVD, as the new version is available for physical order on day of release.

The last several years, releases have never been before 1730 Eastern time the day of release. After, that is, peak site usage for the day.

[Andrew Janke]

Totally unofficial answer here, but:

Don't expect a fully native M1/Apple Silicon Matlab build any time soon. Most of the number crunching stuff in Matlab is built on BLAS, a serious numeric library with multiple implementations. The BLAS implementation Matlab (currently) uses is the Intel Math Kernel Library ("MKL"). The ETA for an ARM port of the Intel MKL to be released is, uh, never, because MKL is a proprietary product whose whole purpose is to make Intel CPUs more useful (and thus sellable), and ARM is a competitor. (MKL doesn't even play nice with AMD x64 chips sometimes!)

So to get a full-native Apple Silicon build of Matlab working, MathWorks is going to have to do something like add support for OpenBLAS or Apple Accelerate as alternate BLAS implementation libraries, and then validate all of Matlab and all its toolboxes against that, and add compatibility shims for where the behavior of MKL and OpenBLAS differs, and then support that forever. (Plus any non-BLAS Matlab internals optimized with x64 assembly, and the External Interfaces stuff for however Python and Java and whatever work under Apple Silicon, and the Matlab Installer system which now has another degree of freedom to deal with, and probably more stuff that's not occurring to me.)

If the word "nontrivial" popped in to your head while reading that, your brain is working right!

I hope they do the work to do this, though. The M1 seems to be a kickass CPU, and well suited for numerics and scientific programming due to the high memory bandwidth of the new MacBook Pros.

[Andrew Janke]

Also I dunno if shipping Mac Matlab as Universal x64/M1 binaries is a great option? A full Matlab installation is already 10+ GB; Universalizing it would probably balloon that. My poor disk, especially for those of us who are running multiple versions of Matlab under multiple VMs on the same box.

[cr]

I too have observed that Matlab strangly keeps processor busy drawing power even when it's pretty much idle. It doesn't happen immediately upon launch, but after I do some runs and leave it. Even clear all close all don't help and I have to relaunch Matlab.

[Walter Roberson]

@Wenqiang CHEN

All that is known publicly is that R2021b is not native M1 for any part of it.

What we know as MATLAB has a small number of interacting programs.

• MATLAB itself
• the help browser
• the MuPAD symbolic engine
• PolySpace
• (I think) Simulink

There might be a few others.

For Native M1 use, each of the above could in theory be converted independently, but all of each of them needs to be done at the same time. You cannot, for example, leave the Automated Driving Toolbox for later when you convert MATLAB, but you might be able to leave Simulink for later in the first version (I am not certain of this.)

Mathworks will soon be offering beta versions of the forthcoming R2022a release. I have no information about M1 status for R2022a beta. But I also would not be permitted to talk about it if I did know something, so if you are eligible for beta testing, you should watch for R2022a pre-release becoming available.

[Walter Roberson]

@Jan Theiss

That is a matter that is currently under Non Disclosure Agreement. If you contact your sales person, they might be willing to enter a non-disclosure agreement with you and tell you about the plans.

[Rik]

There are two main points contributing to the date at which this is ready: expected performance gain and user base.

From what I understand, the performance gain is real, but that will only show in longer/larger computations. Rosetta 2 seems fast enough to be a reasonable semi-permanent solution from what I gather.

According to this informal poll, about 13% of users use Apple products. It would be interesting to have a break-down of the people on M1, but I expect that to be <1% of the Matlab user base (a wild guess based on how long Apple has been selling ARM-powered computers).

Now, if you were a commercial company, would you drop everything else to work on converting your entire code base for a small(?) benifit for less than 1% of your customers? Or would you task a small team to do it? Obviously Mathworks chose the second option. It will be ready when it is ready. I expect Mathworks to choose a time table that makes the most commercial sense. If they publish it next year, that would be another year where the market share of Apple ARM can continue to grow, increasing the return on investment.

I don't know about serious difficulties. Maybe there are, maybe there aren't. Maybe the team working on this is too small to get it done in 15 months. Matlab is pretty big after all.

[Rik]

@Spencer Kraisler

"Also Ric, if I were a commerical company, I would think hard about what the future computer industry will look like."

My name is right there. The c and the k are not close together on any keyboard layout I'm aware of.

"ARM is proving to be better than x86 each day, AMD is releasing better GPUs than Nvidia, and many mac users are switching to mx chips."

ARM CPUs tend to be more effecient and I expect the market share to increase further. NVidia is still releasing cards with better performance than AMD. So unless you're using a different definition for 'better' in these two sentences, you're simply incorrect. Many Mac users are indeed switching, but the market share is still small. If it were any other situation, I don't think Mathworks would have bothered, given a working translation layer.

"I love Matlab, but if Matlab is too passive on staying up-to-date with the best hardware, users will inevitably switch to alternatives that do. Julia already has a great beta, and C++ and Python already have native support (even GPU). Not to mention Julia, C++, and Python are in some ways faster than Matlab, and free."

Open source projects have the opportunity to be cutting edge everywhere. Mathworks needs it to be reliable. They don't need to set trends, only follow them. I don't think this thread would be the best place to discuss this matter though.

This probably isn't a good comparison, but you might want to take a look at what GNU Octave supports. There are efforts to have Octave working at all on Mac.

I don't always agree with the choices Mathworks makes (and to make it clear: I don't work for them, my only connection with them is that I'm a customer, I'm active on this forum, and have participated in some user interviews). In this case however, I completely understand the pace. In a few years when Apple-ARM gets a reasonable markte share, nobody will care anymore that it took a few releases.

[Walter Roberson]

@Rik

On the other hand, Mathworks started to lose customers because R2020a did not have full native M1 support, including GPU support. R2020a was released before the M1 series was available to anyone outside of Apple. R2020b was released the day before The Apple M1 series became available to the public, about 3 months after registered developers could get systems. People were complaining about the lack of native M1 support for MATLAB for their developer's systems.

[Walter Roberson]

I am not sure if that is the same as Mathworks Fuzzy Logic Toolbox? Unfortunately none of the Mathworks toolboxes are ready for the beta as yet.

[Bruno Luong]

Do python and and octave support native M1 ?

[Paul]

TMW blog post on the subject for anyone interested.

[Rik]

Octave is hardly supported on Mac in the first place. It works through homebrew. Updates are sparse for that branch of the project, so it is much less of an alternative than on Linux or Windows.

[Walter Roberson]

@Patrick Dondl

There will be another, improved, beta; I have not been told the release date, though.

[Walter Roberson]

I expect to hear dates later this week. I will ask whether I will be able to reveal them.

[Walter Roberson]

I will find out more soon

[Walter Roberson]

@법수 김

I was told "within a few weeks", nothing more precise.

[Walter Roberson]

@Luke OConnor

Unfortunately the post from Mathworks announcing the earlier Open Beta seems to have been removed.

In that announcement, Mathworks made it clear that the Open Beta was pure MATLAB only, with no toolboxes, and that there would be additional open beta with more functionality. I am told the second beta will be available "within a few weeks".

It might be disappointing that R2022b does not support Apple Silicon natively, but Mathworks was clear in the spring that R2022b was not going to be fully native.

Back in 2021, I publicly predicted it would be R2023b before the fully native version including Polyspace was released. I am not longer confident that Polyspace will be ready by then.

[Walter Roberson]

Unfortunately I have not heard anything more.

[Paul]

New TMW Blog Post on this topic

Answer 2

[Annie Leonhart]

All you need to do to make it work is go to "show package content" Matlab/xxxx/bin/maci64/matlabwindow.app that's pretty much it. Click that and it'll run. Nothing special you need to do. Create an alias on your dock.

Been using 2020b for weeks with 0 issues. Runs just as good as it does on PC. Fully functional.

Answer 3

[cr]

UPDATE 1: Text comparison tool in R2019b not working on M1 mac. Got the following error popup.

[cr]

Yes, the issue still exists. But since MW has already said versions prior to 2020b, update3 are not supported, there is no point opening a ticket.

Answer 4

[cr]

Matlab for AppleSilicon beta is out for testing.

https://in.mathworks.com/support/apple-silicon-r2022a-beta.html

[Bruno Luong]

benchmark result please.

Answer 5

[Mike Croucher]

Blog post on this topic at Exploring the MATLAB beta for Native Apple Silicon » The MATLAB Blog - MATLAB & Simulink (mathworks.com)

Answer 6

[cr]

I cannot believe the results (below) I'm seeing on my MBP-M1 with R2019b. R2018a showed slower benchmarks as expected for Matlab running with Rosetta especially on graphics front. But strangely R2019b is zipping fast.

Results on R2019b, connected to power and no peripherals.

Out of curiosity, I connected an external monitor whose resolution is only somewhat lower than MBPs (2560x1080) and re-ran bench. Graphics seemed way faster, like running Matlab on Intel. The results are incredible.

Results on external monitor:

[Walter Roberson]

Thanks for the benchmarks, cr !

[cr]

Walter,

Any thoughts on the performance jump from 2018a to 2019b?

Thanks.

[Bruno Luong]

IIRC you can't easily compare bench between versions.

The algo itself change, the bench tests change, then reference machine change.

[Walter Roberson]

True, when you look at the release notes, every few releases it will take note that bench() has been revised. Mostly it is revised to make it "harder", which makes it less sensitive to timing noise as hardware gets fast enough that small differences in short completion times could bias the computations badly.

[Bruno Luong]

Already reported. None with update 3 though.

Answer 7

[cr]

Depends on version. MW has said 2020b v3 and later will work on M1 through Rosetta. There might still be issues to iron out. Late prior versions work with some quirks. See some earlier comments in this thread.