Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

It is not surprising that Mathematica on the Raspberry Pi is slow and clunky. In Stephen Wolfram's words, the command line is "quite zippy" but the notebook interface is "a trifle sluggish by modern standards". I believe the performance issues are due primarily to two reasons:

  • The Raspberry Pi performs at about the level of a 300 MHz Pentium II.
  • Mathematica isn't optimized for the ARM processor (yet?) and is currently in pilot release

There are in my mind two good reasons for dealing with the sluggish performance of M/RPi:

  • Running Mathematica for free on a \$35 credit-card sized computer is just awesome
  • The RPi platform allows for hardware interfacing that is not readily available on a PC (or put another way, I'd rather brick a \$35 credit-card sized computer than a \$1000+ PC)

How can end users improve the performance of their M/RPi systems while we wait for Wolfram to roll out optimizations for the RPi?

share|improve this question

1 Answer 1

New version update

The July 29, 2014 version of Mathematica brings to the RPi the ability to evaluate expressions on the cloud, in other words, to cheat at benchmarking!

Mathematica graphics

As an added bonus, we have a default retro color scheme for BarCharts that is sure to please fans of the 70s. I have a sudden urge to dust off my Algol and Cobol handbooks. Ahem.

The interesting data are those marked "Absolute", which includes the network overhead and is a better comparison to running on the RPi than "Cloud" is. (This does not include the one-time 1-2 minute interaction with a terribly sluggish interface that logs you in to your Cloud account.)

Performing these tasks on the Cloud cost me 11 credits. There is clearly a benefit to considering Cloud-based evaluation when designing Wolfram/RPi projects, but one must cognizant of CloudCredit bookkeeping.

Minor update

There was an update to the wolfram engine on the Raspberry Pi in late January. I presume there were some bug fixes and re-ran some of the benchmarks. Here, the results show that there was a significant performance boost in the way M/RPi handles linear systems:

enter image description here

These results were obtained with a fresh install of the Raspbian image (2014-01-07) on an 8 GB class 10 SD card with Medium overclocking running Mathematica from within the GUI (running instead using wolfram in the terminal shaves about 0.75 s off the results).

RPi configuration options

The RPi has two easily accessible features that may influence the performance of M/RPi. The first is overclocking. The default is 700 MHz but the configuration software allows for 4 levels of overclocking: modest, medium, fast and turbo. The second option is the memory split. The Model B RPi comes with 512 Mb of RAM which is shared with the GPU. The memory split can be as little at 16 Mb to the GPU or up to 256, with the default being 64 Mb.

Benchmarking

I performed some benchmarking using a subset of the functions used in the BenchmarkReport[] in version 9. I changed each of the functions so that the operations could be completed in a reasonable (10 s) amount of time. The four tests are:

dft = Module[{data}, 
  Timing[SeedRandom[1]; data = RandomReal[{}, {240000}]; 
   Do[Fourier[data], {11}]]]
ef = Module[{m1, m2}, 
  Timing[SeedRandom[1]; m1 = RandomReal[{}, {2.2`*^5}]; 
   m2 = RandomReal[{}, {2.2`*^5}]; 
   Do[Exp[m1]; Sin[m1]; ArcTan[m1, m2], {30}]]]
rns = Module[{a}, 
  Timing[SeedRandom[1]; a = RandomInteger[{1, 50000}, {300000}]; 
   Do[Sort[a], {15}]]]
sls = Module[{m, v}, 
  Timing[SeedRandom[1]; m = RandomReal[{}, {300, 300}]; 
   v = RandomReal[{}, {300}]; Do[LinearSolve[m, v], {16}]]]

For the first pass through, I changed the overclocking from none to fast. I tried turbo, but my RPi would not boot with this level of overclocking. The results of the four tests above are shown here:

Mathematica graphics

As expected, the performance improves with overclocking. Looking at the results in a slightly different way, we can observe the overclocking effects relative the the default operation:

Mathematica graphics

The greatest performance boost with overclocking is observed with the elementary functions test and the least improvement is observed with for the linear systems. I believe (and someone please correct me if I'm mistaken here) that the random number sorting and linear system solving are the most memory intensive of the four tests I've selected, which is why these functions do not see as significant of an improvement with overclocking as the other two routines.

Final comment on overclocking I don't know how to measure it, but qualitatively I observed smoother performance of the graphical interface with fast overclocking; however my RPi did get fairly hot and I worry about system stability. I typically keep my RPi overclocked at the medium setting and it seems to be fairly stable.

Changing the memory split had a negligible effect on performance. The following data were collected with no overclocking with the Mb number indicating how much memory is allocated to the GPU:

Mathematica graphics

Comment on RPi configuration options These benchmarking results suggest that a medium/fast level of overclocking with a 256 Mb memory split will likely give you the best performance when using M/RPi with the graphical user interface.

Other considerations

Based on conversations I've seen in other forums, it is not obvious that Mathematica can be run in two modes: command line (on the RPi via the command wolfram) and the standard graphical interface (mathematica on the RPi). I agree with Stephen that the command-line mode is fairly responsive. Using a text editor for writing scripts and exporting graphics to view with an external viewer is less clunkly than using the notebook interface in my opinion. (I'm not quite sure what the term 'trifle sluggish' means in Wolfram-ese, but I interpret it as 'darn slow'.) Even with the configuration options noted above, it is hard to use the notebook interface on the RPi, not only because of its sluggishness, but because of the limited functionality. I'm no fan of the predictive interface, but autocompletion is nice, and it's not present on the RPi. If I'm a real glutton for punishment, I'll SSH into the RPi and use X-tunneling. Unless you have the patience of a saint, this is not a viable option for routine M/RPi use.

The best(?) GUI option at present in my opinion is to load up Mathematica on a PC/Mac and establish a remote kernel connection. The Mathematica license on the RPi allows for four kernels to be running simultaneously (don't do this) and remote configuration works out of the box. I observe virtually no performance differences when accessing the kernel remotely and the benefits of a functioning notebook interface with autocompletion (at least for commands that are common to M9 and M10) is very attractive. The downside with this option is that you no longer have the benefit of an ultra-low cost Mathematica solution since you need a license to run Mathematica on the PC/Mac. If you are visiting this forum, however, I suspect that is not really an issue.

share|improve this answer
    
Very nice! I agree about the memory bandwidth being a limiting factor for performance scaling with core clock. I would have thought that Fourier is more memory-bandwidth-intensive than LinearSolve, all other things being equal, but then again this could easily depend on the particular choice of libraries and how well they use the CPU cache. –  Oleksandr R. Jan 2 at 2:25
1  
Tks for sharing. Very nice RPi/WL exploration. I enjoyed your site, and the others experiments with RPi. –  Murta Jan 2 at 11:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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