• Historical evolution of CPU perf

    From Stefan Monnier@monnier@iro.umontreal.ca to comp.arch on Wed Oct 9 12:33:51 2024
    From Newsgroup: comp.arch

    I'm looking for a chart illustrating the evolution of CPU performance
    (e.g. single-threaded or maybe performance per watt) over the years,
    covering something like 1990-2020.

    Any good candidates?


    Stefan
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From BGB@cr88192@gmail.com to comp.arch on Wed Oct 9 13:23:22 2024
    From Newsgroup: comp.arch

    On 10/9/2024 11:33 AM, Stefan Monnier wrote:
    I'm looking for a chart illustrating the evolution of CPU performance
    (e.g. single-threaded or maybe performance per watt) over the years,
    covering something like 1990-2020.

    Any good candidates?


    Yeah, I would also like something like this, or maybe some way to
    "sensibly" compare the relative performance of modern stuff with vintage stuff.

    Like, for example, I can't make sense of whether the performance of my
    current project is similar to similarly-clocked vintage hardware, or potentially significantly faster.

    Based simply on Dhrystone score, it would likely be placed in a similar
    area to a 90s era PowerPC in terms of perf/MHz.



    But, if I add an early 2000s laptop as a reference point, stuff gets
    weird. In various benchmarks, the difference in performance is
    significantly smaller than the relative difference in clock-speed.

    Though, the laptop is also break-even with a RasPi2 in terms of general
    perf (in theory, the laptop should be faster). Seems like the laptop
    suffers a relative deficit in terms of memory bandwidth (*).

    But, can note that Dhrystone doesn't really measure memory bandwidth...


    *: The 100MHz DDR1 RAM in the laptop gets roughly 7x the memory
    bandwidth of a 16-bit DDR2 chip being run at 50MHz. Sort of makes sense
    if one assumes 4x the width and 2x the clock-speed.

    I am not sure if just the laptop, or if RAM access in general was proportionally slower in the 90s. Or, if it is just a case that late 90s
    / early 2000s, CPUs had gotten faster much faster than RAM had gotten
    faster, so there was a performance lag here.

    I suspect it may be the latter, if one linearly extrapolated backwards,
    it would mean 486 PCs running at ~ 10-16 MB/sec for RAM bandwidth, which
    in my own testing seems insufficient to run Doom at acceptable speeds
    (actual 486's having no issues running Doom).

    ...





    Stefan

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Kerr-Mudd, John@admin@127.0.0.1 to comp.arch on Wed Oct 9 20:18:40 2024
    From Newsgroup: comp.arch

    On Wed, 9 Oct 2024 13:23:22 -0500
    BGB <cr88192@gmail.com> wrote:

    On 10/9/2024 11:33 AM, Stefan Monnier wrote:
    I'm looking for a chart illustrating the evolution of CPU performance
    (e.g. single-threaded or maybe performance per watt) over the years, covering something like 1990-2020.

    Any good candidates?


    Yeah, I would also like something like this, or maybe some way to
    "sensibly" compare the relative performance of modern stuff with vintage stuff.

    Like, for example, I can't make sense of whether the performance of my current project is similar to similarly-clocked vintage hardware, or potentially significantly faster.

    Based simply on Dhrystone score, it would likely be placed in a similar
    area to a 90s era PowerPC in terms of perf/MHz.



    But, if I add an early 2000s laptop as a reference point, stuff gets
    weird. In various benchmarks, the difference in performance is
    significantly smaller than the relative difference in clock-speed.

    Though, the laptop is also break-even with a RasPi2 in terms of general
    perf (in theory, the laptop should be faster). Seems like the laptop
    suffers a relative deficit in terms of memory bandwidth (*).

    But, can note that Dhrystone doesn't really measure memory bandwidth...


    *: The 100MHz DDR1 RAM in the laptop gets roughly 7x the memory
    bandwidth of a 16-bit DDR2 chip being run at 50MHz. Sort of makes sense
    if one assumes 4x the width and 2x the clock-speed.

    I am not sure if just the laptop, or if RAM access in general was proportionally slower in the 90s. Or, if it is just a case that late 90s
    / early 2000s, CPUs had gotten faster much faster than RAM had gotten faster, so there was a performance lag here.

    I suspect it may be the latter, if one linearly extrapolated backwards,
    it would mean 486 PCs running at ~ 10-16 MB/sec for RAM bandwidth, which
    in my own testing seems insufficient to run Doom at acceptable speeds (actual 486's having no issues running Doom).


    As a complete non-cpu chap, what I care about is (my) consumer experience;
    - i.e no delays. So ditch the fancy graphics - get me a fast boot time and
    a responsive OS. Only a few are doing FFTs & so-called AI.
    --
    Bah, and indeed Humbug.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From mitchalsup@mitchalsup@aol.com (MitchAlsup1) to comp.arch on Wed Oct 9 19:54:18 2024
    From Newsgroup: comp.arch

    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:


    As a complete non-cpu chap, what I care about is (my) consumer
    experience;
    - i.e no delays. So ditch the fancy graphics - get me a fast boot time
    and a responsive OS. Only a few are doing FFTs & so-called AI.

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Sarr Blumson@sarr@sdf.org to comp.arch on Fri Oct 11 00:27:25 2024
    From Newsgroup: comp.arch

    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.
    --
    sarr@sdf.org
    SDF Public Access UNIX System - http://sdf.org
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From BGB@cr88192@gmail.com to comp.arch on Fri Oct 11 03:03:14 2024
    From Newsgroup: comp.arch

    On 10/10/2024 7:27 PM, Sarr Blumson wrote:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Core memory was before my time, but I remember reading somewhere that it needed to be preheated to a certain operating temperature in order to
    write to it (because the hysteresis energy of the ferrite rings was temperature dependent, and it needed too much power to flip the bits at
    lower temperatures).



    I am left to wonder if one could have made a non-volatile
    electrochemical memory with "ye olde" tech;
    Say, for each memory cell:
    Two lead plates and a thin separator
    With a water + sulfuric-acid electrolyte;
    3 states:
    A: Plate A is lead dioxide, Plate B is lead
    Electrolyte is live.
    B: Like A, but with the plates reversed;
    C: Plates are lead sulfate, preferably avoided;
    Too strong of sulfate, memory cell dies.
    Or, two iron plates, and a separator:
    Similar, but using a potassium hydroxide based electrolyte (1).


    *1: In the C state, the plates would try to convert to iron-potassium
    ferrate, but this process would cause the electrolyte to become slightly acidic (depleting oxygen and leaving an excess of H+ ions), which would decompose the ferrate. In the A and B states, one plate will be metallic
    iron and the other iron oxide, with a basic electrolyte.

    Each memory cell would be constructed more like a capacitor, but would
    be "charged" more like a battery, but with (comparably) very little
    capacity. Bits would be stored in the charge-polarity of each cell.

    Likewise, for RAM like operation, would likely use a fairly dilute
    hydroxide solution (likely much weaker than if it were being used for
    energy storage).


    Memory cells could be separated either by distance or by an insulating barrier, though potentially the electrolyte reservoir could be shared
    between all of the cells (assuming primarily 2 state operation).

    For the iron-hydroxide case, the total amount of free oxygen in the
    system would likely need to be controlled, so it could not be open to
    the atmosphere. If more oxygen could leak in, likely the plates would
    turn into ferrate and the electrolyte would turn into water. With any
    further oxygen turning the remaining iron into iron-oxide.

    Though, charging the cells may drive out the extra oxygen (but, this is
    likely to require considerably more power, and if the process goes on
    too long, it may structurally damage the cells). Similarly, if the
    electrolyte becomes over-saturated with oxygen, then the oxidation
    process would resume as soon as power is removed (unless the cells are
    charged for long enough for any excess free oxygen to diffuse back out
    of the electrolyte).

    For a lead-acid chemistry, free oxygen would not matter.



    Here iron-iron-hydroxide might be preferable for memory cells, as it
    would likely be more stable and have a longer cycle life than a
    lead-based design. Cells would likely have a very low energy density,
    but this doesn't matter for memory cells (and would be preferable for
    RAM like use). One would need a chemistry where cells can be charged in
    either direction and which can tolerate cells being rapidly driven from
    one polarity to another. Here, less capacity also means less energy
    needed to flip a bit (but likely also less stability).

    One would also need the wiring to not interact with the electrolyte.
    Should probably be able to wire up the cells with a crossbar configuration.

    Similarly, the separator would need to be non-reactive with the
    electrolyte. More modern materials, like porous plastic or fiberglass
    would work. Within the limits of older tech, dunno. cellulose was a
    common (such as paper or cotton) but would likely slowly dissolve in the electrolyte solution (I guess, old time solution would probably be to
    use asbestos or similar, or maybe a porous ceramic).

    For similar reasons, could not use bone or leather/vellum (also weak
    against both acids and hydroxides), ...


    ...


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From scott@scott@slp53.sl.home (Scott Lurndal) to comp.arch on Fri Oct 11 14:40:59 2024
    From Newsgroup: comp.arch

    Sarr Blumson <sarr@sdf.org> writes:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Compared to the alternatives at the time, it was the fastest
    gun in the west.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Thomas Koenig@tkoenig@netcologne.de to comp.arch on Fri Oct 11 16:03:45 2024
    From Newsgroup: comp.arch

    Scott Lurndal <scott@slp53.sl.home> schrieb:
    Sarr Blumson <sarr@sdf.org> writes:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Compared to the alternatives at the time, it was the fastest
    gun in the west.

    Reading about the predecessors, the memory delay tubes and the
    Williams tubes (I once saw these in action on the Manchester Baby;
    they were cool, you can see the memory contants directly), _much_
    better in reliability.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Michael S@already5chosen@yahoo.com to comp.arch on Sat Oct 12 21:02:31 2024
    From Newsgroup: comp.arch

    On Fri, 11 Oct 2024 14:40:59 GMT
    scott@slp53.sl.home (Scott Lurndal) wrote:

    Sarr Blumson <sarr@sdf.org> writes:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Compared to the alternatives at the time, it was the fastest
    gun in the west.


    At the time of 11/20 debute (1970) it already was not.
    Custom SRAM was in use for 3-4 years and first OTS SRAM (Intel 3031)
    was shipping for something like a year.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Lars Poulsen@lars@cleo.beagle-ears.com to comp.arch on Sat Oct 12 19:01:38 2024
    From Newsgroup: comp.arch

    On 2024-10-12, Michael S <already5chosen@yahoo.com> wrote:
    On Fri, 11 Oct 2024 14:40:59 GMT
    scott@slp53.sl.home (Scott Lurndal) wrote:

    Sarr Blumson <sarr@sdf.org> writes:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Compared to the alternatives at the time, it was the fastest
    gun in the west.


    At the time of 11/20 debute (1970) it already was not.
    Custom SRAM was in use for 3-4 years and first OTS SRAM (Intel 3031)
    was shipping for something like a year.

    In my embedded/datacomm world, I did not meet solid state RAM until fall
    1980. All the PDP-11/20, PDP-11/05, PDP-11/10, PDP-11/35, and
    PDP-11/45's were still core at that time, and the first system with
    solid state memory that I worked on had a bad bug in the memory, which
    soured me on solid state for a couple of years more.

    Essentially, allocation bitmaps (especially disk allocation bitmaps)
    where you set a bit after it had been 0 for a long time were prone to
    revert after it had not been looked at for another hour. I figure that
    it must have been SRAM.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From scott@scott@slp53.sl.home (Scott Lurndal) to comp.arch on Sat Oct 12 19:06:39 2024
    From Newsgroup: comp.arch

    Lars Poulsen <lars@cleo.beagle-ears.com> writes:
    On 2024-10-12, Michael S <already5chosen@yahoo.com> wrote:
    On Fri, 11 Oct 2024 14:40:59 GMT
    scott@slp53.sl.home (Scott Lurndal) wrote:

    Sarr Blumson <sarr@sdf.org> writes:
    MitchAlsup1 <mitchalsup@aol.com> wrote:
    On Wed, 9 Oct 2024 19:18:40 +0000, Kerr-Mudd, John wrote:

    I remember the PDP-11/20 in the computer lab at NCR.
    Last person out at night would flick the power switch OFF, and
    the computer was OFF in 1/60 of a second.
    First person in would flick the switch ON and the computer was
    back where it was turned off in 1/60 of a second.

    We used the 11/20 as a remote debug device for the 8085 cash
    register machine(s) we were building.

    Core memory: slow to access but also slow to forget.

    Compared to the alternatives at the time, it was the fastest
    gun in the west.


    At the time of 11/20 debute (1970) it already was not.

    "at the time" was in the late 1950s when it was first proposed,
    and through much if not all of the 1960s.

    --- Synchronet 3.20a-Linux NewsLink 1.114