What would happen if computers never got any faster?

Well there are a couple responses to that.

First of all, just because computers stopped advancing doesn't mean all computers will be the same. You'll still be able to use big, powerful machines as workstations where you write and deploy software for smaller machines. At the same time the N64 came out, there were MUCH more powerful machines you could use.

Secondly, there's really nothing in principle that would stop you from creating the late N64 games on less powerful computers. Certainly it would be more clunky to compile and deploy from an older, less powerful machine, but you could still do it.

> The final products of those amazing programs that show up late in the platform's lifetime are indeed running on the same hardware, but aren't those programs often developed using faster computers of later periods?

They are developed on faster computers but that was already the case at the heyday of these games, so the difference might be less than you would expect.

What is a huge difference though is access to information. Back in the day I got my weekly homeopathic dose of assembly language from a local home computer magazine. That's all there was. Today every ever so obscure detail is just few searches away. I cannot stress enough what difference this makes in learning and development speed.

With a bit more memory (or just storage in general), it would've been possible to do the pre-rendering on a SNES as well, it would just take a while. So having faster hardware isn't necessary, it just makes it easier and more convenient.

Amazing demos are released on the C64 today. High quality productions spanning several disk sides, still pushing the boundaries of the machine and doing things like playing video streamed from floppy, using the SID chip for sample playback with incredible quality, squeezing the last out of every single byte of RAM. It shows how well the authors know the system. Many of them have coded for it for more than 30 years and know every little bit about it by heart.

Still, those demos couldn't have been created on an unexpanded C64 without the help of modern cross-development: running an assembler natively takes up memory that can now be freed for data and code. The same goes for some of the audio and graphics: using a PC to downsample from a higher resolution yields better quality and those resolutions wouldn't fit on a floppy, let alone the unexpanded memory.

Some of it could maybe be done natively with a RAMLink and hard drive, but not all of it.

>Many amazing pieces of code involve pre-rendering or other various forms of precomputation that are extremely computationally expensive but the final result will run on a low-powered machine.

Well, if by "many" you mean "mostly games", yes. Not true for other kinds of software...

What kind of P90 did you find that has 128 MB of RAM? My P100 had 16... It could play (and encode!) mp3s just fine, though.

> mpv and mplayer can't play anything smoothly (not even as a .wav file)

If you mean command line tools, this is a bit surprising (assuming no pulse audio).

>As machines have progressed, the great wins of the past have become nearly unmeasurable noise.

I bet they are measurable when you get the cloud bill...

The interesting thing is that in their day we used those devices to do real work. The main thing that sticks in my mind wasn't the slowness but the lack of stability. Rebooting/reinstalling to fix issues was very common.

I remember that my libretto 30 could play mp3s, but only with the Fraunhofer decoder - winamp took too much CPU.

That your P90 is slow to run modern software is largely because modern software is bloated. You mention:

> mpv and mplayer can't play anything smoothly (not even as a .wav file) and mpg321 fires up pulseaudio before it starts playing so that's not happening.

But a P90 could not only play wav files (in fact my 386 with 4MB of RAM could play and edit wav files in realtime just fine under Windows 3.1) but also both decode and play mp3 files at the background while doing other tasks in Windows 95.

That mpv and mplayer are not able to do that shows that they require way more resources than is really necessary to perform the task at hand.

> People aren't being foolish or irresponsible or naive in not caring about these things, they're being sensible. Running a Pentium 90 with modern software --- that's the actual unreasonable hobby here.

That is a false dichotomy, running modern software on a P90 might not be very reasonable but that doesn't make people who do not care about the resource usage of their applications sensible - if they are or not depends on other matters.

And being unable or hard to run modern software on a P90 is because of the state of current software, but that doesn't mean software has to be like that because it is "modern" - someone explicitly made a choice to develop the software in a way that causes it to be like that.

> * telnet bootstra386.com:1994

> * ssh bootstra386.com:1995

Ha! These port numbers made my day:)

might be an interesting comparison with a netbsd release from the era

Hi.

I recently bought some 386SX 25Mhz laptop to develop some software as well, and I worked on low-end hardware for over decade as well(for fun!)

My findings: You could run NetBSD 1.3.1 on just 2MB of RAM.

You can play mp3 on 486DX 66Mhz with mpg123 and madplay if you change the output to 22khz and few other flags.

Pentium 100 was enough back in the 2001 to run Slackware 7, BeOS and NetBSD 1.6.1 with mp3(in lower quality), Opera web browser, few consoles, text editor - at same time without hassle, AND burning cd-rom at the same time.

