5 ms·

This is very similar to another article posted recently[0]. I both agree and disagree with what the author is saying. Like, they claim: “The processors in our

This is very similar to another article posted recently[0]. I both agree and disagree with what the author is saying. Like, they claim: “The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.” I wrote this in the linked thread: “It really does seem to be dependent on the type of work you’re doing. In 2000, I started writing plugins for Final Cut Pro. You could write “real time” plugins for it! That meant you were working in YCbCr 4:2:2 at 320x240 and 30 frames per second (so quarter-sized frame, with 2/3rds the data that an RGB frame would carry and half as often). 22 years later, I’m still writing such plugins, but on the top-end systems you get multiple streams of 8K uncompressed RGB video at 60fps and you can play back in real time.” And I forgot to mention that that video is also processed in floating point (usually 16-bit half float). According to my calculations, that’s about 862x more data being processed in the 8k case. But some of the other points I think are way off. They talk about piping data from one command to another. That’s not how typical users work, and I don’t think it’s how they want to work. I don’t want to pipe data from /dev/MIDI into one command that stores it, and pipe /dev/microphone into another command, and use a third command to mash them together and compress the result so I can listen to it on my phone. I want to use a DAW that records tracks (which are not textual data and would be very inefficient to represent as such) and sometimes I want to render the result to an audio file I can put on my phone. [0] https://news.ycombinator.com/item?id=31798580 https://news.ycombinator.com/item?id=31798580

saghm 4y ago
> “The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.. If I had a choice to swap from the current paradigm of running the programs we have now at the speed we have now or running things 1000x faster but only being able to run programs that were programmed 30 years ago, I don't think I'd take that swap.
- drpixie 4y ago
  > but only being able to run programs that were programmed 30 years ago Take the swap. I don't think you'll loose much. Most programs are doing pretty much the same thing as 30 years ago, but with hi-res graphics
  - eternityforest 4y ago
    30 years ago was Windows 3.1. People still listened to music on CDs commonly until the smartphone era. Using a computer was kind of scary even 10 years ago. They were way buggier and had more exploits. Clicking the wrong link in the WinXP era was not advisable. Programs do the same thing, but they do it more reliably. At least in the GUI world. I don't know what's changed as far as the command line experience.
- actionfromafar 4y ago
  You know what? I think I might. https://en.wikipedia.org/wiki/Amiga_productivity_software https://en.wikipedia.org/wiki/Amiga_productivity_software https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(programming_language)
  - soneil 4y ago
    That was my first thought too, but .. I honestly don't think I'd take that bet. I still have an A1200, and I struggle to think of anything that'd be genuinely improved by having, eg 7GHz instead of 7MHz (to take the article's 1000x figure) processor. 1000x the serial speed would be useful once or twice a year. 1000x the disk access speeds would be a marginal quality of life improvement (I mean I wouldn't say no, but I wouldn't give my modern machine up for it). But making the whole system 1000x faster would realistically achieve what? A hilarious SysInfo screenshot and little else.
    - actionfromafar 4y ago
      Half the argument is not what you would do with it. The hook is that literally everything you could do back then would be instant. I would very much like that. Given that Oberon existed, any green-field development I would have to do in that environment, would be completely feasible and comparable to any advanced environment today. The only thing I would maybe miss is a modern IDE, but on the other hand I was a late-comer to that and used (and still use) Emacs for a long time.
  - cosmojg 4y ago
    Better yet: https://plan9.io/wiki/plan9/plan_9_wiki/ https://plan9.io/wiki/plan9/plan_9_wiki/ http://9front.org/releases/ http://9front.org/releases/
