19
$\begingroup$

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?

$\endgroup$
  • 5
    $\begingroup$ This is going to happen until Wolfram provides a 64-bit version for macOS, I think. $\endgroup$ – user6014 Apr 12 '18 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$ – user6014 Apr 12 '18 at 13:09
  • 7
    $\begingroup$ Ah, it's the FrontEnd. That isn't optimized anyway... $\endgroup$ – Henrik Schumacher Apr 12 '18 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$ – Szabolcs Apr 12 '18 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$ – Szabolcs Apr 12 '18 at 15:58
27
$\begingroup$

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).

$\endgroup$
  • $\begingroup$ Very interesting; should we expect a performance boost of the front end in the 64bit version? $\endgroup$ – QuantumDot Apr 13 '18 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$ – John Fultz Apr 16 '18 at 7:29
  • $\begingroup$ Do you mean like the crash that happens if I click on the + button in the summary box of Compile[{x},Evaluate@Array[y,100000]]? (my guess is that this is an out-of-memory crash) $\endgroup$ – QuantumDot Jun 5 '18 at 1:35
  • 3
    $\begingroup$ Can't wait for the prerelease ... whenever I work either with large MeshRegions or 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$ – Szabolcs Jul 11 '18 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$ – John Fultz Jan 10 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.