Nice or Nasty?

Nice is arguably the most devalued word in the English language, although cool has more recently been giving it a run for its money. Whether you squeeze it like toothpaste into a Windsor naice, or burr it round a West Country village to noice, its meaning remains unsullied if quaintly different in Unix.

nice is a most obvious manifestation of the fundamental difference between old Mac OS and new OS X.

Back in the cosy but naïve world of Mac OS 9, co-operative multi-tasking cut both ways. When applications did work together, it gave the impression that your Mac was juggling those applications smoothly. But any of those applications could equally well seize the processor – perhaps to your advantage, if you were performing live with the likes of Cycling 74’s magnificent MaxMSP, or to your intense displeasure if you wanted different.

With OS X, we have graduated to pre-emptive multi-tasking, which shares the processor’s slices of time out in a fair, round-robin schedule. No longer should anything hog the processor, but each gets its fair share.

But not quite: the software in OS X’s kernel that allocates processor time is not entirely egalitarian. This scheduler sees four categories of running code ‘thread’: normal priority, high priority, high priority kernel, and real-time. High priority kernel threads are those responsible for running the innermost functions of OS X, including input and output. Real-time threads are those that are dependent on getting a minimum percentage of processor time in order to perform functions such as playing live audio. These latter classes are not determined by the user, but by the code itself.

If thread priorities are cast in code, it might appear that the user is stuck with them. Enter our revalued concept of nice, for it is that shell command that can tweak the overall priority of a running process. Type ps -lax into the Terminal command line, and one of the columns of information given for all active processes (and applications) is the ‘niceness’, headed NI.

When you look through the niceness of the processes running on your Mac, almost all of them are 0. You could in older versions see launchd, the daemon that manages other daemons, with a niceness of -1, which in characteristic Unix inverted logic gives it higher priority in scheduling; you may see one or two processes with positive nicenesses, giving them lower priority. In Yosemite, launchd does not enjoy such favouritism, and has a niceness of 0 like those in the herd. However there are still some occasional favourites to be found.

From the early days of OS X, some users have wanted certain applications to be able to hog the processor in the way that they could under OS 9.

As there is no way to return to co-operative multi-tasking, one suggested approach has been to change the niceness of the application in question, to a relatively large negative number such as -10. To assist, there was a steady trickle of neatly packaged, friendly ways of renicing applications, such as Renicer, now sold as Appriority from here and the App Store. Some, such as Speed Freak (now discontinued), tried to be smarter, by renicing the frontmost application to try to mimic OS 9’s idea of foreground and background tasks.

In almost all cases, renicing applications fails to hand the processor over to them, but runs the risk of messing up its scheduling altogether. In fairness, renicing utilities point out that few games will benefit as they are most likely to be bound by graphics performance, and that other performance effects are generally small.

In my experience, the results of such tinkering are nice, in the most devalued sense of the word, and far from cool.

Updated from the original, which was first published in MacUser volume 22 issue 2, 2006.