- AnIdiotOnTheNet 4y ago
  Most applications we use really aren't doing very much more useful than their equivalents did thirty years ago, but they are several orders of magnitude slower anyway.
  - thewebcount 4y ago
    I don’t agree with this at all. It used to be that, for example, if you wanted to spell-check your word processing document, you had to select “Check Spelling” from a menu, and it would analyze the document and give you the results. Now it happens as I’m typing. There are numerous things like this that we rely on but have forgotten didn’t happen even a short time ago. File search is another. The metadata and contents of files is constantly being indexed so that when you search for something, you get results within seconds if not faster. I remember waiting for Windows search to find a file on a “large” hard drive. It was excruciating sometimes.
    - AnIdiotOnTheNet 4y ago
      None of which can explain why launching an Explorer window takes a perceptible amount of time, or this: https://youtu.be/GC-0tCy4P1U?t=1767 https://youtu.be/GC-0tCy4P1U?t=1767 , or any of thousands of similar atrocities of wasting everyone's computing resources and time to accomplish nothing of note.
      - eternityforest 4y ago
        Because people spouted crap about premature optimization any time someone wanted to do anything like lazy load an uncommonly used feature?
- deltarholamda 4y ago
  In general, I'd agree. But one of the most productive word processing programs I ever used was WordPerfect 5.1 for DOS. (Not only because while using it you couldn't do anything else that distracted you.) Okay, you couldn't do page layout for the company newsletter in it very well, but based on the .docx files I've gotten over the years, people can't do that now either.
314 4y ago
> That’s not how typical users work, and I don’t think it’s how they want to work. This hits the nail on the head: most users are not programmers. While the unix philosophy works well for programmers it is not suitable for non-programming users. A small collection of single-use tools that can be orchestrated is a programming interface.
- kaba0 4y ago
  One might argue that the unix philosophy doesn’t work well for programmers either. Do I really have to parse one command’s output to do anything meaningful with it?
- indymike 4y ago
  These small commands, piped together make it possible to build, boot and run systems that are in everyone’s pocket and run software that does work the way users want.
deleted 4y ago
[deleted]
drpixie 4y ago
> That’s not how typical users work, and I don’t think it’s how they want to work. That's true. But if people were routinely offered convenient ways to automate, build pipes, or whatever the technique, then perhaps normal people would learn and use it.
- nonrandomstring 4y ago
  I think "piping" was meant as a general metaphor for interoperability. We often hear regular folks say "why doesn't X just work with Y" EDIT: sorry I misposted this reply
- actionfromafar 4y ago
  Amiga had "AREXX ports" which meant you could script desktop software together in ways not possible even today, on any OS. It's not enough that there must exist technically, a possibility. The app vendors much themselves go to the trouble of adding such "scriptability" into their apps. Instead everything is very slick, but very siloed and nowadays tied to a cloud offering, which is great, but it's more often than not locked to that vendor.
TheOtherHobbes 4y ago
It's most obvious with video, but that's not the only change. Thirty years ago you couldn't: * Run games that approach photorealism at 4K resolution * Emulate a recording studio with virtual instruments/FX in your laptop * Watch video streamed at 4K * Stream video from home and add live video FX * Record and edit video at 4K using a pocket device * Download files from a global communication network at hundreds of Mb/s * Search that network and get results almost instantly * Take usable speech recognition and automatic translation more or less for granted The OP is poorly argued. Presumably they're trying to ask why software isn't 1000X better. In some ways it is. Phone apps particularly are much more usable and intuitive than desktop apps from 1992. In other ways, especially on the web, there's a lot of cruft floating on top of a sea of bloat. But there's a conscious tradeoff between abstraction/development time and runtime performance. The web would not suddenly become more usable if everything was written in machine code. Elsewhere there's a lot of drag because of backward compatibility. Office is still a thing because nothing better has replaced it. It's ugly and stupid but it fills a niche that needs to be filled and - for all their efforts - FOSS isn't a realistic alternative for mainstream, professional use. This also applies to a lot of other industry-standard apps like Photoshop. The limiting factor isn't CPU, it's the user. Most of these apps spend vast aeons of time in an idle loop waiting for the human to do something. You'd need to invent new kinds of assistive apps to get around this, and we're beginning to see those with AI. But they'll be disruptors, not replacements, and it's not obvious how that's going to work out.
- MontyCarloHall 4y ago
  In addition, the engineering skill required for writing basic desktop software is much lower than it used to be, while the skill required to write code for a game engine, audio/video processing, low-level network stacks, or any of the other problems on your list is just as high as it used to be, if not higher. Back in the day, anyone writing even a simple desktop app needed to know about algorithmic complexity and low-level optimizations, or their code would be intolerably slow (if it even ran at all). Today, if all you’re developing is a simple productivity app, high-level abstractions have eliminated the need for such low-level knowledge, dramatically lowering the barrier of entry for developers, at the expense of software efficiency. In other words, if the problem you’re solving is inherently easy, it is easy to write (inefficient but fast enough) code to solve it. This used to not be the case: even easy problems required difficult code to solve. However, all of the problems on your list are inherently difficult and complex, and thus still require difficult and complex code to solve. The barrier of entry for developers remains high, ensuring that those who work on said problems still have thorough knowledge of how to write performant code.
