5 ms·

Amazing to think that was an 8mhz 68000. I can't even compute how many times faster a new Mac Pro is today (even if you ignore the GPU). Or even how many times

Amazing to think that was an 8mhz 68000. I can't even compute how many times faster a new Mac Pro is today (even if you ignore the GPU). Or even how many times more powerful my iPhone 5 is than this.

mikeash 13y ago
That 68000 could manage about 1 MIPS. No floating-point unit, so the FLOPS will be painfully low. The low-end Mac Pro has four cores at 3.9GHz each. I believe they'll do in the neighborhood of 3 instructions per clock cycle at peak performance, so that means the total is 3.9 x 4 x 3 x 1000 = 46,800 MIPS. Roughly. So in the neighborhood of 50,000 times faster when looking at the CPUs. The GPUs make it outright ludicrous. The low-end Mac Pro does 2 teraFLOPS on the GPUs. Even if we're charitable to the 68000 and consider its 1 MIPS roughly equivalent to 1 MFLOPS, the Mac Pro is still two million times faster there. And of course the Mac Pro is substantially cheaper when adjusted for inflation. Although it doesn't come with a display, nor any input devices.
- coldcode 13y ago
  Gag that's crazy. Yet it was still usable according to the needs of the day.
  - cschmidt 13y ago
    The 128k Mac was very usable (and a thing of magic and joy to me as a teenager). The only bad part was swapping floppy disks back and forth. That could give you disk swapper's elbow. http://www.folklore.org/StoryView.py?story=Disk_Swappers_Elbow.txt http://www.folklore.org/StoryView.py?story=Disk_Swappers_Elb...
- gaius 13y ago
  And yet my Amiga and my ST display a menu as soon as I click, can keep up with my typing, and scroll documents without lag. My MacBookPro can do none of these things.
  - billforsternz 13y ago
    +1 I can remember coding up tricky algorithms on 1Mhz embedded processors back in the day which would be instantaneously responsive. Today, although we have supercomputers in our pockets that can do decent speech recognition and other extraordinary things, many really simple I/O operations seem to lag. Is it really possible that all that performance can be effectively neutered sometimes simply by too many layers of software ? If not, what else could it be ?
  - agumonkey 13y ago
    Software randomness and complexity made OS 'bloated', tapping into the immense resources. Up until linux 2.4 computer still had a smallness feel, there was not many abstraction layers to cross, short response time[1]. Now even with systemd fast boot, v8 jitted javascript and performant machines you notice a slight delay. [1] of course pushing compositeless full screen cga or even vga doesn't require the same architecture complexity
the_mat 13y ago
Think about the CPU landscape in 1984. You had all these 8-bit home computers running at sub-2MHz. The IBM PC was 16-bits running at 4.77MHz, and most of those were actually using 8-bit buses (the 8088 vs. 8086). The super expensive IBM PC/AT was the top of the line: a 6MHZ 80286. In comparison to all of this, a processor running at 8MHz that could do full 32-bit operations (though, yes, the external bus was half that) and with 16 32-bit registers. and no segments...mind blowing!
- ajross 13y ago
  It's not quite that cut and dry. The 80286 was actually significantly faster than the 68000 at what-at-the-time-was-considered typical code[1]. The 68000 had a much cleaner and forward-looking ISA of course, but it paid a cost for that 32 bit architecture in more elaborate microcode that the 286 didn't need to worry about. [1] That is, things that fit in mostly-16-bit data sets. Once framebuffer manipulation became the dominant operation a few years later, that status would flip. Nonetheless if you were trying to compile your code, model your circuit or calculate your spreadsheet as fast as possible in 1984, you'd probably pick a PC/AT over a Mac (if you couldn't get time on a VAX).
  - to3m 13y ago
    Yes. The 68000 was very nice to program for, but internally it was obviously from an earlier era/too far ahead of its time/a big pile of shit (delete as you see fit). You'll hunt far and wide for an instruction that takes less than 4 cycles, long instructions take more time again, variable-width shifts take 2 cycles per shift, a division can take 150 cycles, and with the effective address calculation timings on top things can really mount up. (See, e.g., http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68000timing.HTML. http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68000timi...) If you look at the cycle counts for 8086 instructions - see, e.g., http://zsmith.co/intel.html http://zsmith.co/intel.html - they're much closer to the 68000 ones. Compared to the 68000, the 286 is just on another level.
  - yuhong 13y ago
    Another cost of the "more elaborate microcode" is that there was no way to resume or restart execution of the current instruction after a bus error exception. The 68010 fixed that by dumping internal state onto the stack. I wished that after 68010 was released that Motorola promoted the 68010 for new development and the original 68000 only for situations where the system software cannot be modified (since to fix the problem the exception stack frames had to be changed). Motorola had some patents describing how it worked: https://www.google.com/patents/US4493035 https://www.google.com/patents/US4493035

