4 ms·

Was summarizing this article for a group of friends who largely met during the Apple II days and wanted to repost a bit of that here: The optimized code at the

Was summarizing this article for a group of friends who largely met during the Apple II days and wanted to repost a bit of that here: The optimized code at the end takes 94 nanoseconds to sum an array of 1024 32-bit floating point numbers. In 94 nanoseconds, our old friend the 1 MHz 6502, would be just starting to consider signaling the memory chips that maybe they ought to try digging up the first byte of the first instruction in the program. Worth mentioning, that code is entirely dependent on running in cache. Otherwise even the mighty M1 Max in the post would still be stuck waiting on that first memory fetch. DRAM is slow. :-)

cmrdporcupine 2y ago
Lucky our total L1 cache sizes are about as big as the entire addressable memory of the 6502. We truly live in amazing times.
- LoganDark 2y ago
  Truly. And I'm also always amazed by how much slower (in terms of wall time) modern software is than it ought to be. CPUs sure don't feel three to four orders of magnitude faster than they were 50 years ago, because software has gotten four to five orders of magnitude more wasteful to compensate. Argh...
  - jonhohle 2y ago
    I recently moved a project from a Phenom II 945 to an I7 8700. The project took around 1:30 to compile on the Phenom, 15s to compile on the I7. Others working on the project with even more modern systems are compiling in half that time. The major advantage I had was running the same compilers, same interpreters and same tooling, just in better hardware. On the other hand, I always felt KDE 2 and 3 were way more responsive on way less hardware than one of the modern versions or Gnome. Part of it is UI design - giving feedback that an operation is going to take some time immediately instead of blocking until the operation is done before doing anything.
    - LoganDark 2y ago
      Plenty of that software is fairly well optimized, but most software is not that optimized. Microsoft Teams, Discord, Slack, basically anything else that also uses Electron... it's not UI design, it's legitimately wasted work, and tons of it.
      - nikanj 2y ago
        So many programmers saw "Premature optimization is the root of all evil" and thought it means "Caring about performance makes you a heretic". You can't hotspot optimize a Fiat Multipla into an Formula 1 car. When every software you run creates a dozen factories to replace one for-loop, you get the modern desktop experience
        throwaway2037 2y ago
        > So many programmers saw "Premature optimization is the root of all evil" and thought it means "Caring about performance makes you a heretic". This is very well said. Also, with enough experience, many good programmers will "know" where the hotspots will be, while writing the code. So, they can be "sloppy" in areas where it doesn't matter, and "care more about performance" in areas where it will likely matter much more.
      - throwaway2037 2y ago
        > most software is not that optimized I would say: For good reason. The value is too low. > basically anything else that also uses Electron... To me, the point of Electron is a lovely platform with very high developer productivity. This is partly the reason why Java/C# was able to displace so much C&C++ code inside big enterprise corps writing CRUD apps. Sure, Java/C# is a bit bloatly/slow compared to C&C++, but the developer productivity is way higher. > it's not UI design, it's legitimately wasted work, and tons of it. I don't understand this part. Can you explain more? Maybe an example would help.
        LoganDark 2y ago
  - xmprt 2y ago
    Well it depends on what software you're talking about. Browsers are way more capable than they were before. I'd be surprised if old computers would be able to play a 1080p video at 60fps even if somehow your network card had the bandwidth for it. And copying/pasting files is certainly way faster than it used to be. Compiling large applications is much faster now when it would be an overnight process decades ago. Nothing is stopping you from using the old school software but the reality is that old software was missing a lot of the features that we rely on. That's not to say that current software isn't bloated but if you told me I could go back to using the old software I wouldn't (and I could).
- Natsu 2y ago
  Now you're making me wonder if there's a 6502 emulator making use of that fact.
  - deleted 2y ago
    [deleted]
  - cmrdporcupine 2y ago
    Hah, I had the same thought. What kind of hacks can I do to convince the processor to keep as much of the emulator + opcodes in L1 as I can...
    - dhosek 2y ago
      A bit of ignorance on my part, but would the L1 be holding the data and the instructions? In which case we would be trying to fit our entire 6502 emulator in less than 64K of memory alongside the emulated RAM/ROM?
      - cmrdporcupine 2y ago
        The CPU decides what goes in there and when. You can only pray and offer sacrifices and guess at when and how.
      - Someone 2y ago
        https://en.wikipedia.org/wiki/Apple_M1#CPU https://en.wikipedia.org/wiki/Apple_M1#CPU: “The high-performance cores have an unusually large 192 KB of L1 instruction cache and 128 KB of L1 data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB L1 instruction cache, 64 KB L1 data cache, and a shared 4 MB L2 cache.” ⇒ chances are you don’t even have to try to fit an emulator of a 8-bit machine and it memory into the L1 cache.
        filleduchaos 2y ago
        I think you would very much have to try to fit a complete emulator of, say, the Game Boy into 128 + 64KB. There's plenty of behaviour that is self-evident on real silicon but verbose and tricky to express in software.