moffkalast 4y ago
> The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster. I think the simple answer is that processing is only a small part of running anything, data fetching is what you're typically waiting for. Sure cache and RAM speeds have increased, but HDDs are still about as horribly slow as they always were. Only the jump to SSDs made a considerable difference in "general" speed recently. But on the other hand I suppose we can in fact run the original Doom (released almost exactly 30 years ago) at about a quadrillion FPS these days so maybe I'm wrong.
- pegasus 4y ago
  The question could be steel-manned when restated as: why does today's average app, in order to complete an ordinary task - like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's? Replace "1000" with whatever that multiplier, result of the proliferation of intermediary abstraction layers, actually is. I wouldn't be surprised if it is even more than one thousand, at least extrapolating from this article, which was also posted on this site today: https://danluu.com/input-lag/ https://danluu.com/input-lag/
  - moffkalast 4y ago
    Well aside from the usual Wirth's law answer, the key is high abstraction on all levels, which brings bloat with it. Eventually that bloat will get optimized, as that chart interestingly shows iphone responsiveness being somewhat corelated with increasing years. Same with Windows, where there was a sizable abstraction jump with Vista, which then got slowly optimized over 7, 8 and 10. There's even abstraction in memory management now, with 64 bit virtual address mapping. I've recently stumbled upon these ARM benchmarks https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md https://github.com/ThomasKaiser/sbc-bench/blob/master/Result... and was surprised that the Pi 4 runs 10-50% slower in 64 bit mode compared to 32 bit. I'd expect there was also a notable speed decrease when going from 8 to 16 and 32 bit systems, since there's twice as much address data to fetch and process.
  - 4y ago

saghm 4y ago

> “The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.. If I had a choice to swap from the current paradigm of running the programs we have now at the speed we have now or running things 1000x faster but only being able to run programs that were programmed 30 years ago, I don't think I'd take that swap.

drpixie 4y ago
> but only being able to run programs that were programmed 30 years ago Take the swap. I don't think you'll loose much. Most programs are doing pretty much the same thing as 30 years ago, but with hi-res graphics
- eternityforest 4y ago
  30 years ago was Windows 3.1. People still listened to music on CDs commonly until the smartphone era. Using a computer was kind of scary even 10 years ago. They were way buggier and had more exploits. Clicking the wrong link in the WinXP era was not advisable. Programs do the same thing, but they do it more reliably. At least in the GUI world. I don't know what's changed as far as the command line experience.
