Hardware disgruntled

To be honest, I’m kind of underwhelmed by where we are at with storage in computers.

My biggest beefs are: CPU+GPU, SSD and Multi Core…


The CPU is the heart of the computer. Both Intel and AMD are now working to put GPUs on-chip with their next generation processors. I don’t get how they expect this to be a win.  I can see an allure for mobile computing, but I don’t see a pot of gold.

Is the GPU going to share cache access with the CPU? And what performance impact with that have? How about memory access? I can see some real nasty bottleneck potentials there. Which means new motherboard designs. That could be a one time pricing hike or it could be multiple pricing hikes while it goes through countless iterations of refinement to make on-chip GPUs performance comparable to stand-alone GPUs taking advantage of the advances already made.

Secondly, it’s going to hike up CPU prices. You already expect that since, duh, you’re getting more for your money. But that’s not what I mean.

GPUs update far more often than CPUs.

Looking at desktop machines, your CPU is probably going to last you 1-2 years, while you might update your GPU more often than that.

Last time I upgraded, I bought a high-end Core i7 for $450 or more. I ain’t replacing that for a good while. So why would I want a separate on-chip GPU, that I know is just going to become wastage in 6-12 months when I decide I want to move my graphics performance up 2 or 3 of the available 4-5 notches?

If my Core i7 had featured a CGPU, it would probably have cost me $650-$800. If that wasn’t going to last me 2-3 years …

Bundling up devices makes sense when they advance in lockstep. CPUs and GPUs don’t. They both have comparable price brackets.

IMO – they are a really bad choice to meld: Chances are, when you try to upgrade your graphics performance down the line, buying a suitable CGPU is going to require a motherboard upgrade, and a RAM upgrade and …

Long term, that’s not going to appeal to mobile computing platform designers either.


Jeez. What a disappointment. SSD has the potential to rock our performance worlds. But it doesn’t seem to sit well with the saurian storage manufacturers of the computing world we live in.

That’s the only explanation I can see for the lack of any real progress in the cost/Mb and cost/performance we’re looking at.

SSD is actually something I could see a case for “on-chip”, but not in the traditional sense. I can envision a CPU that comes with it’s own expansion socket designed for SSD modules. Screw all this SATA/SCSI nonsense. Plug the high-performance storage straight into the CPU and get the most out of it.

