MATLAB & Simulink R2009a beta for 64-bit Intel-based Macs is available
By Brian Arnold at Mon, Mar 30 2009 8:00am |
The native MathWorks MATLAB R2009a beta for 64-bit Intel-based Macs is now available.
Customers who have a subscription to MathWorks Software Maintenance Service may download the professional version. The current target release for 64-bit Mac is R2009b.
For more information including the download link, qualifications and system requirements, please read the updated FAQ here:
http://www.mathworks.com/support/faq/macintel64.html
Comments
scipy
Ahem. Scipy has been available natively for mac intel for ages. Why do people still bother to use Matlab? Beats me.
still using X11?
Is this version STILL using X11?
This would be like them shipping as 16 bit Windows 3.1 application for Vista.
Its embarrassment that they still can not ship a native Mac version, well it pretty much just shows their level of commitment to the Mac platform.
What MATLAB is today
Thank you for your feedback.
Despite its many shortcomings, the number of customers and the relative percentage of customers on the Mac OS X platform both continue to rise year to year, and so we intend to increase our investment in, and support for the Mac platform, and this 64-bit beta is an important part of that strategy.
For the record, MATLAB is native (through Java), and each release uses less and less of X11.
More changes are coming. One day there will be no X11 dependency, and my hope is for those customers who actually do continue to rely upon X11 functionality, that we have an alternative in place for them when we do remove it completely. Because some customers require it, we will always continue to support non-GUI command line interfaces (CLI), for local and remote operation, and parallel and distributed computing.
- Brian
MATLAB on OSX
Brian
I'm sorry if I sound so pessimistic and negative about MATLAB, but if I have a free app like Gimp, Dia, etc..., I understand how they might require X11, after all, the Mac is not their primary dev platform, and they have very limited resources, and they are free, so I can't complain.
However, with something like MATLAB which costs thousands of dollars per seat, I'm sorry if I expect a bit more.
Couple question, if there are so many dependencies on X11, how come the Windows version does not have these dependencies?; If MATLAB workbench is written in Java, what about developing a new workbench based on Eclipse?, it looks great on all platforms, and provides a TON of functionality?
Based on the fact that the MATLAB app contains all the libQT libs, I assumed MATLAB was a QT application, apparently this was the wrong conclusion.
Re: MATLAB on OSX
I hear you. I expect more, too, and we're working towards that goal.
PC-MATLAB for Windows came first, before MATLAB for UNIX, that's why it has no X11 dependencies. The OS X port was directly based on MATLAB for UNIX and shared over 99% of the code, under the mistaken assumption (which by the way originated from our very vocal Mac user base ;-)) that X11 would be good enough.
MATLAB for OS X today is all three: it's Java-based, Qt-based, and X11-based. There is native Cocoa code as well in a growing number of places. There is no active development directly using X11, and we are working to eliminate that code through active development in projects based on Java and Qt. The MATLAB Desktop continues to push forward using Java, and Simulink continues to push forward using Qt. Some products span both worlds (or rather, all three), for example Signal Processing Toolbox, and push forward using both.
You might think it's crazy to have all of this, and I will not disagree with you, but you are probably imagining that there is a single team, or platform teams, who should consolidate all of this, and just organize to blow it all away in a single release. There aren't any such teams, and it's a bit like herding cats. The MathWorks has a dizzying array of engineering teams developing over 80 products spanning more markets than I can count. It would be a mistake to think of MATLAB as a single product addressing a single market, and that happens to be one of its strengths. This is one of the key reasons why it's so hard for any single competitor to effectively chip away at our market share in any particular market.
But that's no excuse for not trying harder, and we are working as best as we can to improve things, from release to release. For those of you who are actively keeping up, we hope that it shows, and that things are getting better.
X11 is a must!
X11 support is an absolutely necessary feature in Matlab installations that for instance involve both Mac and Linux computers. Imagine you want to work remotely with Matlab on your Linux server back home in the lab while you're out in the field with a low bandwidth connection (nothing unusual btw!). Without X11 support you'd have to use VNC or the like - impossible at low bandwidth. In fact I'm worried about fading out X11 support in Matlab, how would you replace X11?
Speed differences in 64 bit?
Came a bit late to this thread, but I was wondering if anyone knows if there is much of a speed difference when using 64 bit MATLAB vs. 32 bit MATLAB.
Also, kudos to Mathworks for greatly improving its Mac support. There is always more to ask for, but I think Mathworks has done a pretty good job of supporting Mac users recently.
To be quite honest, I do not
To be quite honest, I do not give a rats ass if MATLAB uses X11 or Qt as long as the performance is on par with the current linux and windows releases (which it still is not).
I do not know what causes this performance hit but I doubt this has anything to do with X11 or Qt (as long as no graphics are called).
So what about stopping to fuss about X11/Qt/Cocoa and rewritting the basic stuff (things that do not even require a GUI) so I do not see my 8 core mac pro running as fast as a core2duo dell desktop.
Sorry about the rant but I recently discovered that the benchmarks for matlab on mac were horrid.
Problems worse than the "bench" utility suggests
The benchmarks with the R2009a (I tried both the 64-bit and the 32-bit) are just a bit slower than the Windows benchmarks (tested with the same Macbook pro using Bootcamp). On the other hand the execution time for a program that I wrote and that requires the Optimization Toolbox (it uses the command "fsolve") is between five and six times longer in OS X than in Windows, and that is quite discouraging.
Retraction of my previous post (Problems worse ...)
I have figured out what was wrong, and now the run-time of my program is more in line with the results of the "bench" command. I figure it is much better to retract than to simply delete so that it is clear why before I was getting such horrible results and now everything looks more "normal".
The problem is that three of the lines of the code (each of which gets executed many times in a loop) was
if exist(variable)
which is syntactically correct but much less efficient with respect to the better command
if exist(variable, 'var').
It turns out that the loss in efficiency was much worse in OS X than in Windows. I have corrected the script and report on the results. At the time of the previous post (with the inefficient commands) I had actually run my program only using r2008b, now I give here the data both for r2008b (32-bit Windows and Mac) and r2009a (32-bit Windows, 64-bit Mac: if I am not wrong the only r2009a that can be downloaded today August 20th 2009 is 64-bit: so the results of this last comparison are more for curiosity than anything else).
R2008b
Now the program runs in Windows 1.85 times faster (very different from the 5 to 6 time faster that I mentioned in my post above). This corresponds better to the results of the "bench" command, which for the sake of completeness are for my computer (Macbook pro early '08)
OS X: LU 0.11; FFT 0.24; ODE 0.24; SPARSE 0.34; 2D 0.78; 3D 1.03
Windows (bootcamp): LU 0.09; FFT 0.14; ODE 0.12; SPARSE 0.25; 2D 0.28; 3D 0.72
Seen as a ratio between speeds (speed Windows / speed OS X) we get the following
speed Windows / speed OS X; LU 1.22; FFT 1.71; ODE 2; SPARSE 1.36; 2D 2.78; 3D 1.43
So the speed ratio of 1.86 in the execution of an actual program is reasonably predicted by the "bench" utility.
R2009a
For what regards R2009a I get a ratio of speeds of 1.51 in favor of Windows in the execution of my program.
Bench results:
OS X: LU 0.09; FFT 0.21; ODE 0.19; SPARSE 0.32; 2D 0.63; 3D 0.83
Windows (bootcamp): LU 0.09; FFT 0.15; ODE 0.11; SPARSE 0.23; 2D 0.40; 3D 0.71.
Again as a ratio between speeds (speed Windows / speed OS X):
speed Windows / speed OS X; LU 1; FFT 1.4; ODE 1.72; SPARSE 1.39; 2D 1.57; 3D 1.17
So again the speed ratio of 1.51 in the execution of my program is reasonably predicted by "bench".
Maybe the one curiosity that remains is why an inefficient command has so much worse effect in OS X than in Windows, but it is not so pressing to figure it out.
X11 isn't a must... on the Mac
Well the Linux version is (and will probably be still) X11, which will display on the Mac by xterm/ssh to the Linux server. It has nothing to do with the MATLAB install (if any) on the Mac.