actionfromafar 4y ago
You know what? I think I might. https://en.wikipedia.org/wiki/Amiga_productivity_software https://en.wikipedia.org/wiki/Amiga_productivity_software https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(programming_language)
- soneil 4y ago
  That was my first thought too, but .. I honestly don't think I'd take that bet. I still have an A1200, and I struggle to think of anything that'd be genuinely improved by having, eg 7GHz instead of 7MHz (to take the article's 1000x figure) processor. 1000x the serial speed would be useful once or twice a year. 1000x the disk access speeds would be a marginal quality of life improvement (I mean I wouldn't say no, but I wouldn't give my modern machine up for it). But making the whole system 1000x faster would realistically achieve what? A hilarious SysInfo screenshot and little else.
  - actionfromafar 4y ago
    Half the argument is not what you would do with it. The hook is that literally everything you could do back then would be instant. I would very much like that. Given that Oberon existed, any green-field development I would have to do in that environment, would be completely feasible and comparable to any advanced environment today. The only thing I would maybe miss is a modern IDE, but on the other hand I was a late-comer to that and used (and still use) Emacs for a long time.
- cosmojg 4y ago
  Better yet: https://plan9.io/wiki/plan9/plan_9_wiki/ https://plan9.io/wiki/plan9/plan_9_wiki/ http://9front.org/releases/ http://9front.org/releases/
AnIdiotOnTheNet 4y ago
Most applications we use really aren't doing very much more useful than their equivalents did thirty years ago, but they are several orders of magnitude slower anyway.
- thewebcount 4y ago
  I don’t agree with this at all. It used to be that, for example, if you wanted to spell-check your word processing document, you had to select “Check Spelling” from a menu, and it would analyze the document and give you the results. Now it happens as I’m typing. There are numerous things like this that we rely on but have forgotten didn’t happen even a short time ago. File search is another. The metadata and contents of files is constantly being indexed so that when you search for something, you get results within seconds if not faster. I remember waiting for Windows search to find a file on a “large” hard drive. It was excruciating sometimes.
  - AnIdiotOnTheNet 4y ago
    None of which can explain why launching an Explorer window takes a perceptible amount of time, or this: https://youtu.be/GC-0tCy4P1U?t=1767 https://youtu.be/GC-0tCy4P1U?t=1767 , or any of thousands of similar atrocities of wasting everyone's computing resources and time to accomplish nothing of note.
    - eternityforest 4y ago
      Because people spouted crap about premature optimization any time someone wanted to do anything like lazy load an uncommonly used feature?
deltarholamda 4y ago
In general, I'd agree. But one of the most productive word processing programs I ever used was WordPerfect 5.1 for DOS. (Not only because while using it you couldn't do anything else that distracted you.) Okay, you couldn't do page layout for the company newsletter in it very well, but based on the .docx files I've gotten over the years, people can't do that now either.

314 4y ago

> That’s not how typical users work, and I don’t think it’s how they want to work. This hits the nail on the head: most users are not programmers. While the unix philosophy works well for programmers it is not suitable for non-programming users. A small collection of single-use tools that can be orchestrated is a programming interface.

kaba0 4y ago
One might argue that the unix philosophy doesn’t work well for programmers either. Do I really have to parse one command’s output to do anything meaningful with it?
indymike 4y ago
These small commands, piped together make it possible to build, boot and run systems that are in everyone’s pocket and run software that does work the way users want.

deleted 4y ago

[deleted]

drpixie 4y ago

> That’s not how typical users work, and I don’t think it’s how they want to work. That's true. But if people were routinely offered convenient ways to automate, build pipes, or whatever the technique, then perhaps normal people would learn and use it.

nonrandomstring 4y ago
I think "piping" was meant as a general metaphor for interoperability. We often hear regular folks say "why doesn't X just work with Y" EDIT: sorry I misposted this reply
actionfromafar 4y ago
Amiga had "AREXX ports" which meant you could script desktop software together in ways not possible even today, on any OS. It's not enough that there must exist technically, a possibility. The app vendors much themselves go to the trouble of adding such "scriptability" into their apps. Instead everything is very slick, but very siloed and nowadays tied to a cloud offering, which is great, but it's more often than not locked to that vendor.

TheOtherHobbes 4y ago