Then GOOGLE "invited" Ajax in 2004 and now even computer with 2gb of ram and 1.6Ghz dual cpu, can't open simple page with JS without serious stutter...

alternatively, let's say we will hit some kind of physical/innovation barrier one day, and we no longer have more hardware to throw at things.. suddenly any optimization feels like an upgrade? Almost akin to the recent M1 vs Intel CPU progress...

I agree, why not use the resources we have, but, I guess he meant that even though processing power were to stagnate we could still make progress?

That I can outpace the cursor on a windows desktop in word 365 on a 30 page document and need to stop for a good second for it to catch up with nothing else open on a 8 gb, 4 core, 3GHz machine is so outrageous I don't know how anyone still uses Windows.

Computers have gotten so unoptimized for people that a machine from the 80s has better capabilities for the average office worker than one used today. The only reason why we don't use WordPerfect 3.0 is because Microsoft has managed to force planned obsolescence on software and hardware for 30 years for no reason other than they can.

I can't help to see the analogy with muscle building. Train to gain mass first, then add more repetitions to make those muscles effective.

The author seems to think that not spending time optimizing for slower hardware when the hardware keeps getting faster is somehow not thoughtful or creative.

We're thoughtfully and creatively optimizing for the world that exists now (i.e. one where hardware keeps getting faster). When hardware stops getting any faster, we'll thoughtfully and creatively optimize for that then.

I can't speak to the services side of your comment, but my professional experience is in games.

I worked as part of a team that once backported a game from the Xbox 360 to the PlayStation 2 (512 to 24 megabytes of RAM, much slower CPU, much more limited 'shaders' if you can call VU code 'shaders', etc). The PS2 had 32 megabytes of RAM, but by Sony submission requirements you weren't allowed to touch the bottom 8mb of that. And a lot of the remaining 24mb would be taken up by your program itself, leaving little space in memory for model data, sound, etc. But we did it.

From that perspective, it seems to me like there's really very little in Breath of the Wild that couldn't have been done back on the GameCube, if somebody had really wanted to. You just use lower detail models and textures, and maybe adjust the way you stream the world into memory from disk.

Similarly, Death Stranding could probably have been made on the original PlayStation (if you didn't care about network features; you'd have to wait for the later PS2 models if you wanted those). And similar for Kingdom Hearts 3.

Sure you would have had lower numbers of triangles and less fancy shaders and lower-resolution textures. But the games themselves? The stories and logic and mechanics and experiences? I feel like they'd all be pretty doable on lower-spec hardware, if an experienced team had a mind to try.

I guess my point is just that if computers stopped getting faster, you'd still have newer and better and more intricate games being released. Faster computers are absolutely not required for that. They're really only required if you want ray tracing and higher polygon counts and physically based lighting and similar.

> You would have games, you would have services, but you wouldn't have these games and these services without both massive computational power and massive creativity.

And market competition engendering innovation

You can buy 32 core 3.5 GHz CPU :)

You pretty much summed up the major misconception of how CPUs work (and get faster) these days. It's not about cores or clocking speed.

Yeah, the guy is living in some alternate reality. E.g., here on planet Earth low- and mid-range consumer laptops have been getting slower, not faster over the years. (Yeah, they're lighter and more power-efficient, but that's orthogonal.)

Same deal with servers: AWS and Azure are dog-slow compared to the on-premises server hardware we'd have before "the cloud".

