Slashdot Mirror
CPU DB: Looking At 40 Years of Processor Improvements
CowboyRobot writes "Stanford's CPU DB project (cpudb.stanford.edu) is like an open IMDB for microprocessors. Processors have come a long way from the Intel 4004 in 1971, with a clock speed of 740KHz, and CPU DB shows the details of where and when the gains have occured. More importantly, by looking at hundreds of processors over decades, researchers are able to separate the effect of technology scaling from improvements in say, software. The public is encouraged to contribute to the project."
Processors have come an even longer way wince the days when main memory was on a magnetic drum, and the machine had to wait for the drum to revolve before it could fetch the next instruction. That was the first machine I used.
... but apparently haven't improved enough to survive a beatdown from /.
Processors did exist before Intel. IBM, Sperry, Amdal, Burroughs, DEC, Honeywell...
And the speed improvement there paved the way for Intel.
for an "IMDB" of processors, it really needs to include others - ARM, AMD (though that might be covered by the Intel) and still others exist. The DSP processors are also significant as many improvements there migrated to other implementations.
It's an Erlang webserver running on a 4004, give it time.
Technology, as it is today, is all too fleeting. New technology is being pushed out at an ever increasing rate with the new products quickly supplanting the old. The old is then quickly forgotten. I applaud the effort of this group in its work to keep a living record of the heart of the machines that have been the core of most of lives for almost half a century.
On a slightly note, I believe we need better cataloging of technology in general as many old file are effectively being lost due the technology require to read them no long exist. Of course this raises further questions of how to maintain such cataloging as the cataloging infrastructure ages so that the data doesn't get lost. Oh what a vicious cycle it is.
Software 'Improves' to use up all that performance gain BEFORE the next CPU Improvement appears.
i.e. Software Bloat uses up all the gains at a quicker rate than the H/W can give it.
It's deliberate. There was a podcast interview with some Microsoft engineers regarding future COM enhancements. They were waiting for the hardware to get faster and for memory to increase just so they could give every class member its own lock.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
No, I'm not Mel. I did try programming it in machine code, though, instead of the high-level (all numerical, though) interpreted language it provided, and got nowhere. Perhaps I needed an oscilloscope as a debugging tool, and didn't have one. What I managed to learn of the machine language I figured out by reading the circuit diagrams. But I wasn't Mel, and I really appreciate decent languages and programming tools. Pity there are so few of them, even now. The best seem never to have been popular.
-- hendrik
I can't even look at what Stanford is trying to do right now, but there have existed for years at least two online CPU "museums" that serve this goal. The one that readily springs easiest to mind - the one I've used most myself - is CPU-World. It has extensive coverage of all the major CPU lineages, including photos submitted by users, and even includes some non-CPU silicon. It seems to be largely the creation of one guy, Gennadiy Shvets, with eager collaboration from a lot of fellow enthusiasts, and there seems to be no profit motive to the site that I've ever noticed. He even thanks the most prolific contributors by name.
WHY would Stanford feel it was necessary to "divide and conquer" this enthusiasm by creating an entirely new site and museum, rather than focusing the collective interest by contributing to or partnering with the one(s) that have already existed for many years? On the face of it this effort looks like either ignorance or pointless competition.
Actually, even that solution shows diminishing returns after 4 CPUs - you can keep throwing cores @ it, but the performance improvements will be minimal. Ideal solution is to have as RISC-like a CPU as possible, and then have 4 cores of it in a CPU set-up, and one is off to the races.
Right now, x86 still has to support 32-bit modes, but once it's no longer needed, x64 will be a purely RISC CPU.
Can I have some of what you're smoking? Also, your usage of "@" is so very cyber, in a 90s way.
(I have an x86-64 machine with 4 CPUs running in 64-bit mode, meaning its ISA has magically changed from CISC to RISC. However, I'm posting this on a PowerPC running Gentoo, so as not to contaminate the message with any CISCy remains.)
Escher was the first MC and Giger invented the HR department.
I really like strongly typed, garbage-collected, secure languages that compile down to machine code. I've used the excellent and fast Algol 68 compiler long long ago on a CDC Cyber computers, and now I use Modula 3 on Linux, when I have a choice. They compile down to machine code for efficiency, and give access to the fine-grained control of data -- you can talk about bytes and integers and such just as in C, but they still manage to take care of safe memory allocation and freeing.
Modula 3 is a more modern language design, though I have a subjective preference for the more compact and freer-style ALgol 68 syntax. Modula 3 has a clean modular structure which is completely separate from its object-oriented features. You're not required to force everything into object types. You can if it's fits your problem, but you can still use traditional procedural style if that's what you need.
And Modula 3 functions well as a systems programming language. It has explicit mechanism to break language security in specific identified parts of a program if that's what's necessary. It almost never is.
And, by the way, to avoid potential confusion, Modula 3 was *not* designed by Niklaus Wirth. Modula and Modula 2 were, but Modula 3 is a different language from either.
-- hendrik
It doesnt matter how good any language is, its the available framework tools and libraries which make it useful.
ie, C by it self, is simple and takes lots of coding to make something useful (if you do not use any libs at all)
Strongly type langs can be a bitch if you are editing in VI/VIM, as they dont 'know about the language' to auto help you out, besides colors. Today cpus are so fast, the IDE should help you program, and act as if types are free, and the IDE can auto determin types, and fix it for you. Otherwise if you have to spend 20% of the byte space of your language defining types and pre casting EVERYTHING, then its not an efficient and smart human friendly language.
Its kind of funny, that in assembly language, you only really have 3 types of ints plus floats, and pointers, and are free to interpret values to your imaginations content.
If you have to reinvent everything because its not there, then youre wasting your time.
Liberty freedom are no1, not dicks in suits.
The point of strong typing is not to tell the compiler how to make your program efficient. That's a pleasant side effect, but it's not the point at all. The point is to tell the compiler, possibly redundantly, what kind of values you intend to have in variables, so it can tell you when you get it wrong. Proper strong typing can catch almost all coding errors before your program is ever executed. It takes longer to code it and get it through the compiler, sure, but the time you lose this way is far outweighed by the reduced time you spend debugging.
In addition, the explicit type information on all function definitions makes it vastly easier to understand a program you've never seen before when it's handed to you.
Yes, there are a few situations where you can't specify types statically. They are pretty rare in a properly designed type system. A good language has mechanisms to handle the few cases that still remain.
-- hendrik