What follows is a cut-down version of the cover feature of the 50th issue of HardCopy magazine, originally published Nov 2010:
Any attempt to foretell the future is fraught with difficulties, to say nothing of the potential for the sort of embarrassment embodied by Thomas Watson’s apocryphal 1943 statement, “I think there is a world market for about five computers.” Nevertheless, let’s give it a go.
Perhaps the safest place to start is with Moore’s Law. This was formulated by Gordon Moore, co-founder of Intel, and states that the number of components that it is economic to put on a single chip doubles every two years. It has remained true from the Intel 4004, introduced in 1971 with 2,300 transistors on the chip, up to Intel’s latest Quad-Core Itanium processor which crams on over two billion.
Up until 2004, Moore’s Law had been synonymous with processing power, although this had more to do with increasing clock-speed than transistor density. However in 2004, Intel realised that it could not increase clock speed any further with existing technology, and that the best way forward was through multi-core processors able to execute more than one instruction at a time. The Intel Core Duo was introduced in 2006, and the Intel Core 2 Quad in 2008. At the time of writing, Intel’s Core i7 range includes two models boasting six cores, while Intel has talked about introducing processors with 64 cores sometime next year. Read More
Up until now, programmers have had it easy. Ever since the first 16-bit processors appeared in the late 1970s, processor speeds have been increasing at an exponential rate, doubling every two years, or more recently, every 18 months. The modern Intel Pentium 4 offers 10,000 times the processing speed of the 8086, found in the original IBM PC. However the essential architecture has remained unchanged, which means programs which ran on last year’s processors continue to run on today’s, only faster. They may need to be recompiled to take advantage of the latest technology, but in the end it has always been hard disk or network access that caused the bottleneck and that wasn’t a coder’s problem.
