Via www.digg.com I came across a very useful tip for improving font appearance on Ubuntu. Details
here.

Makes a remarkable difference for me. YMMV.

posted by Sean 10:59 PM

[Link] . . .

Part 6 is here.

A curious phenomenon in the computer industry is the differing dynamics driving the CPU makers and the RAM makers.

With CPUs, the emphasis has been on *speed*. Year on year, clock rates go up. Nowadays its measured in gigs. Not so long ago - Megs.

With RAM, the emphasis has been on *capacity*. With speed of access coming a distinct second.

The result has been that modern day CPUs absolutely *scream* along ... except for when they need to access such slow devices as RAM chips.

Real-world applications spend a lot of time accessing RAM, so much so, that processors can spend a silly amount of their total execution cycles waiting around for the tardy RAM to do its thing.

So here is the upshot:

• We are building machines with fasters and faster processor clock speeds
  
• As the speed goes up, so too do the problems of heat generation
  
• As the speed goes up, the amount of time a box spends waiting on its RAM goes up
  
• Consequently, pumping CPU speed is no longer the obvious solution to application performance problems
  

We need another way to drive performance rather than just look at CPU speed.

We need to find ways to make todays ultra-fast CPUs spend more of their cycles doing useful work and less of their time navel gazing waiting for RAM.

To do this effectively, we need to give each processor core the ability to switch between applications that are waiting around on RAM and do it quickly.

That is what chips like the T1 UltraSparc in the Niagara are all about.

Ask not how many seconds your application takes to process a record or an document. That is not the important question. The important question is how many records/documents your application can process in a second.

The second is a measure of *throughput*. The former is afflicted by von Neumann's Curse.

Next up: a look at threads - the obvious paradigm to feed cores with applications to switch between. As with everything else of course, its not quite that simple.

posted by Sean 1:47 AM

[Link] . . .

Part 5 is here

Between holidays and work commitments some time has passed since we set up the Niagara (Sun T2000) box and popped it on the network. Thankfully, I can see some light now where we can proceed to run some application tests.

First up: this is a 4 core box i.e. it has a single UntraSparc T1 processor and on that single processor there are 4 cores. Each core is basically a separate CPU (there are some subtleties here. We'll get to them later.)

So, I have a machine that the operating system will see as a 4 CPU SMP box right? Lets see...the mpstat command gives me a look at what all processors in a Solaris setup are doing. Lets try that...(abbreviated output shown)

CPU minf mjf xcal ...
0 0 0 52 ...
1 0 0 0 ...
2 0 0 0 ...
3 0 0 0 ...
4 0 0 0 ...
5 0 0 0 ...
6 0 0 0 ...
7 0 0 0 ...
8 0 0 0 ...
9 0 0 0 ...
10 0 0 0 ...
11 0 0 0 ...
12 0 0 0 ...
13 0 0 0 ...
14 0 0 0 ...
15 0 0 1 ...


16 processors! What gives? Did Sun give me a 16 core box by mistake? Is there a big gaping hole in this simple conceptual model?

The latter.

Here is the simplified scoop.

• There is a single T1 UltraSparc Processor in the box


• That single processor chip has 4 separate cores. The cores are *mostly* independent processors. They share a single FPU and they share an L2 cache.
  
• Each core provides 4 hardware-implemented threads. Simply put, each core can switch in one instruction cycle between any of its 4 threads.
  
• The hardware level threads are known as *strands*.
  

So, 1 T1 UltraSparc with 4 cores, each of which has 4 hardware threads (strands).

That is where the 16 processors comes from. 4 cores times 4 strands per core = 16. Solaris "sees" each strand on each core as a separate processor. When Solaris wants to schedule a lightweight process (a software thread) to run, it sees 16 virtual CPUs on which to do so.

Thats the simple version. Of course, its not that simple in practice. Getting the most out of a multi-core box requires digging down a couple of levels below this.

To see why its best to a segue into looking at the world from the perspective of one of those cores...

posted by Sean 1:09 AM

[Link] . . .

Just thinking out loud here. If technology makes privacy really problematic (as in the famous "Privacy is Dead. Get over it.") perhaps the pragmatic reaction of carbon-based life forms who value their privacy will be to use a plethora of makey-uppy identities. Modern day "nom de plume" by the boatload?
If privacy is dead, maybe identity is dead too?".
How many standalone identities have you already got right now for online services? Do you see that list diminishing or growing in the years ahead?
Where do genteel sounding "non de plume(s)"[1] stop and the problem-laden concept of "fake identities" start?

[1] Apologies to the beautiful French language for this egregious pluralisation hack.

posted by Sean 1:26 AM

[Link] . . .