cpubars: More processors equals more fun

This is kind of a pointless screenshot for cpubars, given what it’s intended for:

If I had two cores, or maybe four, or maybe 16, or one of these, cpubars might really put on a show. As it is, my lowly non-hyperthreading P4 will only animate one row of CPU stress bars. More’s the pity. 😦

The home page says cpubars is intended for multicore machines accessed over ssh, and I do believe that cpubars could do just that. It wisely sticks to block characters and simple colors, which should cause minimal stress while offering a still-pleasing display.

After all, what good is a CPU monitor that puts the CPU to task while running? 😛

Aside from that, I don’t know there’s much to say about cpubars. The binary is 23K. There’s an option to set the refresh delay. I think that’s it.

Good enough — color, animation, low profile and a straightforward design. Huzzah, I say. 🙂

mpstat: Quickdraw processor statistics

Back in April I brushed up against the sysstat suite while mentioning sar. sar is just one of a cluster of tools you get when you install sysstat; another one is mpstat.

mpstat shares some features with sar, mostly in its ability to generate processor statistics at intervals, and a set number of times. This is useful in the same way as sar, by allowing you to poll the processor when you know it will be taxed.

Commands are also similar; sar 2 5 will behave in the same way as mpstat 2 5, with some small but obvious variations.

Taking into account the other programs that are available in sysstat (some of which will come later), there’s not a huge difference between sar and mpstat, except perhaps in the specific processor data either one offers. By default, sar shows a little less, and mpstat shows a little more. But some is shared between the two.

And you can’t really appreciate it with this machine, but mpstat has the ability to split out its results according to processor. That might be important if you’re working with one of these. 😯 I keep watching the recycling shop, but nothing yet. …

mpstat‘s output is sparse enough and well-spaced enough that you might consider cramming it into some other application. colorwrapper, anyone? 😉

parallel: Working along the same lines

I have been messing with parallel all morning, trying to get it to do the same things that I see in the videos, tutorial and examples.

If you’ve not heard of it, parallel should (and by all accounts usually does) split CPU-intensive jobs across processors, which should drastically reduce the time they require to finish.

But I’m not getting much in the way of speed increases, and in some cases it seems to be taking longer.

I’ve tried most combinations I could think of, done them all again as root, even followed examples letter-for-letter from the explanatory videos.

But in almost every case I’m getting much the same performance from functions, so long as they don’t bottleneck at hard drive writes, or something like that.

The coolest thing about parallel — that of course I can’t take advantage of 🙄 — is that it can farm out work to other machines.

Yes, that’s what I meant. It can distribute the workload to networked computers and retrieve the results when they all finish.

I think that trumps xargs, which I often see mentioned in the same breath as parallel, because it will take a --max-procs argument and split out to several processors.

But hey, if I could set four computers on the task of compressing my family photos, I’d be all for that.

I’m going to keep tinkering with parallel and if I can get it working in a promising way, I’ll let it make cameos in future posts.

But you’ve got to earn a place on the big screen, friend.