I recently posted that massively parallel processor are on the way and that we (as programmers) will have to think differently to write code for these environments. I posted that we will need to think in terms of tiny nuggets of program that interact in some simple way.
This in itself is not hugely clever - expose a simple message-passing system, perhaps make a nod towards PI-calculus, maybe make compile-time restrictions on code size and message complexity. Hmm, a kinda SOA at the machine-code level.. grid computing anyone?
I think that moving away from the separation between 'data' and 'code' might help somewhat, and this bit is clever! It would mean that, once suitably transformed, a users data can be expressed in terms of it's interpretive ability. A new service can be created because we know that the user has recorded the position of a telelphone port, or changed the value of the price of a share in some company. Now our 'real' coders are really writing interpreters. They are writing programs that interpret the data into machine-executable processes. Of course, the implication is that we are creating a program that is writing itself at execution time... oh boy!
Thursday, May 24, 2007
What happened?
I'm not happy! What happened to good code? What happened to efficient programs? What happened to squeezing the last dribble of performance out of that computer?
Why is my PC is starting to creak even though it has 2G memory, a superfast HT P4, SATA, a mega gfx card, etc. I remember (whistful reminiscence ensues, cue scratchy violin music and sepia, soft focus imagery) a P166 with 16Meg and a 1G IDE HD playing Quake and Duke Nukem. I remember programming image manipulation programs and virtual reality services that barely tickled it. I remember... when I was a lad, you had to solder your own processor to the motherboard and blow an EEPROM with a basic BIOS. Actually, that last bit is true - I feel like I'm one of the last of a dying breed!
So, what about this? Here's some possibilities:
The Von Neumann bottleneck is probably biting our butts. Not just memory though, as more use is made of the HD in modern OS's. More generally, the data comes out of the processor at a huge rate on knots. The first thing it hits is a thing which we shall call a north-bridge. This generally does AGP (where applicable), PCI and the memory bus. The data-transfer across this piece of silicon would have to be huge - an error, or sub-optimal bit of this would certainly have a big effect. Peripheral devices, such as USB, HD control, serial and parallel interfaces are then bundled into a south-bridge. More often than not, this sits on the PCI bus. So, paged memory in the OS has to pass through the north-bridge, across the PCI bus and through the south-bridge on it's way to the HD. Plenty of scope here for bottlenecks.
Onboard gfx with shared memory is, imho, the biggest pile of pap on the planet! Every screen refresh, the card has to request all it's memory from main memory. Now, dear reader, re-read the previous paragraph! Not only is the memory bus being used for normal processor operations (remember that a processor can easily fill this bus) but you're whapping a screenful of information across the bus 60times per second. Nuts!
Bloatware screws things too. When a simple web-browser can hog 100megs of memory, we have to think to ourselves that something is wrong. Pushing this amount of data around cannot be necessary and would certainly have an effect on performance. But more fundamentally, when the OS has a lot in memory it will generally page more and hence have to traverse between the memory and the HD more.
So... an answer? Hmm, difficult!
Certainly the next big thing on the horizon is big, multi-processor machines. IBM's recent T-FLOP 80-core processor was an early example of what is to come. In order to utilise this, programs will have to be written differently. parallelisation will become the watch-word. We will have to think in terms of tiny, interacting nuggets that can run in parallel, rather than monolithic, synchronous programs. I think will then help with the memory bottleneck, but I'll investigate this later.
Why is my PC is starting to creak even though it has 2G memory, a superfast HT P4, SATA, a mega gfx card, etc. I remember (whistful reminiscence ensues, cue scratchy violin music and sepia, soft focus imagery) a P166 with 16Meg and a 1G IDE HD playing Quake and Duke Nukem. I remember programming image manipulation programs and virtual reality services that barely tickled it. I remember... when I was a lad, you had to solder your own processor to the motherboard and blow an EEPROM with a basic BIOS. Actually, that last bit is true - I feel like I'm one of the last of a dying breed!
So, what about this? Here's some possibilities:
The Von Neumann bottleneck is probably biting our butts. Not just memory though, as more use is made of the HD in modern OS's. More generally, the data comes out of the processor at a huge rate on knots. The first thing it hits is a thing which we shall call a north-bridge. This generally does AGP (where applicable), PCI and the memory bus. The data-transfer across this piece of silicon would have to be huge - an error, or sub-optimal bit of this would certainly have a big effect. Peripheral devices, such as USB, HD control, serial and parallel interfaces are then bundled into a south-bridge. More often than not, this sits on the PCI bus. So, paged memory in the OS has to pass through the north-bridge, across the PCI bus and through the south-bridge on it's way to the HD. Plenty of scope here for bottlenecks.
Onboard gfx with shared memory is, imho, the biggest pile of pap on the planet! Every screen refresh, the card has to request all it's memory from main memory. Now, dear reader, re-read the previous paragraph! Not only is the memory bus being used for normal processor operations (remember that a processor can easily fill this bus) but you're whapping a screenful of information across the bus 60times per second. Nuts!
Bloatware screws things too. When a simple web-browser can hog 100megs of memory, we have to think to ourselves that something is wrong. Pushing this amount of data around cannot be necessary and would certainly have an effect on performance. But more fundamentally, when the OS has a lot in memory it will generally page more and hence have to traverse between the memory and the HD more.
So... an answer? Hmm, difficult!
Certainly the next big thing on the horizon is big, multi-processor machines. IBM's recent T-FLOP 80-core processor was an early example of what is to come. In order to utilise this, programs will have to be written differently. parallelisation will become the watch-word. We will have to think in terms of tiny, interacting nuggets that can run in parallel, rather than monolithic, synchronous programs. I think will then help with the memory bottleneck, but I'll investigate this later.
Subscribe to:
Posts (Atom)