CPU DB: Looking At 40 Years of Processor Improvements 113
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."
An even longer way (Score:5, Interesting)
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.
Re:An even longer way (Score:5, Funny)
Re:An even longer way (Score:5, Funny)
Re:An even longer way (Score:5, Funny)
How I did that will have to be my little secret.
-- hendrik
Re: (Score:3)
Re:Not Mel (Score:4)
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
Re: (Score:2)
PS: The guy who taught me programming in 1981 was 75 years old and had been a paratrooper during WWII before getting into electronics and computers. I don't know why I just remembered that...
Re:Not Mel (Score:5, Interesting)
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
its not the language any more, its libs and tools (Score:3, Interesting)
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. O
Re:its not the language any more, its libs and too (Score:5, Informative)
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
Re: (Score:2)
Hogwash. It depends on the domain (industry). Type-related errors make up only a minority percent of errors I encounter in dynamic languages (and many of them could be caught with Lint-like "suspicious" code detectors).
Plus, debugging is often faster with dynami
Re: (Score:1)
I realize our classifications here are over-simplified to keep the replies short. In practice, though languages tend to fall into one pattern or the other along with related features. Yes, I know, there are exceptions.
No, but I don't think it will ever become a mainstream language (for reasons I won't go into) such that job offers for it are not likely even if I did grow to like it.
Re: (Score:1)
Perhaps, but the practicality of such detailed specification is questionable for many domains.
Re: (Score:2)
dang, my mod points expired yesterday. I want to mod this up so much.
Re: (Score:1)
I've used the excellent and fast Algol 68 compiler long long ago on a CDC Cyber computers
I've never used Algol 68 'in anger', only played with it, but it always stuck me as rather elegant in an uber-nerd sort of way.
On a fairly trivial note, I always likely the keyword reversal - IF...FI, CASE...ESAC. I found it makes the code logic stand out more than other schemes. Although that does seem to create a potential problem if you want to use a palindromic word...
Re: (Score:2)
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.
As a system programming language I chose C as my favorite tool for the job.
What would you say are the main advantages of choosing Modula 3 versus C as a system programming language?
I agree with your comments about strong typing catching more problems earlier, and thus if Modula 3 is able to express stronger typing than C, that seems to have its advantages (with some loss of versatility/flexibility perhaps?) Does this have for example drawbacks when trying to add generic programming elements? I find void * u
Re: (Score:2)
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.
As a system programming language I chose C as my favorite tool for the job.
What would you say are the main advantages of choosing Modula 3 versus C as a system programming language?
The main advantages of Modula-3? It is a secure language. The places in the code where you use insecure features (like type-punning) have to be explicitly and obviously marked -- usually in the first line of the module you're writing. Instead of MODULE FOO; you write UNSAFE MODULE FOO;
By contrast, in C you can do type-punning almost by accident by various forms of union and pointer misuse.
I agree with your comments about strong typing catching more problems earlier, and thus if Modula 3 is able to express stronger typing than C, that seems to have its advantages (with some loss of versatility/flexibility perhaps?) Does this have for example drawbacks when trying to add generic programming elements? I find void * useful in that regard.
In Modula 3 there's an explicitly available UNSAFE operation that enables you to look at values of one type as if th
Re: (Score:2)
Have you looked at go?
Strong typing, ridiculously fast compiles, garbage collection, python-like maps and slices, and a decent standard library.
http://golang.org/ [golang.org]
Re: (Score:2)
Not yet. But I have briefly looked at Opa, which seems to me another clever language design.
-- hendrik
Re: (Score:2)
Re: (Score:3)
Back in the days of magnetic drums it was common for instructions to specify the address of the next instruction, to handle drum rotation latency. Were their assemblers that smart, or did programmers do instruction scheduling by hand?
...laura
Re:An even longer way (Score:5, Informative)
They were smart. At least the one I had documentation for was. And the programmer could override it if he thought he was smarter. But the assembler needed a newer model of computer than the one I had -- one that could actually read and write letters on its typewriter instead of just digits. (though u, v, w, x, y, z counted as hexadecimal digits)
The machine, in case anyone is interested, was a Bendix G-15d.
That was in 1962, if I remember correctly. I think the machine was about 5 years old. The next year the university got an IBM 1620, with alphanumeric I/O and 20,000 digits of actual core memory. Change was relentlessly fast in those days, too. THe big difference is that every few years we got qualitative, not just quantitative change.
-- hendrik
Re:An even longer way (Score:5, Interesting)
That was in 1962, if I remember correctly. I think the machine was about 5 years old. The next year the university got an IBM 1620, with alphanumeric I/O and 20,000 digits of actual core memory. Change was relentlessly fast in those days, too. THe big difference is that every few years we got qualitative, not just quantitative change.
We do still get qualitative change in computing today, just that for *most* of what people actually do with computers, they're fast enough that the human is the limiting factor. For anything where human input isn't a factor (think large number crunching operations), there is still a noticeable difference from generation to generation.
Case in point... I do a fairly large amount of video encoding (DVD rips, and other stuff). I use 64-bit software, with a 64-bit operating system. I have recently upgraded from a first generation i7 to a second generation i5. I did go from 4GB to 16GB of RAM, but the actual usage when doing the transcode operation has remained stable, around 1.2GB in use (there's no swapping happening on either system), and the actual type of memory used is the same (speed and bus). That said, the transcode opertation from the original mpeg2 DVD rip to h.264 has gone from about 20 minutes for a 42-minute TV episode to 6 minutes for the same 42-minute TV episode, all else being equal. The difference... I went from a quad core/ht i7 (8 processes at 1.6GHz) to a quad core i5, overclocked (4 processes at 4.7GHz). I went from a top end processor 1 generation old to a current generation midrange processor, and saw a *huge* improvement in performance for a number-crunching heavy operation. now... I am pushing less than double the number of operations per second (8x1.6 = 12.8, 4x4.7 = 18.8), but there is more than a double improvement in real world performance. This is down to improvements in the architecture of the processor, and how it handles the operations.
That being said, my Facebook page doesn't load any faster than it did with the i7 (or on my celeron-based laptop for that matter), and my ability to type is still the limiting factor in how quickly I can use a word processor. If you're not doing heavy number crunching, there is almost no reason to upgrade your computer today (power consumption is an argument that can be made, but the difference is rarely enough to make up for the cost of buying a computer).
Re: (Score:3)
You could still largely use the same code, right? That would make it a quantitative difference.
But there is a saying that an order of magnitude is by itself a qualitative difference.
Re: (Score:1)
Running 8 threads on a parallel task doesn't really result in 8x more processing power. A good solid non-blocking strategy across multiple threads results in exponential gains, but it's rare to find software that's like that. h.264 is a great example though of how effective a solid non-blocking strategy can be in a task that is highly parallel by it's very nature.
Sadly most of the gains in processing speed have been dwarfed by HDD speeds. Recently had to calculate atmospheric data with samples every 30min s
Re: (Score:1)
So how much data? 100 gb? 200gb?
Time to get a new server with at least 64gig ram, and use 4 x 512gb intel SSDs
Yes, its a little more money $320 worth of ram + good mb $1000 + $4000 in SSDs.
Give linux 1500gb of swap and let the OS handle caching.
Do you ever need more than 2 days of data in ram at the same time?
Re: (Score:1)
If I recall correctly the drums used capacitors to store the data, very early dynamic RAM
Re: (Score:2)
Re: (Score:1)
The first random-access digital storage device was a...http://en.wikipedia.org/wiki/Williams_tube
Re: (Score:2)
I'm not old enough to remember those.
They've come a long way... (Score:5, Funny)
... but apparently haven't improved enough to survive a beatdown from /.
Wow - is it just me (Score:3)
Re: (Score:1)
Or is it slashdotted already. You would think Stanford would have better infrastructure
It not just you. Slashdot hits again.
Re: (Score:3, Funny)
It's an Erlang webserver running on a 4004, give it time.
Re: (Score:1)
It's just some box in some grad student's office somewhere
Seems rather limited to Intel. (Score:5, Insightful)
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.
Re:Seems rather limited to Intel. (Score:5, Informative)
Cheers,
Ian
Re: (Score:3, Informative)
Same problem here.. cant see it..
And especially don't forget Motorola, or IBM, Dec, Sun, RCA, Intersil, TI, MIPS, etc etc... Even within the Intel camp id hope they branch into other architectures other than ix86, like ix432 and960, for example.
Re: (Score:1)
6800, 6809 (Score:1)
I've written some programs for the 6800, but I have worked years programming for the 6809. Great CPU, good instruction set, easy to do the hardware interfacing.
Perhaps someone will write a 6809 emulator on a PIC or Atmega microcontroller. That would be fun to play with!
Re: (Score:3)
Re: (Score:1)
We also still have customers running 286 based voice mail systems because they are so reliable.
In many applications reliability trumps speed. Not to mention that you have a de
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Don't model #22 bending units use a 6502 processor?
Re: (Score:3)
Re: (Score:2)
What part of "the public is encouraged to contribute" did you not get?
Re: (Score:2)
While i will agree with you that it should include more than Intel.. it is a CPU database and doubt DSP's would be included do to the fact that are well, not CPU's..
But on the other hand the same type of setup for common types of IC's would be useful
Re: (Score:2)
Re: (Score:2, Troll)
No, processors didn't exist before IBM. Unless you are counting mechanical ones.
Re: (Score:2)
Yes, but they were (usually) designed for only one specific model of computer. And they weren't single-chip microprocessors. This CPU DB seems to be for the latter.
I don't see ARM in here (probably because they don't mass produce their designs, they license them to other chip makers), bu
Improving software (Score:3)
Re: (Score:3, Insightful)
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.
Re:Improving software (Score:5, Informative)
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.
Re: (Score:2)
Much needed catalogging (Score:4, Insightful)
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.
Re: (Score:1)
Re: (Score:2)
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.
In some ways, yes, in other ways no. A PC I bought in 1991 was horribly obsolete by 1995. A PC I bought in 2003 is still useful today, running Windows 7, etc. A PC I bought in 2006 is still useful today, without doing any upgrades. Crysis? No. But they're still more than adequate for surfing, word processing, Youtube, etc.
What I'm amazed at is the increase in complexity. In the 80s you'd see systems designed by one or two people (I'm thinking Woz and the Apple I and Apple II). Now you're seeing new systems
Re: (Score:2)
Of course... Thanks to open-source tools that support massive lists of file-types, I don't see this happening a lot. I'm sure there's some specific proprietary files that require one specific version of a program to read... But, thanks to emulators, even that isn't a problem so long as you can find /some/ commonality between emulated system and host for getting the data off.
Re: (Score:2)
I was thinking of my proprietary closed sourced systems. Anything from the past 12-14 years can run WindowsXP, and things from the past 8 years can run Windows 7.
Re: (Score:2)
Well, erm... /no way/ most of those would run Windows 7 - Do you think that AMD or Nvidia has w7 drivers for things that far back? No way. /was/ able to (slowly) run the OpenGL mode of R
8 years ago was 2004. You're talkihg about Pentium M and later Northwood P4s. There's
Linux on the other hand... No problem. I'm currently running 10.10(current when I installed it) on a HP TC1100, which is ~9 years old, and I was able to use an older set of Nvidia blobs with it's Geforce 4 Go chipset. May not be much, but it
so the 'liberal art' of library science (Score:2)
is not to be shat upon after all? because i thought to be a 'real IT guy' i had to make "witty" comments about "you want fries with that" directed at anyone who had a degree that did not come from the college of engineering.
Re: (Score:2)
Improvements in debugging? (Score:3)
We're still using
print "I got to #1" \ print "I got to #2" for debugging!
Re: (Score:2)
Inside of a conditional breakpoint set in a gui debugger of course.
Re: (Score:1)
We're still using print "I got to #1" \ print "I got to #2" for debugging!
If those are your actual debug code instructions, your problems may run deeper than you think.
:)
Re: (Score:1)
Why 740? (Score:1)
Slashdotted. (Score:2)
Turns out RISC is optimal (Score:2, Interesting)
Well, CPUs started off mainly as CISC, and after realizing that not all modes of operations are really needed if higher level languages are used, they migrated that to RISC. In RISC, as parallelism concepts kept gaining milege, they tried dumping more of the functionality to the compiler in the form of VLIW and EPIC architectures, but the ROI was simply not there, as Itanic showed. The tragedy of the Itanic's introduction was that it saw to the demise of far superior and well established CPUs, such as PA-
Re:Turns out RISC is optimal (Score:5, Funny)
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.)
Re: (Score:2)
As long as x86 CPUs continue to support 32-bit, they'll remain CISC, since there are instructions there that require multiple clock cycles to complete. However, if a CPU came out that no longer supported those modes, then the new 64-bit only CPU would be RISC.
I didn't get what you're trying to argue - that it won't be RISC, or that performance will keep increasing linearly or exponentially as one keeps throwing cores at it? (While I don't use sms abbreviations, I do make use of things like '&', '@' s
Re: (Score:2)
As long as x86 CPUs continue to support 32-bit, they'll remain CISC, since there are instructions there that require multiple clock cycles to complete. However, if a CPU came out that no longer supported those modes, then the new 64-bit only CPU would be RISC.
x86-64 is CISC, not RISC. The processors are internally RISC, but the x86 instruction set is Complex. In fact it seems that x86-64 is even more CISC, because they keep inventing new specialized instructions that were not there in any 32-bit x86 CPU.
Perhaps you are confusing this with the fact that there are other 64-bit architectures, most of which are RISC?
I didn't get what you're trying to argue - that it won't be RISC, or that performance will keep increasing linearly or exponentially as one keeps throwing cores at it? (While I don't use sms abbreviations, I do make use of things like '&', '@' since those are by no means indecipherable)
Scaling for a bigger number of cores depends entirely on the application you're running. You cannot generalize these things. I think I know what I'
Re: (Score:2)
From what I understand, all the 64-bit mode instructions complete in a single cycle, not multiple. Previously, I too was under the impression that they were CISC, but looks like when AMD extended the instruction set, they didn't make the instructions that take multiple clock cycles 64-bit. In fact, the term RISC, which stands for Reduced Instruction Set, is somewhat misleading given that many RISC architectures - particularly PPC - have a huge number of instructions. All it is is that every instruction h
Re: (Score:2)
NonStop Guardian also embraced Itanium.
Re: (Score:1)
Re: (Score:2)
Obviously need to measure power to the CPU, not wall power.
That'll be quite difficult on the older, non-microprocessor based machines (say, the 1980 vintage minicomputers) where the "CPU" was a 6u or 7u drawer in a rack. /frank
Why not partner rather than reinvent from scratch? (Score:4, Informative)
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 [cpu-world.com]. 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.
Re: (Score:2)
Re: (Score:2)
The guy who founded that site and the others who contribute are hobbyists and collectors, meaning that they have available to share what has interested them personally. If you're an aficionado of IBM processors - and apparently you'd be in a minority - then contribute what you have and know. That's way the process works to the benefit of everyone. Perhaps others will see what you contribute and also become fascinated with IBM's processors.
Re: (Score:2)
Just because someone's done a good job with the x86 architecture, doesn't mean they've done much more than scratch the surface.
Re: (Score:2)
Cut and paste from my response to the other get-off-my-lawn griper:
The guy who founded that site and the others who contribute are hobbyists and collectors, meaning that they have available to share what has interested them personally. If you're an aficionado of IBM processors - and apparently you'd be in a minority - then contribute what you have and know. That's way the process works to the benefit of everyone. Perhaps others will see what you contribute and also become fascinated with IBM's processors.
Re: (Score:2)
Should be useful (Score:2)
For a rather weird video game I'm making (will post it on /. as soon as it's ready), I compiled a list of literally thousands of processors. As of now, I believe I have every x86 processor (Intel, AMD, Via, Centaur, NSC, etc., from the 8086 to Ivy Bridge), every Itanium, quite a few POWER and SPARC chips and a handful of MIPS.
I'd like to contribute it - it has some factual errors, such as where I couldn't find actual prices and had to guess, and it has some less relevant stuff, like what integrated GPU, if
No 6502? (Score:1)
Cool idea but a little barren. (Score:2)
Seems a little barren at the moment. I can see several important microprocessors missing from the early days that would be fun to compare.....
MOS/WDC 6502/65C02/65816 - How could they *NOT* have a freaking 6502 in there?! Pretty sure the 6502 outsold the 8080!
MicroPDP-11 - J11?
MicroVAX - CVAX, NVAX, PVAX, etc
RCA 1802 - Still a couple floating around a few million miles away. Probably still working.
At least Alpha and SPARC are in there. This is definitely a cool effort. Will likely end up pretty complet
Missing the Fastest Microprocessor! (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
MIPS & SGI (Score:3)
One thing that struck me - within the MIPS family of processors, everything up to R8000 was listed under MIPS, while R12000 and R14000 was listed under SGI. No mention of R10000
That strikes me as curious. Did SGI keep the R1x000 CPUs to itself when it spun off MIPS? B'cos when MIPS/SGI switched from the superpipelined R4x00 to the superscalar R8000 & R10000, MIPS was very much a part of SGI. Only that afaik, the R8000 and R1x000 never got used outside SGI. So I'd think that in the MIPS family, everything up to R5000 would be w/ MIPS, and the ones above it are now dead, since SGI itself switched from R1x000/Irix to Itanium/Linux.
Numbers (Score:1)