cmrdporcupine 2y ago

Lucky our total L1 cache sizes are about as big as the entire addressable memory of the 6502. We truly live in amazing times.

LoganDark 2y ago
Truly. And I'm also always amazed by how much slower (in terms of wall time) modern software is than it ought to be. CPUs sure don't feel three to four orders of magnitude faster than they were 50 years ago, because software has gotten four to five orders of magnitude more wasteful to compensate. Argh...
- jonhohle 2y ago
  I recently moved a project from a Phenom II 945 to an I7 8700. The project took around 1:30 to compile on the Phenom, 15s to compile on the I7. Others working on the project with even more modern systems are compiling in half that time. The major advantage I had was running the same compilers, same interpreters and same tooling, just in better hardware. On the other hand, I always felt KDE 2 and 3 were way more responsive on way less hardware than one of the modern versions or Gnome. Part of it is UI design - giving feedback that an operation is going to take some time immediately instead of blocking until the operation is done before doing anything.
  - LoganDark 2y ago
    Plenty of that software is fairly well optimized, but most software is not that optimized. Microsoft Teams, Discord, Slack, basically anything else that also uses Electron... it's not UI design, it's legitimately wasted work, and tons of it.
    - nikanj 2y ago
      So many programmers saw "Premature optimization is the root of all evil" and thought it means "Caring about performance makes you a heretic". You can't hotspot optimize a Fiat Multipla into an Formula 1 car. When every software you run creates a dozen factories to replace one for-loop, you get the modern desktop experience
      - throwaway2037 2y ago
        > So many programmers saw "Premature optimization is the root of all evil" and thought it means "Caring about performance makes you a heretic". This is very well said. Also, with enough experience, many good programmers will "know" where the hotspots will be, while writing the code. So, they can be "sloppy" in areas where it doesn't matter, and "care more about performance" in areas where it will likely matter much more.
    - throwaway2037 2y ago
      > most software is not that optimized I would say: For good reason. The value is too low. > basically anything else that also uses Electron... To me, the point of Electron is a lovely platform with very high developer productivity. This is partly the reason why Java/C# was able to displace so much C&C++ code inside big enterprise corps writing CRUD apps. Sure, Java/C# is a bit bloatly/slow compared to C&C++, but the developer productivity is way higher. > it's not UI design, it's legitimately wasted work, and tons of it. I don't understand this part. Can you explain more? Maybe an example would help.
      - LoganDark 2y ago
- xmprt 2y ago
  Well it depends on what software you're talking about. Browsers are way more capable than they were before. I'd be surprised if old computers would be able to play a 1080p video at 60fps even if somehow your network card had the bandwidth for it. And copying/pasting files is certainly way faster than it used to be. Compiling large applications is much faster now when it would be an overnight process decades ago. Nothing is stopping you from using the old school software but the reality is that old software was missing a lot of the features that we rely on. That's not to say that current software isn't bloated but if you told me I could go back to using the old software I wouldn't (and I could).
Natsu 2y ago
Now you're making me wonder if there's a 6502 emulator making use of that fact.
- deleted 2y ago
  [deleted]
- cmrdporcupine 2y ago
  Hah, I had the same thought. What kind of hacks can I do to convince the processor to keep as much of the emulator + opcodes in L1 as I can...
  - dhosek 2y ago
    A bit of ignorance on my part, but would the L1 be holding the data and the instructions? In which case we would be trying to fit our entire 6502 emulator in less than 64K of memory alongside the emulated RAM/ROM?
    - cmrdporcupine 2y ago
      The CPU decides what goes in there and when. You can only pray and offer sacrifices and guess at when and how.
    - Someone 2y ago
      https://en.wikipedia.org/wiki/Apple_M1#CPU https://en.wikipedia.org/wiki/Apple_M1#CPU: “The high-performance cores have an unusually large 192 KB of L1 instruction cache and 128 KB of L1 data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB L1 instruction cache, 64 KB L1 data cache, and a shared 4 MB L2 cache.” ⇒ chances are you don’t even have to try to fit an emulator of a 8-bit machine and it memory into the L1 cache.
      - filleduchaos 2y ago
        I think you would very much have to try to fit a complete emulator of, say, the Game Boy into 128 + 64KB. There's plenty of behaviour that is self-evident on real silicon but verbose and tricky to express in software.