It's most obvious with video, but that's not the only change. Thirty years ago you couldn't: * Run games that approach photorealism at 4K resolution * Emulate a recording studio with virtual instruments/FX in your laptop * Watch video streamed at 4K * Stream video from home and add live video FX * Record and edit video at 4K using a pocket device * Download files from a global communication network at hundreds of Mb/s * Search that network and get results almost instantly * Take usable speech recognition and automatic translation more or less for granted The OP is poorly argued. Presumably they're trying to ask why software isn't 1000X better. In some ways it is. Phone apps particularly are much more usable and intuitive than desktop apps from 1992. In other ways, especially on the web, there's a lot of cruft floating on top of a sea of bloat. But there's a conscious tradeoff between abstraction/development time and runtime performance. The web would not suddenly become more usable if everything was written in machine code. Elsewhere there's a lot of drag because of backward compatibility. Office is still a thing because nothing better has replaced it. It's ugly and stupid but it fills a niche that needs to be filled and - for all their efforts - FOSS isn't a realistic alternative for mainstream, professional use. This also applies to a lot of other industry-standard apps like Photoshop. The limiting factor isn't CPU, it's the user. Most of these apps spend vast aeons of time in an idle loop waiting for the human to do something. You'd need to invent new kinds of assistive apps to get around this, and we're beginning to see those with AI. But they'll be disruptors, not replacements, and it's not obvious how that's going to work out.

MontyCarloHall 4y ago
In addition, the engineering skill required for writing basic desktop software is much lower than it used to be, while the skill required to write code for a game engine, audio/video processing, low-level network stacks, or any of the other problems on your list is just as high as it used to be, if not higher. Back in the day, anyone writing even a simple desktop app needed to know about algorithmic complexity and low-level optimizations, or their code would be intolerably slow (if it even ran at all). Today, if all you’re developing is a simple productivity app, high-level abstractions have eliminated the need for such low-level knowledge, dramatically lowering the barrier of entry for developers, at the expense of software efficiency. In other words, if the problem you’re solving is inherently easy, it is easy to write (inefficient but fast enough) code to solve it. This used to not be the case: even easy problems required difficult code to solve. However, all of the problems on your list are inherently difficult and complex, and thus still require difficult and complex code to solve. The barrier of entry for developers remains high, ensuring that those who work on said problems still have thorough knowledge of how to write performant code.

moffkalast 4y ago

> The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster. I think the simple answer is that processing is only a small part of running anything, data fetching is what you're typically waiting for. Sure cache and RAM speeds have increased, but HDDs are still about as horribly slow as they always were. Only the jump to SSDs made a considerable difference in "general" speed recently. But on the other hand I suppose we can in fact run the original Doom (released almost exactly 30 years ago) at about a quadrillion FPS these days so maybe I'm wrong.

pegasus 4y ago
The question could be steel-manned when restated as: why does today's average app, in order to complete an ordinary task - like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's? Replace "1000" with whatever that multiplier, result of the proliferation of intermediary abstraction layers, actually is. I wouldn't be surprised if it is even more than one thousand, at least extrapolating from this article, which was also posted on this site today: https://danluu.com/input-lag/ https://danluu.com/input-lag/
- moffkalast 4y ago
  Well aside from the usual Wirth's law answer, the key is high abstraction on all levels, which brings bloat with it. Eventually that bloat will get optimized, as that chart interestingly shows iphone responsiveness being somewhat corelated with increasing years. Same with Windows, where there was a sizable abstraction jump with Vista, which then got slowly optimized over 7, 8 and 10. There's even abstraction in memory management now, with 64 bit virtual address mapping. I've recently stumbled upon these ARM benchmarks https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md https://github.com/ThomasKaiser/sbc-bench/blob/master/Result... and was surprised that the Pi 4 runs 10-50% slower in 64 bit mode compared to 32 bit. I'd expect there was also a notable speed decrease when going from 8 to 16 and 32 bit systems, since there's twice as much address data to fetch and process.
- 4y ago