# Benchmarking Mathematica performance on the Raspberry Pi

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? - ## 2 Answers ## 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! 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: 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: 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: 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: 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. - Tks for sharing. Very nice RPi/WL exploration. I enjoyed your site, and the others experiments with RPi. – Murta Jan 2 '14 at 11:11 We have a new Raspberry Pi with a 4-core ARMv7 processor and 1 GB of RAM. A recent version of Mathematica was just rolled out which apparently addresses a licensing issue that limited the number of cores that Mathematica was using. It's time to revise the benchmarking reports. Here's the results from Benchmark[] with a comparison to the $BenchmarkSystems that appear to be on 32-bit computers. We observe a modest improvement in performance with the new RPi although we are (not surprisingly) still at the very bottom of the list. Mathematica has been available for the RPi for about a year or so, and a five-fold improvement in performance is impressive in my opinion.

Here's a closer look at overclocking the RPi 2

We see an average decrease in execution time of about 10% when bumping the frequencies up (ARM 900 to 1000, SDRAM 450 to 500, CORE 250 to 500). The overclocking values were the best I could get out of my system with reasonable stability. I'll note that when overclocked, the Discrete Fourier Transform routine caused the voltage on my RPi to drop below 4.65 V although it didn't crash the system. I am using Powered USB (2 A) to supply the RPi with all peripherals (wireless mouse, wifi) except for the keyboard attached to the powered USB hub. (Despite having 4 USB ports, I did run in to some serious voltage drop issues if I had them occupied with the mouse/wifi adapters.)

I would also go so far as to say that the Front End is usable with the RPi 2. Manipulates work about as sluggishly as the do on the Wolfram Programming Cloud. Initializing calls to curated data sets is a bit snappier and while I haven't spent large amounts of time (yet) on the Front End with the RPi, it does not seem to get bogged down as it does on the single-core model B.

3D graphics is still a bit of a stretch. They render in reasonable amounts of time but 3D graphics output does not respond well to mouse-based interactivity. Best to sharpen up on your ViewMatrix skills.

-
A USB connector is not rated to supply 2A (even the specialized charging connectors are only rated for 1.5A), so this is probably where your voltage drop comes from. Perhaps it would operate better if a dedicated power supply was used. An additional decoupling capacitor may also be useful. –  Oleksandr R. Feb 16 at 19:15
@OleksandrR. I was not aware of the current limitations and will have to look in to more reliable power supplies. What surprised me were the claims that the RPi 2 draws as much current as the B+, and I'm starting to find that a little hard to believe. –  bobthechemist Feb 16 at 22:41
I should also note (just learned this) that I am using a HDMI-VGA converter box, which is also drawing power from the RPi. I suspect this connection is also contributing to the power problems I have alluded to. –  bobthechemist Feb 28 at 15:05