Amazing to think that was an 8mhz 68000. I can't even compute how many times faster a new Mac Pro is today (even if you ignore the GPU). Or even how many times more powerful my iPhone 5 is than this.

mikeash 13y ago

That 68000 could manage about 1 MIPS. No floating-point unit, so the FLOPS will be painfully low. The low-end Mac Pro has four cores at 3.9GHz each. I believe they'll do in the neighborhood of 3 instructions per clock cycle at peak performance, so that means the total is 3.9 x 4 x 3 x 1000 = 46,800 MIPS. Roughly. So in the neighborhood of 50,000 times faster when looking at the CPUs. The GPUs make it outright ludicrous. The low-end Mac Pro does 2 teraFLOPS on the GPUs. Even if we're charitable to the 68000 and consider its 1 MIPS roughly equivalent to 1 MFLOPS, the Mac Pro is still two million times faster there. And of course the Mac Pro is substantially cheaper when adjusted for inflation. Although it doesn't come with a display, nor any input devices.

coldcode 13y ago
Gag that's crazy. Yet it was still usable according to the needs of the day.
- cschmidt 13y ago
  The 128k Mac was very usable (and a thing of magic and joy to me as a teenager). The only bad part was swapping floppy disks back and forth. That could give you disk swapper's elbow. http://www.folklore.org/StoryView.py?story=Disk_Swappers_Elbow.txt http://www.folklore.org/StoryView.py?story=Disk_Swappers_Elb...
gaius 13y ago
And yet my Amiga and my ST display a menu as soon as I click, can keep up with my typing, and scroll documents without lag. My MacBookPro can do none of these things.
- billforsternz 13y ago
  +1 I can remember coding up tricky algorithms on 1Mhz embedded processors back in the day which would be instantaneously responsive. Today, although we have supercomputers in our pockets that can do decent speech recognition and other extraordinary things, many really simple I/O operations seem to lag. Is it really possible that all that performance can be effectively neutered sometimes simply by too many layers of software ? If not, what else could it be ?
- agumonkey 13y ago
  Software randomness and complexity made OS 'bloated', tapping into the immense resources. Up until linux 2.4 computer still had a smallness feel, there was not many abstraction layers to cross, short response time[1]. Now even with systemd fast boot, v8 jitted javascript and performant machines you notice a slight delay. [1] of course pushing compositeless full screen cga or even vga doesn't require the same architecture complexity

the_mat 13y ago

Think about the CPU landscape in 1984. You had all these 8-bit home computers running at sub-2MHz. The IBM PC was 16-bits running at 4.77MHz, and most of those were actually using 8-bit buses (the 8088 vs. 8086). The super expensive IBM PC/AT was the top of the line: a 6MHZ 80286. In comparison to all of this, a processor running at 8MHz that could do full 32-bit operations (though, yes, the external bus was half that) and with 16 32-bit registers. and no segments...mind blowing!

ajross 13y ago
It's not quite that cut and dry. The 80286 was actually significantly faster than the 68000 at what-at-the-time-was-considered typical code[1]. The 68000 had a much cleaner and forward-looking ISA of course, but it paid a cost for that 32 bit architecture in more elaborate microcode that the 286 didn't need to worry about. [1] That is, things that fit in mostly-16-bit data sets. Once framebuffer manipulation became the dominant operation a few years later, that status would flip. Nonetheless if you were trying to compile your code, model your circuit or calculate your spreadsheet as fast as possible in 1984, you'd probably pick a PC/AT over a Mac (if you couldn't get time on a VAX).
- to3m 13y ago
  Yes. The 68000 was very nice to program for, but internally it was obviously from an earlier era/too far ahead of its time/a big pile of shit (delete as you see fit). You'll hunt far and wide for an instruction that takes less than 4 cycles, long instructions take more time again, variable-width shifts take 2 cycles per shift, a division can take 150 cycles, and with the effective address calculation timings on top things can really mount up. (See, e.g., http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68000timing.HTML. http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68000timi...) If you look at the cycle counts for 8086 instructions - see, e.g., http://zsmith.co/intel.html http://zsmith.co/intel.html - they're much closer to the 68000 ones. Compared to the 68000, the 286 is just on another level.
- yuhong 13y ago
  Another cost of the "more elaborate microcode" is that there was no way to resume or restart execution of the current instruction after a bus error exception. The 68010 fixed that by dumping internal state onto the stack. I wished that after 68010 was released that Motorola promoted the 68010 for new development and the original 68000 only for situations where the system software cannot be modified (since to fix the problem the exception stack frames had to be changed). Motorola had some patents describing how it worked: https://www.google.com/patents/US4493035 https://www.google.com/patents/US4493035