(All benchmarks mentioned are from Geekbench, I don't know how methodologically sound they are).

I don't know which CPU you're actually using, but taking the i7 990x (3.5GHz, 6 cores etc. - $1k back in '11) as a reference, single threaded performance at the cutting edge has increased by roughly a factor of 2 to 3 - 7GHz enough for you?

The AMD 5950X is currently the meanest desktop chip on the market, across multithreaded workloads it's something like a factor of 6.5 faster than the i7. Sure it's got 12 more cores, but it does all that for less power at boost than the i7's nominal TDP.

Include modern memory and storage into the equation, and we've come quite a long way, and it's only going to get better now that Intel are desperate, AMD are finally back, and Apple have demonstrated ARM is good enough to displace x86.

Are you suggesting that processor speed is solely a function of clock speed?

Given the improvements in IPC over ten years it is not that far off. If your workload can spread over more cores then that level was exceeded long ago.

Modern processors have not just increased in core count, but also in how efficient their pipelining, parallelizing, and instruction reordering is. We used to measure CPUs by cycles/instruction, but modern CPUs have inverted that relationship and now we can execute several instructions per cycle, so each cycle is actually doing more even if we can't squeeze more cycles in per second.

> I dare say performance might even become government regulated, like efficiency is for home appliances

Sounds like a nightmare. But since programming has so far restricted attempts at credentialism-gatekeeping and even unionising, I'm not holding my breath.

> IMO you can already see this happening to Ruby, and Rust. Increasing attention to making low level languages more palatable.

Or viewed in reverse, attempts to make higher level languages faster.

One way to do that is to make sure that the levels of abstraction that exists in the language don't leave much of a trace at runtime. Ie compile the abstractions away.

That's more straightforward with more statically typed languages. But the excellent work done on JavaScript engines shows that given enough resources to throw at the problem, being 'slow' or 'fast' is not a property of languages but of implementations. (But the language definitely has an influence on how much implementation effort you need.)

> I think the biggest factor will be "slow" programming languages going extinct.

then make this language faster, problem solved :)

Are we going to get back to Forth?!

Things aren't increasing as fast as they were in the 90s but I'd be willing to bet at least the last 5 years of single thread stagnation was largely a fluke due to lack of competition in high end CPUs coupled with various setbacks in Intel's next generation processes preventing the (at the time) best from gaining advantage from significant manufacturing advances. I think releases like Zen 3 and Apple's M1 give a good sign the next doubling period for single thread performance may be the first that was significantly shorter than the previous.

> Really, I would be quite fine with, say, most websites operating on a technology level of around 1995.

I would pay for that if it was a feature.

The good news is, a lot of old software is still running fine on today's computers and lightning fast compared to modern behemoths. Too bad it's often not very compatible with other people's and organisation's workflows. And the attitudes are sometimes a bit strange because people vastly underestimate the capabilities of certain programs, especially if they run in the terminal. Yes, Vim looks weird at first. But it also doesn't need to spin up a web browser first and starts instantly on pretty much every hardware that you didn't dig out of a museum.

Although to be fair I once tinkered a bit with Electron and was surprised at how lightning fast it can be if it's not overburdened. Your comparison with gas is great - it seems optimisation is always done just enough that acceptance from the target audience doesn't suffer too much, and the rest of the performance gain is sunk somewhere in the vast network of dependencies that nobody cared to clean up.

I can have a web browser with hundreds of non trivial tabs and yet it "only" needs 2GB of RAM. Firefox used to be lean and only need 1GB but then everyone insisted on multi process browsing and it doubled the memory usage.

I think the issue is that rather than making C++ better we have defaulted to relying on the hardware more.

C++ is a deeply, deeply, flawed language - using something else isn't hard (and it doesn't have to be Rust). You'd be surprised at the amount of stuff you can get for free if you make it easy to express.

My D scripts are usually shorter than my Python one's (and I write code I want to save not just "it'll do"-type scripts, to my detriment), but because we don't teach people anything other than C++/Java/Python (Haskell is very nice but it's too far away to be helpful to this area of software) we falsely imprint a view that performance always cost's expressiveness or development time.

The good news is that this trend does seem to be getting better, and it's only going to get easier thanks to widespread use of infrastructure like LLVM and the social acceptance in industry of wacky languages.

The biggest issue with this sort of thinking is that developers tend to create applications that either assume they're the only applications running in the system - or they use machines so powerful that when you try their applications on a lower end machine (PCs with just 4GB of RAM and weak CPUs are still being sold for example) they might as well assumed they'd be the only applications running in the system.

I mean, this is still done (not to as absurdly a degree as in the past) with consoles, which for the most part have a few permutations per generation at most.

The big thing that would cause a trend away from this would be the demand to target cross-platform. I wouldn't call Windows software particularly optimized, and it wouldn't make sense to do these optimizations for Windows, because there are countless permutations of hardware that can run Windows 10 off the shelf, so optimizing for all of those would be a Sisyphean task. Combine that with the fact that even console games these days are generally targeting cross-platform on multiple consoles and PC, and this type of optimization is largely out of the realm of the possible.

The performance increases from using C these days really come from it forcing you to avoid abstraction rather than access to the hardware. If you imagine the amount of indirection a Python program has just to add two numbers, that's why C is "fast". Compilers are clever, but they generally don't bother and aren't really allowed to look too far away from a given expression or function i.e. Extracting very high level information about even integers still requires manual annotation - GCC and LLVM will happily propagate parity through an expression but declaring an invariant about an integer inside a struct is not possible even with extensions AFAICS

The issue we have, now, however isn't that your code (or any code, ideally) is slow but that the depth of the tree from your library call down to the missile launching is too deep. There's just too much crap in between the important stuff.

Even if you could there are endless permutations of CPU, GPU, and whatnot that you couldn't possibly optimize for all of them. Coupled with the fact that an obvious way to boost profits of a game is to design it to be easily portable across some combination of PC and various consoles, and why would you hyper-optimize a game for hardware?

