The ARM VFP co-processor is most commonly used for individual floating-point computations, in the so-called “scalar mode.” In Flynn’s taxonomy, this is known as SISD, or “single instruction, single destination.” This design philosophy is the basic form for most low-level assembly most high-level compilers. In cases where different data sources are treated differently, for whatever reason, SISD is the norm.
However, when a block of identical operations are carried out on a sequence of data points, then it is possible to fetch several of the source data, and perform the operations on them all at once. This may be something as simple as adding the values of two arrays and storing the results into a third array, which may be part of a sophisticated analysis on a digital image. A close examination of the processing can show where Single Instruction, Multiple Destination (SIMD) design can boost a program’s performance.
One convenient Linux kernel feature is an uptime stamp in each kernel log entry. This stamp is independent of the clock time, so small or large jumps in the clock have no bearing on the reported time for each entry.
Normally, the log files in /var/log/ will include a human-readable local time stamp before the log entry, but these files are readable only by the root user. Another possibility is that the logs are routed to another system for storage. This practice would also include restricting “dmesg” to the root user; the following won’t be useful in this case.
One axiom of computing is to script commonly-used command sequences, akin to C’s functions, Pascal’s procedures, and Ada’s subprograms. But what if the command sequence involves “su” for elevated privileges? I found an idiom that Works For Me.
This example will pull pages from the swap space back into RAM:
#!/bin/sh case `id -u` in # The task is accomplished in the 0 case, # where we know we have root privileges. 0) /sbin/swapoff -a /sbin/swapon -a ;; # Everyone else gets to provide a password: *) exec /bin/su -c "`which $0`" - ;; esac
Anything requiring elevated privileges, or even simply someone else’s privileges, can be scripted this way. I have the above script in ~/bin/unswap. I have three other scripts in the same directory, called “slow”, “normal”, and “fast”, which set the CPU frequency governor to powersave, ondemand, or performance.
The one caveat is to hard-code the paths to the root-executed programs (which you already do in scripts, right?). You don’t want to execute a non-standard “swapon” that isn’t where you expect it to be.
(If someone would like to contribute an example using “sudo” instead of “su” it would be greatly appreciated.)
I run Slackware ARM on my Raspberry Pi. I’ve been a longtime fan of Slackware, which caters to my inner control-freak. However, since Slackware ARM (formerly ARMedSlack) is designed to run on a variety of ARM-based systems, and an ARM-based system is typically a System-on-Chip, this means that Slackware ARM is built for maximum compatibility… and minimum optimization. For example, not all ARM CPU’s have on-board floating-point capability. By assuming no floating-point capability, Slackware ARM can run on a wider range of ARM-based systems. However, this can reduce performance significantly.
This guide will explain how to rebuild core glibc libraries to use the greater capability of the Raspberry Pi’s on-board ARM 1176JZF-S CPU. The process is not terribly involved, but using NFS for the build space took 8-1/2 hours, even with the CPU overclocked to 900 MHz.