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 /.
Or is it slashdotted already. You would think Stanford would have better infrastructure
I have mod points and I am not afraid to use them
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.
Nothing improves software performance like new hardware.
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.
Hardware is much better, but software?
We're still using
print "I got to #1" \ print "I got to #2" for debugging!
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
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.
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!
640 kHz should be enough for everyone. Besides, one of my favourite data-processing chips is the 741, so it must be one better.
Escher was the first MC and Giger invented the HR department.
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...
Non-Linux Penguins ?
Whatever CPUs they were using are melted now.
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-RISC and Alpha: yet in terms of market acceptance, the only OSs that embraced it were HP/UX, FreeBSD and Debian Linux.
Also, once concepts like multiple threading and parallelism - long there in Unixes from Solaris to Dynix - started taking hold in NT based OSs like XP and beyond, turned out that even better than VLIW was multiprocessing, or dumping more cores @ that problem. 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. At which point, performance improvements will undergo a quantum leap. Of course, for general purpose usage, todays processors are more than adequate, so what might happen is that it would be an opportunity to provide the same performance w/ lower power consumption.
One thing that is painfully missing from the CPUdb is accurate energy measurements while running benchmarks. If anyone has a vintage machine they could do the following: compile and run spec and measure the energy consumption (a plot of power vs. time will suffice here). Obviously need to measure power to the CPU, not wall power.
The point is to measure both raw performance and energy efficiency, i.e. given that in today's processes power is the performance limiting constraint.
Further notes:
The CPUdb mainly captures the CMOS era (386 to present day). It does have a variety of manufacturers -- not just Intel. Intel happens to be very prolific, especially coming through the 2000s.
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.
I don't see the 80186 listed, even though it was in production all the way up to 2007.
I'd like to see the same for hard drives.
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 any, it has. But hey, it's already several thousand processors, that's got to be a good start.
And, if this CPU database starts growing, I'm excited because it will make adding the *rest* of the processors easier. ARM in particular is hard to find full, definite lists of, because it's a licensed architecture instead of fabricated.
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
What the fuck are they smoking!?
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.
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 complete one day.
None of the IBM z/Architecture microprocessors (or their ESA/390 and prior predecessors) are listed yet. So Stanford is only missing the highest clock speed CPU ever created in the entire history of computing to date -- the IBM z196 microprocessor. Which seems like a rather serious and obvious omission. Also a bit insulting, since IBM has been announcing their new z/Architecture microprocessor breakthroughs exclusively first at Stanford's own "Hot Chips" conference for several years now. (Ooops.)
I couldn't find any reference to IBM processors in the CPU World database even though IBM has been a major player for many years.
If I used a sig over again, would anyone notice?
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
does it have another name?
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.
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.
I liked Algol 68 too, but come on, it doesn't cut it any more. Just compare it to a modern language like Java or PHP. There is no equivalent to (PHP): 'foreach', 'explode', 'join', 'stripos', 'date', 'str_replace', 'mysql_query' and associative arrays. Libraries and functionality make all the difference. It takes these types of construct or function to make real progress against real world problems. Otherwise you are left shuffling bits.
In a contest to write real applications Algol 68 is left in the dust. Sad but true.
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 dynamic languages because you don't have to wait for the long compile step to study the bug by altering the code, adding logging statements, etc.
And, dynamic languages are usually easier to read than compiler-centric languages (at least to my eyes). Easier-to-read means that it's easier to review the code for for bugs and design problems. The heavy-typing/compiler style tends to make the code bureaucratic and long-winded.
Further, dynamism allows more meta-programming techniques to add design-simplification abstractions.
Table-ized A.I.
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).
A good strongly typed language turns almost all errors into type-errors, that are cought at compile-time. This is taken to an extreme in for example agda where you cannot index an array out of bounds because of its type (which is also provable)
Plus, debugging is often faster with dynamic languages because you don't have to wait for the long compile step to study the bug by altering the code, adding logging statements, etc.
And, dynamic languages are usually easier to read than compiler-centric languages (at least to my eyes). Easier-to-read means that it's easier to review the code for for bugs and design problems. The heavy-typing/compiler style tends to make the code bureaucratic and long-winded.
Further, dynamism allows more meta-programming techniques to add design-simplification abstractions.
Have you ever tried Haskell? One normal line of Haskell often takes 10 lines of your average dynamic language. And since Haskell is a functional language it allows very nice abstractions with type-checked meta-programming.
Also debugging is easier in interpreted languages, not dynamic ones, which you seem to confuse.
I wasn't very impressed with CPU-World's coverage of the POWER architecture. Or Alpha. Or HP-PA. Or Sparc. Or MIPS. Or ...
Just because someone's done a good job with the x86 architecture, doesn't mean they've done much more than scratch the surface.
Also FatPhil on SoylentNews, id 863
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.
Instead of relying on personal experience, try looking up your CPU from history in here: http://www.cpubenchmark.net/cpu_list.php The cpus date back to an Celeron 600mhz (Probably one of those Slot A types) up to current. Using the numbers from that link also, that cpu gets a "passmark" of 103. A current i7 3930k gets 13567. In other words, it is over 131 times faster.
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...
dang, my mod points expired yesterday. I want to mod this up so much.
Suppose you were an idiot and suppose you were a member of Congress
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.
Table-ized A.I.
Perhaps, but the practicality of such detailed specification is questionable for many domains.
Table-ized A.I.
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 * useful in that regard.
I have been always skeptical about garbage collection, after having first hand experience with Java.
Does Modula 3 give control / options about garbage collection and its memory management strategies?
C memory management may be a pain, but at the same time it gives me more or less what I want, when the need for dynamic allocation cannot be simply avoided, but still a somewhat predictable run-time behavior is desirable.
I studied the glibc implementation of malloc and friends, which I tend to prefer compared to different implementations of mallocs available by default on SunOS 5.8 and Solaris 10 and other Unices.
Could you give me/all some pointers to memory management under Modula 3?
I am asking about Modula 3 since you are pitching it as a system programming language, but if you think this also relates to Algol 68, I'd like to know as well.
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 they are of another. It's almost never needed.
If you're using its object-oriented features, there's a type ANY that allows you to point to any kind of OBJECT. You need explicit type-tests to convert it to something more specific so you can do stuff with it beyond just pass it around.
Further, it's possible to parameterize entire modules with a type. This is another form of generic programming.
I have been always skeptical about garbage collection, after having first hand experience with Java.
You compare to Java? Java is an implementation mess in this respect, primarily because it wants you to use classes for everything, and class overhead is significant. For example, every object contains a semaphore in case you want to use it in two differente threads. It won't even allow the slight amount of type abstraction you can get in C by writing typedef foo bar; And once you end up using heap-allocated classes for everything you'd normally use structures for, you've accumulated a lot of overhead. I don't know how Google's new Java code generation fares -- you know, the one they use in Android. It might be different. Anybody know?
Modula 3 also has STRUCTures much like C's. They don't need to be on the garbage-collected heap, though they can be. They don't take part in object inheritance. They are safe features.
Does Modula 3 give control / options about garbage collection and its memory management strategies?
There are garbage-collected types and nongarbage-collected types. REFERENCE TO Foo is collected, whereas UNTRACED REFERENCE TO Foo is not. You are advised to use UNTRACED storage for data structures you wish to pass to C so the garbage collector won't get in C's way.
By the way, I'm talking about features I rarely need to use here, so my syntax may be rusty.
C memory management may be a pain, but at the same time it gives me more or less what I want, when the need for dynamic allocation cannot be simply avoided, but still a somewhat predictable run-time behavior is desirable.
I studied the glibc implementation of malloc and friends, which I tend to prefer compared to different implementations of mallocs available by default on SunOS 5.8 and Solaris 10 and other Unices.
Could you give me/all some pointers to memory management under Modula 3?
Why would I want to contribute to this site that clearly has next to no interest in the things I'm interested in? They don't even *acknowledge the existence of* the majority of the CPU architectures that have hit the market in the last 4 decades.
Also FatPhil on SoylentNews, id 863
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/
Not yet. But I have briefly looked at Opa, which seems to me another clever language design.
-- hendrik