More than anything, what SSD is demonstrating is how poorly Windows supports multiple drives. Installing Windows on a 64Gb SSD rapidly becomes a problem as the drive starts to fill up. Most people won’t have run into the issues yet, but just wait until the first time you need to use a recovery disk and find that Windows 7 recovery disks can’t handle parts of the operating system being on alternate drives :(

SSD sizes need to grow fast, but as yet there’s no real evidence of that happening any time soon. They cost too much and their initial “wow” factor of performance doesn’t really carry through as you wind up putting more and more of your apps/games/data on old-style drives. I know numerous people are gradually backsliding to traditional HDs with the SSD serving as a “ready boost” device :(

Direct-to-CPU SSDs could at least offer extra ‘soft’ storage (volatile RAM) presented as a ram-disk to the CPU that Windows could use for ReadyBoost and Linux/MacOS could use for /tmp etc.

That would provide some real performance gains.

Multi Core


I struggle to find the right way to describe, in lay mans terms, what a shitty solution to CPU performance this has proven to be so far. I’m going to try two analogies.

1. The Chef analogy: As of right now, multiple CPU cores are like hiring multiple chefs without ESP. You know what they say about too many chefs in the kitchen? Well running one application is like cooking one meal, so two chefs is too many.

Computer programming, computer languages and operating systems have to change to take real advantage of them. There’s nothing automatic about it. In a kitchen, that means changing the recipes or specifically selecting recipes around the fact that more than one chef is going to be working on it at the time.

2. The Dictionary and River analogy: A CPU is an implementation of a set of operations, the way a dictionary defines a set of words that implement a human language.

Programmers and hardware guys talk about “instructions” but that’s a misnomer, what it implies is far too easy. CPUs actually work in terms of operations, and an “instruction” – as written by a programmer – may translate to multiple CPU operations.

There is an “add” operation, a “multiply” operation, etc. The term “instruction” comes from when you write those in a human readable language. For example, “square root” is an instruction, but not every CPU has an operation to perform square root, and instead the instruction is itself a sophisticated sequence of CPU operations that produce a square root.

Saying there are no moving parts on a CPU is like saying that a river has no moving parts. Over numerous years, the flow of water down a river will cause it’s course to change.

When a CPU loads in a chunk of program that represents what was an “add instruction” in the original code, a sort of soft-reconfiguration changes that causes the next wave of electrons to flow through a set of gates and switches that causes another part of the CPU to soft-reconfigure into the representation of the two numbers added together.

If you imagine the flow of a river downstream reaching a muddy area, during the winter the river follows the eastern bend through the muddy area, but when the summer floods come, the water is strong enough to break through the silt and take the shorter western bend.

So computer “operations” are implemented very simply as cascades of these kinds of cause-and-effect decision points.

From a human perspective, a program is built up through a complex sequence of “instructions” to implement hundreds and thousands of these operations, with the flow of operations dictating the subsequent sequences of instructions.

How fast the program will run depends on how many “instructions” translate directly to a individual CPU operations.

This is where the Dictionary component comes in. Next time you’re in or passing a book store, stop and look for a good English Dictionary. It’s not small.

And the Dictionary is a sort of “human” communication program. It explains English “instructions” in terms of other English “instructions”.

If a CPU doesn’t have a multiply operation, then any program wishing to multiple one times three, would need to define it’s own “multiply” instruction comprising multiple CPU operations, e.g. “one plus one plus one”.

Multi-core CPUs don’t provide multi-core facilities, that is: they provide next to no multi-core operations.

Consider the simple statement:

let A be the number of CPU Cores times 3

The CPU operations to implement this could be very simple.

fetch the value 3
fetch the value Number of CPU Cores
multiply values

But there’s no “Numer of CPU cores” operation. That means, instead, it’s an instruction. By and large, you get the number of CPU cores from the Operating system, which is itself a very large set of instructions that combine large number of CPU operations to fill in various gaps and blanks.

Previously, on start up, each CPU core began running a copy of the operating system: independently. The operating system copies performed a clever set of instructions (combinations of operations) that manipulated a certain area of memory providing them with an awareness of each others existence and allowing them co-ordinate and provide the appearance of a single instance of the OS. (This may still be true, but I don’t know for sure)

That’s a lot of fucking around. It’s like trying to define “and” without using the word “and”. Hence the Dictionary analogy.

While that may have progressed, unfortunately it hasn’t gotten much better for programs running under an operating system. If you want to take advantage of multiple CPU cores, you must co-ordinate with the operating system.

That means instructions to run instructions to run instructions. This is like trying to explain the situation between the Capulets and Motagues without using the words “the” or “and”. Again, look at the size of a decent dictionary… It’s not small. Oh, and by the way, try and define the term “dictionary” without using the words “the”, “word” or “language”. This should give you some sense of what’s involved in doing something on multiple CPU cores without actually having any CPU operations for doing so.

Multi-core CPUs, todate, are little more than networked assistant computers that happen to be housed on the same chip. They can communicate really fast thanks to their shared location, but there’s still no ESP, it’s all down to complex communications defined by the operating system (the dictionary), which is itself a set of complex sentences and statements built using the definitions of the dictionary.

This totally sucks donkey balls. As I’ve said previously, it’s a huge con job by the CPU vendors that depends on the fact that most of us are ignorant of these complex details. I mean, seriously, those early dual-core CPUs were marketed as “run twice as fast”, right? Because once you’ve gotten past the overhead of starting two chefs working on their separate tasks, and made absolutely, categorically certain that they will never come into conflict or contention (e.g. they never both need to access the same hob of the same stove), the meal will be cooked twice as fast, right?


I always thought the big advantage of on-chip GPUs was the removal of the comms bottleneck over the PCIe bus. If the GPU could access normal memory with the same speed the CPU can, then you could switch between GPU and CPU computations with much less of a disadvantage than the current shoving of gigabytes of data up and down the PCIe bus…

SSDs, Still novelity I think comparitivly at least.
Multi cores, my head hurts now… but yea seems to me the job of handing off work to each core should be a part of what the cpu does for you.

Course I got no clue realy :)

oliver said multi ore enhancements for 1.33!


Yes I hear what your saying and there is some frustration.
Just saw an article on the BBC of all places about the actuality of the new BIOS becoming commonplace by next year.

At last a few seconds only is needed before the OS kicks in.

Multi Core is a bit of a white elephant – It helps and yes some apps and OS’s take good advantage of it but it’s not quite the great hope it was billed as.

SSD I agree has massive potential and I love the speeds and idea behind it but the price per MB and sata have held it back. We do need that next jump in architecture to push things on.

forget C and pull out your assembler for multi core.

Bone up on registry manipulation and your favorite terms

It may take 10x longer to code but it will be faster. maybe 2x 3x

Lut: Unless the two tasks are utterly independent, they’re going to be contending for resources. If you are pumping data from CPU to GPU, that means it’s L1/L2 cache you’re mucking with. Is the GPU going to have CPU-L1 cache access? Or is the CPU going to push it out somewhere *to* the GPU?

Most importantly: will driving the GPU be a CPU operation? That is, will CPUGPU co-operation be hardware or yet more software?

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: