On launching Mathematica (11.3.0.0) on macOS 10.13.4 I get a warning that it is "not optimized" for High Sierra. Is this a known issue being addressed?
$\begingroup$
$\endgroup$
15
-
5$\begingroup$ This is going to happen until Wolfram provides a 64-bit version for macOS, I think. $\endgroup$– ktmCommented Apr 12, 2018 at 13:06
-
8$\begingroup$ I found this, in which Wolfram acknowledges they have not released a 64 bit version of Mathematica, but are working on it: support.wolfram.com/kb/37287 $\endgroup$– ktmCommented Apr 12, 2018 at 13:09
-
7$\begingroup$ Ah, it's the FrontEnd. That isn't optimized anyway... $\endgroup$– Henrik SchumacherCommented Apr 12, 2018 at 13:17
-
12$\begingroup$ @HenrikSchumacher Mma 11.3's Front End is still 32-bit (!!!) The kernel is of course 64-bit, but the FE is 32-bit, which limits it to 2 GB of memory and causes me trouble by crashing whenever more than that is needed. $\endgroup$– SzabolcsCommented Apr 12, 2018 at 15:55
-
3$\begingroup$ @user6014 Mathematica consists of two components: the computation kernel, which has been 64-bit for a very long time, and the "front end" (i.e. the GUI), which is still 32-bit. It's quite misleading to say that "Mathematica is not 64-bit". The most important part, and the part that benefits the most, has been 64-bit-only on OS X for many years now. $\endgroup$– SzabolcsCommented Apr 12, 2018 at 15:58
|
Show 10 more comments
1 Answer
$\begingroup$
$\endgroup$
9
This message is a warning delivered by High Sierra that the application you're running is a 32-bit application. In our case, it's specifically referring to the Mathematica front end, which is not only 32-bit, but also still running against the legacy Carbon APIs for accessing the windowing system.
The Mathematica bundle also contains a small number of other 32-bit binaries, but the kernel is fully 64-bit, and has been since even before macOS could support 64-bit GUI applications (since the kernel is not, in fact, a GUI application).
Based upon what we know about how High Sierra delivers this warning, you should receive it once only for any given app bundle.
We're actively developing a 64-bit Cocoa version of the front end, as well as ports of other binaries which remain unported. I'm not ready to suggest a date when we'll release this, but I'm quite confident it'll be sometime this calendar year.
Update: Version 12.0 and later releases are fully 64-bit, and the v12 front end is a completely native 64-bit Cocoa app. Furthermore, version 12 (the latest version as of this writing) has been tested with and is fully supported for macOS 10.15 (Catalina).
-
$\begingroup$ Very interesting; should we expect a performance boost of the front end in the 64bit version? $\endgroup$ Commented Apr 13, 2018 at 19:19
-
1$\begingroup$ @QuantumDot it depends upon what you mean by "performance". If you're asking whether it will be faster, I don't yet have enough information to say. If you're asking about stability, it will certainly prevent a class of crashes caused by memory exhaustion. And we'll be able to avoid a class of Carbon-layer bugs that Apple is no longer interested in fixing. And we'll be able to adopt some macOS app features that simply aren't available to Carbon apps (that's not to say all such features will be ready on day one, though). $\endgroup$ Commented Apr 16, 2018 at 7:29
-
$\begingroup$ Do you mean like the crash that happens if I click on the
+button in the summary box ofCompile[{x},Evaluate@Array[y,100000]]? (my guess is that this is an out-of-memory crash) $\endgroup$ Commented Jun 5, 2018 at 1:35 -
3$\begingroup$ Can't wait for the prerelease ... whenever I work either with large
MeshRegionsor large images, I need to be prepared for the FE crashing eventually (due to the 2 GB memory limit). Forgetting a semicolon can easily result in an immediate crash. $\endgroup$– SzabolcsCommented Jul 11, 2018 at 12:53 -
2$\begingroup$ @QuantumDot, a couple of months ago, I did some tests on the latest 64-bit Mac FE, which is now in prerelease and should be shipping shortly, and I found that for most FE-specific operations there was a modest, across-the-board speed-up. I was doing things that stressed broad portions of the system like opening large notebooks with varied content, cycling the help viewer, etc. and finding that operations were taking around 40% less time. It wasn't a result I had expected, and I'm certain there's specific areas of functionality where that number won't hold, but I'm happy to see it's the case. $\endgroup$ Commented Jan 10, 2019 at 18:54