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.