We're in a vastly different world than BBC Micro or the Sega Genesis, where a game targeting multiple platforms is now pretty normal, and if it's not it's usually for business reasons rather than hardware incompatibility. And ports in those days were often from-the-ground rewrites, which I would probably hazard is not true today of most of them.

> 5G computers with Xtreme Speed®

Don't forget the 1nm process still using today's optics.

There is a new wave of games coming which use advanced physics, think destructible voxel worlds, like minecraft but having blocks of 1cm instead of 1m. VR benefits immensely from CPU/GPU overkill and can use any cycle it can get. The status quo you see now is caused by CPU stagnation not the other way around. Once tech finds a way to afford more cycles games and applications will find ways to use them (and not just by wrapping them with Electron :).

About your old PC, first try to run a memcheck to ensure the RAM is fine.

Then just take it apart and clean everything, add new thermal paste, etc. I did that for my mid-2000s Athlon64 X2 (took apart everything, including removing the GPU heatsinks, etc to clean them) and it works like charm. Now i also need to find a GTX280 or equivalent GPU to fix the PC i bought after the Athlon64 X2 :-P.

PC gaming is the spearhead of planned obsolescence. Everything else comes after the gaming market has paid the hefty markup.

Check your power supply. I just replaced a power supply on a pc I built in 2012. The system was unstable and shutting down after five minutes of being on

Stuffing more chips onto game cartridges was a thing that happened with the SNES quite a bit, but really only happened with Virtua Racing on the Genesis/Mega Drive. If you look at early titles for a particular platform vs the later ones, the later ones almost always look/perform better because the developers learned how to milk more resources out of the platform. An example from the Playstation 1 era is Naughty Dog Studios, as seen here in this old HN thread: https://news.ycombinator.com/item?id=9737156

Not very much. The SNES was the king of stuffing coprocessor chips onto cartridges; the hardware was a minor 6502 upgrade paired with amazing sound from Sony, and some pretty good video hardware. Sega did almost the opposite: they took the 68000, a pretty good CPU for the time, and paired it with OK sound and a tweak to the TI VDP they were using in the Master System. The average SNES game just needed the extra oomph that a coprocessor could give, while the average Genesis game probably was fine with the 68K.

That's not to say coprocessors didn't exist. Sega loved expanding the Genesis - but with hardware-addons that didn't sell very well. The Sega CD is effectively a second console's worth of coprocessors. It included much-improved audio hardware (which barely got used because you had CDDA), another 68000 CPU, and some fancy rotozoom ASIC stuff. There is a SNES style "just sneak a chip onto the cartridge" thing, though, but there's only one game that does that: Virtua Racing. It has a very primitive hardware rasterizer on board, which actually causes problems with some later-model Genesis consoles. It also won't work at all if you have a 32X plugged in.

The other replies describe the lack of coprocessors, but there is one way in which Mega Drive cartridges got more sophisticated over time - increased ROM capacity.

At launch, most games were around 512KB in size. By the end of the machine's lifespan 3MB was common and there were even some 4MB and 5MB games.

Since I just came across this[1].

"The moment the robots realize that the three laws of robotics are just socially constructed norms"

[1] https://twitter.com/Thinkwert/status/1325980944654856193

That is largely a C issue, Delphi 2 for example can compile a simple text editor application in about a second on a Pentium at ~166Mhz :-P.

Though for modern hardware there is Tiny C Compiler [0] which actually can be used as a "C scripting language" - AFAIK you can even embed it in applications for such use. Also TCCBOOT [1] was made in 2004 with TCC that compiles and boots Linux on a Pentium 4 in 15 seconds, so there is that.

[0] https://bellard.org/tcc/

[1] https://bellard.org/tcc/tccboot.html

This is a use-case for D, with a compiler flag to compile-and-run.

Assembly would probably increasingly only be useful to eliminate overhead rather than efficiency, because the CPUs would probably get even harder for a regular human to understand (i.e. the Compiler is probably already better at instruction scheduler than almost all of us, including me)

AMD's CPUs and Apple's SoCs keep getting faster.

Or a similar question: what if TSMC magically disappeared.

And a big point of computer is to take the need for creativity out of routine tasks.

In that apocryphal story where young Carl Friedrich Gauss's class was asked by a lazy teacher to add up all the natural numbers up to 100, Gauss came up with an ingenious and creative solution. But these days, we don't need to waste the creativity of our best and brightest like that.

Perhaps this will usher in more competition which will benefit consumers and developers with even more powerful hardware! Apple has certainly raised the bar significantly with their M1 chip.