Forgot your password?
typodupeerror
Hardware Technology

CPU DB: Looking At 40 Years of Processor Improvements 113

Posted by timothy
from the why-in-my-day-we-didn't-have-binary dept.
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."
This discussion has been archived. No new comments can be posted.

CPU DB: Looking At 40 Years of Processor Improvements

Comments Filter:
  • An even longer way (Score:5, Interesting)

    by hendrikboom (1001110) on Saturday April 07, 2012 @11:44AM (#39606799)

    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.

    • by dargaud (518470) <slashdot2&gdargaud,net> on Saturday April 07, 2012 @12:04PM (#39606889) Homepage
      OK, I'll get off your lawn without even making a snarky comment... Are you Mel [pbm.com] by any chance ?
      • by K. S. Kyosuke (729550) on Saturday April 07, 2012 @12:30PM (#39607007)
        It could be him...look, he only has a /. ID of 154 and he managed to make Slashcode print it out in binary to boot!
      • by hendrikboom (1001110) on Saturday April 07, 2012 @01:00PM (#39607239)

        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

        • by dargaud (518470)
          I wonder what you do consider the 'best languages and programming tools'.

          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)

            by hendrikboom (1001110) on Saturday April 07, 2012 @04:34PM (#39608565)

            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. O

              • by hendrikboom (1001110) on Saturday April 07, 2012 @10:37PM (#39610203)

                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

                • by Tablizer (95088)

                  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.

                  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

                • by gander666 (723553) *

                  dang, my mod points expired yesterday. I want to mod this up so much.

            • by mikechant (729173)

              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...

            • by sick_soul (794596)

              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

              • 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

            • 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]

              • Not yet. But I have briefly looked at Opa, which seems to me another clever language design.

                -- hendrik

    • More bizarre to me was reading about mercury filled tubes as memory.
    • 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

      • by hendrikboom (1001110) on Saturday April 07, 2012 @12:33PM (#39607025)

        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

        • by realityimpaired (1668397) on Saturday April 07, 2012 @01:52PM (#39607561)

          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).

          • 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.

          • by Anonymous Coward

            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

            • by cheekyboy (598084)

              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?

    • by dgharmon (2564621)
      "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.", hendrikboom

      If I recall correctly the drums used capacitors to store the data, very early dynamic RAM ...
    • by hairyfeet (841228)

      Damn and I thought I was old because my first three machines were an Altair, followed by a Trash 80 and a VIC.

      You know what i think made as much if not more of an effect on modern computers? RAM. I remember when a Mb RAM chip would cost you more than a car, and I don't give a crap how powerful your CPU is if you are always waiting on some slow media, be it drum or tape or HDD, to feed the chip then its gonna be hamstringed by the slower media. Now even my $350 netbook has 8Gb of RAM simply because its so ch

    • by Anonymous Coward

      The first random-access digital storage device was a...http://en.wikipedia.org/wiki/Williams_tube

  • by Anonymous Coward on Saturday April 07, 2012 @11:44AM (#39606803)

    ... but apparently haven't improved enough to survive a beatdown from /.

  • by MerlynEmrys67 (583469) on Saturday April 07, 2012 @11:44AM (#39606809)
    Or is it slashdotted already. You would think Stanford would have better infrastructure
    • by Anonymous Coward

      Or is it slashdotted already. You would think Stanford would have better infrastructure

      It not just you. Slashdot hits again.

    • Re: (Score:3, Funny)

      by Anonymous Coward

      It's an Erlang webserver running on a 4004, give it time.

    • by tapspace (2368622)

      It's just some box in some grad student's office somewhere

  • by Anonymous Coward on Saturday April 07, 2012 @11:46AM (#39606819)

    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.

    • by mccalli (323026) on Saturday April 07, 2012 @12:06PM (#39606897) Homepage
      It's slashdotted so I can't tell, but any definitive database really needs MOS and Zilog in there as well. The home and micro computer revolution depended on them, Zilog's Z80 and MOS's 6502.

      Cheers,
      Ian
      • Re: (Score:3, Informative)

        by nurb432 (527695)

        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.

      • I read about it a couple days ago (in ACM) and there was no MOS as of then. There was the Motorola 6800, though.
        • by Anonymous Coward

          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!

      • by hairyfeet (841228)

        What amazes me is how long some of these chips have lasted. There are STILL variants on the Z80 in production and Intel only quit making the 386 in 2009. the z80s are used a lot in little MP3 players and I heard the 386 was popular for military applications as an embedded CPU. I don't think anybody still uses the MOS 6502 though.

        It just goes to show that if a design is well made it can still find uses even after all these years. I wonder if in 30 years AMD will still have some division making Bobcats for

        • Very true. The phone line controllers we use at work use 8088 processors. The whole controller requires no active cooling and are incredibly reliable. The "newer" controllers are built far more compact with more processing power and require active cooling and have been incredibly unreliable, we've been removing them from service.

          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
      • by Relayman (1068986)
        Back up now. Zilog is showing the Z80 but MOS is not there.
    • by shokk (187512)

      What part of "the public is encouraged to contribute" did you not get?

    • by Amouth (879122)

      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

    • by njahnke (757694)
      the wait is quite long at the moment (the site appears to be slashdotted) but the selection of manufacturers is excellent. i saw amd, hp, zilog, sun, dec ...
    • Re: (Score:2, Troll)

      by marcosdumay (620877)

      No, processors didn't exist before IBM. Unless you are counting mechanical ones.

    • by Eil (82413)

      Processors did exist before Intel. IBM, Sperry, Amdal, Burroughs, DEC, Honeywell...

      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.

      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.

      I don't see ARM in here (probably because they don't mass produce their designs, they license them to other chip makers), bu

  • by ISoldat53 (977164) on Saturday April 07, 2012 @11:50AM (#39606833)
    Nothing improves software performance like new hardware.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

  • by Skywings (943119) <skywings_w@yah[ ]com ['oo.' in gap]> on Saturday April 07, 2012 @11:53AM (#39606853)

    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.

    • 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

      • 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.

        • 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.

    • 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.

    • by hairyfeet (841228)

      Which is why we need a "use it or lose it" clause to copyrights and patents. Anybody who likes classic PCs games can tell you we are about to lose an entire generation of games, as more and more of the Win9X era games become unplayable. Its sad that I can play the DOS games all day long but more and more of the Win9X era games are becoming completely unplayable due to the fact they used hacks to get more performance and/or old DRM crap that no longer functions.

      What we need is someone to do for Win9X what th

  • Hardware is much better, but software?

    We're still using

    print "I got to #1" \ print "I got to #2" for debugging!
  • 640 kHz should be enough for everyone. Besides, one of my favourite data-processing chips is the 741, so it must be one better.
  • 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-

    • by TeknoHog (164938) on Saturday April 07, 2012 @03:42PM (#39608275) Homepage Journal

      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.)

      • by unixisc (2429386)

        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

        • by TeknoHog (164938)

          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'

          • by unixisc (2429386)

            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

    • by sconeu (64226)

      NonStop Guardian also embraced Itanium.

      • by unixisc (2429386)
        I actually wasn't counting dead architectures, like NonStop or VMS. Anybody legacy still on those systems should have remained on MIPS/Alpha, and then worked out a migration plan to Windows Server, IBM OSs or Unix. It doesn't make sense for new buyers of Itanium - in case they exist - to embrace the above - they'd be better off w/ HP/UX, FreeBSD or Debian.
  • 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.

    • by Relayman (1068986)
      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.
      • by macraig (621737)

        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.

    • by fatphil (181876)
      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.
      • by macraig (621737)

        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.

        • by fatphil (181876)
          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.
  • 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

  • What the fuck are they smoking!?
  • 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

  • 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 [ibm.com] 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.)
    • by Relayman (1068986)
      I think if you dig you will find that the microprocessors in the z196 are Power7 processors, similar if not exactly the same as are used in the Power Systems. You are right in that they have possibly the highest clock speeds. Of course, Power7 processors are included in the Stanford database.
      • No, they're very different. They have entirely different instruction sets as one example. As another, the z196 is clocked at 5.2 GHz and POWER7 at 4.25 GHz (in the 795 Turbo). The z196 is quad-core while POWER7 is octo-core. POWER7 has about 1.2 billion transistors and z196 about 1.4 million. POWER7 has a private per-core L1 instruction cache of 32 KB; z196, 64 KB. POWER7's private per-core L1 data cache is 32 KB; z196, 128 KB. POWER7's private L2 cache is 256 KB; z196, 1.5 MB. The L3 cache design is differ
        • by Relayman (1068986)
          I stand corrected. It does look like a completely different processor than the Power7 chips. I learned something new today. You should add it to the database.
  • by unixisc (2429386) on Sunday April 08, 2012 @12:18AM (#39610521)

    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.

  • Instead of relying on personal experience, try looking up your CPU from history in here: http://www.cpubenchmark.net/cpu_list.php [cpubenchmark.net] 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.

Wherever you go...There you are. - Buckaroo Banzai

Working...