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.
it's far from settled that the 68k in the Genesis was more powerful than the 65816 in the SNES. Most instructions on the 68816 use 1/3 of the cycles per instruction compared to the 68k. Sega had their marketing of "blast processing" because Sonic was a "fast game" we all know what was pure marketing. Similarly fast games, meaning games that displayed the same features as Sonic, came out on SNES, Uniracers would be one such example.
I think it would be pretty hard to find a Genesis game that would unequivocally demonstrate the 68k in the Genesis was a win over the 65816 in the SNES.
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.
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.
Given that Featurecreep/Software complexity continues to increase, there would be a shift in mindset to leverage more Performant languages/tools instead of only focussing on highlevel productivity for developers. Read: use Rust instead of Ruby. Or augment, like native libs in python
That's orthogonal. You could always scale performance by throwing money at it in the past; the issue here is the promise of "free" performance improvements just by virtue of the natural upgrade cycle.
I believe the point of the poster you replied to was that if you have software running at speed X it won't get particularly faster if you run the same software on a 32-core CPU. Not if the original system also ran at 3.5GHz. I.e. it doesn't get magically faster by throwing more cores at it. It could get faster by better or faster caches etc, and that's valid, but the additional cores don't magically help.
If you mean that compiling gets faster.. then yes, with 'make -j' it will. But that you're compiling C++ has nothing to do with it, except that (as with most other modern languages) you have individual components which can be compiled in parallel. But this is hardly what the grandparent meant by automatically getting a speed boost just by executing existing software on a newer system.
When people talk of "Moore's law", they really imply that there's a huge class of problems that get solved automatically just because transistors get smaller and smaller.
This hasn't been true for a long while now. Yes, technology get better with time, but we don't get things like 32 cores in a PC just because transistors shrunk; smart people worked really hard to optimize this stuff.
TL;DR - there's no more free lunch in computing anymore.
Lets be even more abstract. What matters is useful work per second.
That metric is a function of clock speed, core count, lithography process, but also how many cycles each instruction takes to execute (e.g. how many cycles for an add), the instruction level parallelism in each core, branch prediction, memory architecture and caching, instruction set architecture (ISA) and its implementation, available cooling and more.
For example, by optimizing the number of cycles per instruction, increasing instruction level parallelism and branch prediction you can get a significant boost in performance, as witnessed by the massive jump[1] from the 486DX2 66Mhz to the Pentium 60 (also at 66Mhz in the video below).
The simplest thing you can do to make a processor faster is to have faster memory. Usually this means bigger caches or wider memory buses.
You can decode more instructions at the same time. In theory there is no limit to how many instructions you can decode at once.
Those decoded instructions end up in a buffer and execution units can process them if there are no data dependencies. You can add as many execution units as you like if there is enough work for them.
You can avoid performance destroying events like pipeline stalls by predicting the execution flow of instructions. Better branch prediction means less performance is lost.
None of these have anything to do with clock 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".
I think that this is wrong perspective. The computers that you and I are using right now on our desks does not get slower. A CPU running 3.6GHz will still be running at 3.6GHz in a few years time. The moving target is software.
3.6GHz from 10 years ago and 3.6GHz from today aren't the same though. Modern processors have way more specialized hardware for common tasks that weren't common a decade ago.
Yes, the compute cores are going at the same speed. But you aren't getting the significant advantage of other hardware optimizations.
Just look at the M1 benchmarks for goodness sake. (A bit unfair because it's RISC-V based, but even x86 hardware has improved enormously in the last decade.)
>even x86 hardware has improved enormously in the last decade.
No, it really hasn't! My ancient x220 is still as fast as, or faster than almost all pre 2020 laptops. By contrast, hardware in the period of time ~9 years before 2011 when I bought it is absurdly slower to the point of unusability. Same story with my threadripper versus my 2009 era desktop. For single threaded stuff, not IO bound, they're subjectively about the same. If I need a lot of threads, big memory or big IO, the recent machine is comically faster (like 100-1000x), but lots of things are single thread bound. Again if I take the leap back in time separating the threadripper from my 2009 era machine; there were huge improvements in performance; imagine trying to compile something on a 1998 era tower like OP did.
>Yeah, the guy is living in some alternate reality.
How so?
(I'm talking from desktop perspective)
I'm following tech news and it feels like there's always news about AMD releasing new stuff or Intel trying to catch up
I bought my 8 cores CPU for +-125$ of _my_currency_ year ago which was unbelievable like 3? years ago. Meanwhile I'm still far behind of what's on the edge.
Also nowadays I can spend like 60$ of _my_currency to get insanely fast NVMe M2 disks, so things are cheap nowadays I guess.
Maybe if you stick with Intel. My AMD "budget" laptop (Ryzen 4500U, 6 cores) blows away a much more expensive Intel laptop I bought only 2 years ago. It was less than half the price.
(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.
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.
> Once you understand a system – deeply understand – it can do things that its designers never thought possible.
I often wonder to what degree that is possible in modern computers. Their complexity so hugely beyond that of old 8-bit micros that I doubt a single person could completely understand it. I mean to the level it’s possible to understand a BBC micro - what every CPU cycle does, what function every gate in the video output performs, etc.
A lot of the improvements listed are due to understanding very minute details of the operation, like timing CPU exactly with the video output, changing palettes and sprites on the fly, racing the CRT beam, etc. With a reasonably modern CPU you can’t even reliably tell in advance how many cycles a simple instruction will take.
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.
There are three approaches Moore's law (doubling of transistors per die leading to improvements), More Moore [1] and More than Moore[2]. The latter two deal with the "what if Moore's law does not work anymore problem". Which is close to what the author talks about.
> We don’t necessarily need faster, better hardware. We need more thoughtful, and more creative humans.
Money line, but I strenuously disagree.
We need both, but thankfully, we have that. Games like Breath of the Wild, Death Stranding, and Kingdom Hearts III; and services like YouTube, TikTok, Twitch, Stadia and Steam wouldn't exist without both. 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.
There's a lot more incentive to get more out of a piece of equipment that will likely never be serviceable by humans again but is still serving a valuable role than there is to get more out of a piece of equipment only ten years old, taking up space and easily replaceable by something that is a capabilities upgrade and quality of life improvement in every measurable way.
There's sentimental value to be had in old hardware and a lot of great games that are 30 or 40 years old; and it's entirely possible there's a fair amount of hardware we never exploited to its full potential before replacing it with something much more capable, but that's life, tech and economics.
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.
I largely agree, with the exception that there are some aesthetic details that just weren't possible to capture the same way. A good example to me is the difference between wind waker and Breath of the wild. Wind waker is a beautiful game, and shows that there is absolutely enough power in the gamecube to make cell shaded art games. But when you pull the bow back for the first time in breath of the wild, and the corners of the screen go out of focus, and you peer between the cell shaded blades of grass at the beautifully animated boar you are trying to hit, it is a much different subjective experience.
The reason I chose those games as examples is because those are all games in which the core gameplay is doable on lesser hardware, but an important aspect of what made them enjoyable to me were the technical improvements over Wind Waker/Twilight Princess, MGS3 and Kingdom Hearts I & II.
Breath of the Wild would not be Breath of the Wild as we know it without the subtle details, more objects in memory, more intelligent AI, graphical details, increased draw distance, made possible by the beefier hardware. The Switch isn't exactly the beefiest hardware to begin with, but there is a noticeable improvement in the gameplay compared to even just the Wii U version.
My favorite game of all time is Chrono Trigger, released in 1995 on the SNES, but part of what made Chrono Trigger special was that many of the game scenarios were hand tuned, down to the placement of enemies on screen and the ways they interacted with you. It is a fun and immersive game, and I still play it every now and then, but you can see the limitations of the original hardware in the game and how much more the all-star crew (seriously, think the Dream Team but for JRPGs, never to be replicated again) could have done with the game with just one generation more of improvements in the hardware.
Chrono trigger is interesting to me too because I know some rpg fans who just can't get past the simpler turn based battle system and hand drawn pixel graphics to unlock the story. If it had a FFVII style remake I would be vastly more enjoyable to lots of people.
> 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.
Just recently I got a Pentium 90 up and running using modern software (NetBSD 9.0). Doing a side by side speed comparison against my 3970x threadripper you can see the AMD is ~200-500x faster on a given task.
The P90 creeks along running the modern kernel. 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.
In this whole exercise I've learned something valuable:
This is all very reasonable.
If someone told me they'd spend an immense effort to speed something up by 0.15 seconds I would think them extremely foolish. That 0.15 seconds translates to 60 seconds on the P90.
My AMD has literally 1,000 times more memory than the P90.
If someone said they spent some enormous effort and took the memory footprint of something from 40MB down to 28MB I'd think they're just doing a hobby but of course on the P90 that's 10% of the memory available.
As machines have progressed, the great wins of the past have become nearly unmeasurable noise.
The OpenSSH server, for example, a fairly competently written piece of software, takes about 8 seconds to serve me a password prompt.
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.
it was a server class machine. It's a Micron tower. I'm using 4 32MB 72 pin EDO modules. I can get a model number if you really want.
It also has a PATA card to support the larger disk (I'm using 20GB) and has a PCI USB card to support well, basically anything (it's kinda fun using a wireless keyboard on it).
My Pentium 60 I bought in 1995 for $2200 came with 4 mb of RAM. I later upgraded it to 8 mb. 540 MB hard drive, 2x CD ROM drive. It ran just about everything I had until I built my next computer in ‘98
I think I got it with an "nas" version of mpg123. I have the test audio in the home directory. You can try it out yourself
Here's a youtube livestream of the machine. The monitor is hooked up and running X under the hn user account along with a set of speakers. You can feel free to run things with the DISPLAY=:0 environment set.
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.
They were rock solid running Linux. I remember we had a 486 where the jiffies counter overflowed (which is what happened on 386/486-era Linux after ~ 497 days). We expected it would crash then, but the machine kept running just fine.
They really weren't. It took lots of configuration tweaks and careful selection of the right software. People could and did do the same thing with Windows back then. But trying to use a PC for general purpose work, straight out of the box, stability was a problem on all extent desktop operating systems.
You have to distinguish between Windows NT and 95/98/Me. I was installing a lot of servers back then and NT was way ahead of Linux in nearly every way.
For me the Pentium was where it started to shift. My 468 got booted several times a day, not just from stability but having to mess with IRQ settings and whatnot for my ISA soundcard etc.
When I installed Windows 2000 on my Pentium 150 box it was pretty much rock solid. Proper memory protection and PCI made life so much better.
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.
> 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.
Developer work is expensive and there's always a backlog of fixes and features. Spending non trivial time on lowering memory consumption from 40 to 28 MB in case of normal end user desktop applicaton is not reasonable in the sense that very few users will care or even notice. This time could be spend developing features with actual user impact.
Right, this is the usually the most common reason brought up. And depending on the situation, it is correct - it is the "depends on other matters" part i wrote.
> Spending non trivial time on lowering memory consumption from 40 to 28 MB in case of normal end user desktop applicaton is not reasonable in the sense that very few users will care or even notice.
This hides a big problem of today’s software. Instead of having time to actually think about their software and optimise it, it’s all about throughput and making the economists happy. That’s why projects use various ready-to-use frameworks and get bloated very quickly. And time to look at the whole monstrosity and think about how you can slim it down “is not reasonable” as nobody pays for that. Users are supposed to get a better computer instead.
The constant ratchet on users to provide ever-increasing amounts of computing resources is a textbook case of an ‘externality’ for the developers so we get the whole usual Tragedy Of The Commons situation yada yada yada.
Applying this to the original question one gets that if performance ceases to increase users can no longer be expected to endlessly ramp up their specs so suddenly optimisation and slimming-down will be in vogue.
I guarantee you 99% of what is on a dev's backlog is senseless busywork that doesn't do anything important. The lack of focus on performance and efficiency has nothing to do with available resources, it is a consequence of management (political) decisions. Those decisions end up being the wrong decisions basically every time, but those are the times we live in.
The bottom line is, if you don't play with the latest fadtech you end up sidelined into a niche, career-wise. God help you if your niche ever goes away; even if it doesn't, embedded C++ developers make about half of what Node.js webshit developers make, despite the job requiring more in the way of specialized skills.
> in case of normal end user desktop applicaton is not reasonable in the sense that very few users will care or even notice.
such a very-first-world country way of thinking.
Hell, I live in france, in a fairly affluent city (Bordeaux), and my two neighbors run their stuff on 15 year old computers as buying newer computers is not really an expense they can make that easily.
But they will never be able to complain to anyone & make their voice heard (except to me, their computer geek neighbor) that things are slow - they don't even know that things could be faster.
I have a bunch of old PCs around (i like collecting them and toying around with them) and i did try to run modern stuff of them with similar results to yours, but my takeaway is always that modern stuff is just bloated without actual need to be - at least most of the time anyway.
Software doesn't have to be slow. My favorite example is Total Commander - a file manager that is still under active development for Windows which not needs almost very little memory (right now i have it open with 10 tabs -and had it open for a while- and it uses 7.3MB of memory) but even runs on something like a P133 with 16MB of RAM running Win95. It wont be that fast, but it will be perfectly usable and packs so many features (actual visible features, not stuff that theoretically might be useful but are behind 29301 layers and i may not even see them or even care about them) that i do not mind.
You have more luck seeing how this works on systems that are not x86 / did not make it out of the 70/80/90s but that were popular then. The fact that this [0] runs on a 3.6mhz processor with 128kb memory shows what can be done when you chisel away at software that has to run on hardware that will not improve.
I had similar hardware 15-20 years ago (my laptop was about the same specs, just maybe 16mb ram?) and I ran NetBSD 1.4.x on it. This was before pkgin so you had to use the ports collection and compile or use the fairly simple pkg_add system.
For web browsing I did dillo and links -g ... it worked on a lot of the internet which at the time still did not heavily rely on stylesheets and javascript for baseline functionality. For email reading I used one of the many terminal readers, I believe pine.
For instant messaging I used naim. Social networking through websites wasn't a thing yet nor was youtube. I used mpg123 to do music and I believe I ran in screen without X up most of the time.
Before that I had an IBM 360c (https://en.wikipedia.org/wiki/IBM_ThinkPad_360) with 8MB of ram. I used I believe NetBSD 1.2 on that. I could even recompile the kernel without hitting swap with some very interesting gcc flags that I have long forgotten - but it still took I believe most of a day (maybe 7 hours?).
NetBSD 1.6 was really where the split began ... the priorities were different and things seemed slower. It is mostly meant for academics and research so this ultimately makes sense.
It's like a lifetime ago.
So when I got this up and running, NetBSD was exactly what I turned to. It's different of course now. But the P90 is surprisingly able to reasonably keep up as long as you have patience and modest expectations.
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...
Microsoft invented AJAX. Google popularized it and developed V8 to make large scale JavaScript applications feasible. Both originally did what they did for email clients.
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...
Speed enables higher lever programming and therefore more people can solve more problems better and faster.
Surely you can fix 40-year-old machine with new software, but how long did it take to write that software and how much more could the machine do if it could be upgraded today?
Also good luck taking iPhone photos in real time with a Pentium 3.
> Once you understand a system – deeply understand – it can do things that its designers never thought possible. You can push hardware beyond its apparent limits.
The interesting question is how much of a performance gain is there from hyperoptimizing for an architecture, how much from porting your code to C (or maybe assembly), and what's the cost. Considering how much more complex software has gotten than Wolfenstein 3D, the porting cost would be pretty expensive. I'm also not sure if the performance gain would be as good as hoped; compilers have gotten a lot better, architectures have gotten a lot more complex and harder to understand.
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.
In principle, a higher level language like eg some variant of Haskell, would give compiler much more freedom to optimize. Including making collapsing what remains at runtime of the path between what your code describes and the missile launching.
Modern machines are stupid fast. Something like 200,000,000,000 cpu instructions per second.
And we're already there. Single core CPU speed has been stagnating for years. We used to get ~1.5x performance boost every 2 years. Today's CPU's are only twice as fast as designs from a decade ago.
Everything is going parallel, which buys us some time. But long term, I think the biggest factor will be "slow" programming languages going extinct.
When you can't depend on CPU performance constantly increasing, companies will look elsewhere. The 10-50x speed difference in programming languages will become a target.
IMO you can already see this happening to Ruby, and Rust. Increasing attention to making low level languages more palatable. And decline of slow languages that don't have other advantages. And I think this is just the beginning with all the focus on energy efficiency.
I dare say performance might even become government regulated, like efficiency is for home appliances
> 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.)
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.
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?
For instance, Donkey Kong Country does run on an unmodified SNES purchased on its launch day, but its creation shouldn't have been possible were it not for the Silicon Graphics workstations used to create the art, which was most likely vastly faster than the development hardware used to create the earliest SNES games. 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.
What we're seeing on the BBC Micro, MegaDrive/Genesis or other evergreen demo platforms is not "what would happen if computers never got any faster," rather it's more like "what would happen if only the computer running the final product never got any faster." We still need faster, better hardware.
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.
That's true in principle, but beyond a certain degree it would leave the realm of practicality, eg. You can pre-render something complex in 3D or do some complex calculations to populate a precomputed table on any computer no matter how slow, and it might be clunky and inconvenient yet still possible if it's merely 2x or 3x slow. But if it's something like 10000x slow doing it would pretty much be out of the question, as real-world projects (even hobbyist ones) are bound by limitations of time and budget.
> 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.
>Back in the day I got my weekly homeopathic dose of assembly language from a local home computer magazine.
I had the same experience, until I (we)found that the knowledge of those magazines were taken from books, so I(we) went to the source, the library of the University.
I was a kid at the time and had friends that shared the same interests as me. The library was magical.
Even today, when there is lots of amazing materials on the web, the real deep stuff is in books.
One of the great things of Internet, specially videos is that they introduce you to a topic so you can understand the book.
> Even today, when there is lots of amazing materials on the web, the real deep stuff is in books.
Years ago my then 7yo was given an assignment: Find out how long woodchucks live in captivity. It was in late January in the USA so the idea is there would be many possible sources of info due to "Groundhog Day": newspapers, books, the Internet, TV... All the kids heard "blah, blah, the Internet, blah" (this was before smart phones and kids that age typically didn't use the Internet so it was exciting).
Much to his annoyance I forced my kid to come with me to the library where the librarian happily showed him how to find the answer. We made some photocopies and wrote the answer at the top. He actually brought home a book full of animal pictures.
I was in school there next day and discovered every other kid had brought a printout of the web (Wikipedia, an article about Groundhog Day, etc) but none actually had the answer to the question. Our photocopies did.
Whether my intransigence had any long term value to the kid is unclear to me.
Today, it is just a single straightforward google request "how long woodchucks live in captivity" -> 14 years (shown on SRP directly) according to pbs.org groundhogs-facts (6 years in the wild)
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.
I don't think that's right. There is absolutely no way that a SNES can, with just "a bit more memory", perform the same computation as a Silicon Graphics workstation of the time. That's like saying you could write a library's worth of books without a printing press if you just had a bit more ink for your pen. No, you couldn't. You would grow old and die long before completion, even if you wrote every second of every day of your entire life.
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.
Yep, special use case : data compression. Many compression that work on old computer are actually the decompression side of an asymmetric compression scheme. Asymmetric meaning that it requires a lot more CPU power than a mere C64 can provide to compress data whereas the same C64 can easily decompress...
I've coded myself a Bad Apple video demo for the Apple 2+. Takes minutes of compression on my I7 but can be decrunched on a 1Mhz 6502.
If computers stop getting faster then larger investments in software development become reasonable.
As we are not limited to a single i7 today, the C64 was hardly the most powerful machine of that time. A Cray X-MP released just after the C64 might take hours to run that same compression, which would have been expensive but hardly impossible.
First an i7 920 is up to 54,000 megaflops vs a cray X-MP at 800 MFlops X minutes on a first gen i7 is ~1.1 hours in terms of pure flops. However, that i7’s architecture has many compromises that tend to make it significantly less efficient.
Newer i7’s have significantly more power, but it’s still few minutes > Y hours not days or anything.
Though not many people would've had have access to a Cray X-MP back in its time, and certainly not to use it for compression in creating a hobbyist Apple II demo that's not expected to generate any profit. Again, possible in theory, but impractical in its day and age.
That’s fair, but if we assume hardware stalls for say 1,000 years you get a different ROI from computer investments. 6 hours on a 30 million dollar supercomputer that lasts for 20 years is ~1,000$ worth of it’s lifespan + electricity costs etc.
Over time you can expect various people to have made such investments and historic examples would still be valuable on “modern” hardware.
>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...
I think the author is misguided by saying "we need more thoughtful, and more creative humans". It's as if the author is lamenting some lost productivity that we would have otherwise achieved as a society by now. Just like how human work naturally fills up the time allotted to it [1], programmers tend to use up the hardware resources to make their apps usable. If time was spent hyperoptimizing, it would not change the computing landscape moving forward. Maybe the author should look into algorithm design and CS research as a way to directly affect the future of computing efficiency.
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.
Hear hear. I remember when MS Works was so slow I'd type and watch letters appearing. Then Word got better, and got quick, I was almost happy. Then cloud happened, and suddenly now whenever I'm saving a file, I find myself waiting again, to connect to the cloud... I am missing full keyboard system where once you learnt a little you could do everything by touch without touching that mouse.. and I'm missing the snappiness.
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.
Lately I've been feeling like computers have become fast enough. During the 1990s, the pace of improvement was staggering, and the impact of every hardware improvement was really felt. But these days, I've come to expect a 10-year life from my hardware. My previous PC, now 12 year old, worked admirably for 10 years. It ran The Witcher 2 just fine. It did everything just fine, except for the latest games; after some update, EU4 stopped running well (I kept playing for years on the last version before that performance-breaking update), and I knew I needed a new PC for The Witcher 3. But frankly, the graphics of The Witcher 2 were already stunning.
Currently that old PC has become unstable and occasionally crashes or reboots. No idea why. I'd love to get it working again, but it feels a bit pointless for such an old PC. But it feels wasteful to just chuck it out; there are tons of things it can still do. Maybe if I just upgrade the CPU?
So do we really need games to continue to demand more and more from the hardware, or should games be made to do more with less? There are excellent games that run fine on lesser hardware.
Arguably the best game of the past decades in Minecraft, and it runs fine on my son's crappy school laptop without GPU (though not at very high framerate, and not when he wants to stream). (I'd really like that laptop to last him for ages, but it turns out he needs Blender for school, and rendering Blender movies requires more GPU.)
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.
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
A large amount of things won't work with the best of software optimizations. You won't be able to decode 4k videos on 20 year old consumer hardware. You won't be able to run games with today's 3D graphics on an N64, no matter how much you're improving the rendering engine. We absolutely do need faster hardware for a whole lot of things, especially multimedia.
I think the opposite conclusion is correct: Hurray, we don't have to dive into the intricacies of hardware and low-level programming anymore, but instead can focus on end-user value and making programming accessible to more people. Sure, building Electron apps is incredibly wasteful and NodeJS' type system allocates way too much memory for something that C++ would be much more frugal with, but who cares? Hardware is cheap, and processing power is cheap. Computers are becoming a commodity layer that simply facilitates human requirements, rather than being the thing that humans have to understand and optimize for.
We've seen the same mind-shift happen for storage: remember the pre-gmail days when Microsoft/Yahoo/Your internal IT department gave you 2MB of email storage, and you had to optimize your mail archive to fit this constraint? Do we really want humans that are better at optimizing mail archives? Of course not, we want mail storage we don't have to think about. And the same is true for computation.
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.
On a similar note: we rarely make use of abstractions that 'compile away', instead using abstractions that bring a runtime performance cost.
An example of this is declarative GUI design. It's a good design idea to use a declarative language for this, as it helps with GUI design tooling (drag-and-drop editors), and eliminates the bugs that could arise from doing the work 'by hand' in a programming language. Most solutions end up parsing XML (or something similar) at runtime, rather than compiling down to an optimised binary. It's possible to 'have it all', in this instance.
At least on the web, this is a feature, not a bug. It allows the user to modify the page as they see fit. For example, ad blockers or "dark mode" extensions would have a much more difficult job if websites were delivered as optimized binaries.
I specify "on the web" because almost all browsers execute the content retrieved from the website with no user interaction besides navigating to a url. Contrast that with operating systems, which all require separate download + run steps (and often a bit flip in between, to mark the file as executable). That's a lot more friction / time for the user to notice if something is not as they expect or want.
I agree it makes sense on the web, which is ultimately a document system, but for a native desktop application I figure it makes good sense to compile away as much as possible.
Agreed on that front — especially since you can distribute the source in addition to the binary so that users can make changes & recompile if they want.
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.
Oh, I remember old versions of SQL Server, they took ALL the memory on the machine. Did not work well if you tried to run something else at the same time.
The author's use case is gaming, actually retro games. While that does not benefit so significantly from faster computers, other industries would significantly benefit from computers running as fast as possible.
Simple use case of doing a compile to generate a binary. Imagine if that process was only a few milliseconds, C language could be reclassified as an interpreted language. :-)
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.
Programs will be rebuild and optimised many times. Fully written in low level assembly. Probably many different versions for each hardware configuration. Ultra low level hacks will be found to speed up the application.
After 50 years they manage to run real-time raytracing on a 486 with some insane unexplainable tricks.
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)
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.
My father was working on a math puzzle, and he asked me if I had any insight into it. I said that it would take me days or weeks of remembering/relearning to have any hope of solving it cleverly -- but the search space for the answers was only factorial(10) possibilities, so I could write a program to brute force it.
I did. 30 minutes of code writing (of which about 20 was spent making sure I didn't miss something) and then less than 3 seconds of computing time later, I had the answer for him. Nothing clever at all -- just trying all the possibilities and seeing if that set fit.
That's sometimes fun. But I also had lots of fun solving eg the first few Project Euler challenges with some math and pen and paper. (And sometimes a desktop calculator.)
Eg https://projecteuler.net/problem=2 "By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms." has a nice (almost) closed form solution that you only need a few integer multiplications and additions to evaluate.
182 comments
[ 4.9 ms ] story [ 143 ms ] threadThat'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.
I think it would be pretty hard to find a Genesis game that would unequivocally demonstrate the 68k in the Genesis was a win over the 65816 in the SNES.
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.
I've been running a 3.5GHz CPU (with 4 HT cores) for nearly 10 years.
That's a lot of weeks. Surely, today, I should be able to buy a 10GHz CPU, right? :D
When people talk of "Moore's law", they really imply that there's a huge class of problems that get solved automatically just because transistors get smaller and smaller.
This hasn't been true for a long while now. Yes, technology get better with time, but we don't get things like 32 cores in a PC just because transistors shrunk; smart people worked really hard to optimize this stuff.
TL;DR - there's no more free lunch in computing anymore.
This was always the case, it was just simpler before. Lunch was never free, it's just getting a few percent more expansive every year.
That metric is a function of clock speed, core count, lithography process, but also how many cycles each instruction takes to execute (e.g. how many cycles for an add), the instruction level parallelism in each core, branch prediction, memory architecture and caching, instruction set architecture (ISA) and its implementation, available cooling and more.
For example, by optimizing the number of cycles per instruction, increasing instruction level parallelism and branch prediction you can get a significant boost in performance, as witnessed by the massive jump[1] from the 486DX2 66Mhz to the Pentium 60 (also at 66Mhz in the video below).
[1]: https://www.youtube.com/watch?v=NLrKxWL73Mw
You can decode more instructions at the same time. In theory there is no limit to how many instructions you can decode at once.
Those decoded instructions end up in a buffer and execution units can process them if there are no data dependencies. You can add as many execution units as you like if there is enough work for them.
You can avoid performance destroying events like pipeline stalls by predicting the execution flow of instructions. Better branch prediction means less performance is lost.
None of these have anything to do with clock speed.
That said, I would also dispute that increasing core count doesn't matter. That does seem to be the main way to get more computing power.
Same deal with servers: AWS and Azure are dog-slow compared to the on-premises server hardware we'd have before "the cloud".
Yes, the compute cores are going at the same speed. But you aren't getting the significant advantage of other hardware optimizations.
Just look at the M1 benchmarks for goodness sake. (A bit unfair because it's RISC-V based, but even x86 hardware has improved enormously in the last decade.)
RISC-V is a specific (RISC-based) ISA. ARM is a family of RISC-architectures, which does not include RISC-V.
Apple's M1 is an ARM SoC. It does not use RISC-V.
No, it really hasn't! My ancient x220 is still as fast as, or faster than almost all pre 2020 laptops. By contrast, hardware in the period of time ~9 years before 2011 when I bought it is absurdly slower to the point of unusability. Same story with my threadripper versus my 2009 era desktop. For single threaded stuff, not IO bound, they're subjectively about the same. If I need a lot of threads, big memory or big IO, the recent machine is comically faster (like 100-1000x), but lots of things are single thread bound. Again if I take the leap back in time separating the threadripper from my 2009 era machine; there were huge improvements in performance; imagine trying to compile something on a 1998 era tower like OP did.
How so?
(I'm talking from desktop perspective)
I'm following tech news and it feels like there's always news about AMD releasing new stuff or Intel trying to catch up
I bought my 8 cores CPU for +-125$ of _my_currency_ year ago which was unbelievable like 3? years ago. Meanwhile I'm still far behind of what's on the edge.
Also nowadays I can spend like 60$ of _my_currency to get insanely fast NVMe M2 disks, so things are cheap nowadays I guess.
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.
It’s cheaper to develop faster hardware that can be used again and again than ‘clever’ software that achieves the same on less capable hardware.
I often wonder to what degree that is possible in modern computers. Their complexity so hugely beyond that of old 8-bit micros that I doubt a single person could completely understand it. I mean to the level it’s possible to understand a BBC micro - what every CPU cycle does, what function every gate in the video output performs, etc.
A lot of the improvements listed are due to understanding very minute details of the operation, like timing CPU exactly with the video output, changing palettes and sprites on the fly, racing the CRT beam, etc. With a reasonably modern CPU you can’t even reliably tell in advance how many cycles a simple instruction will take.
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.
[1] https://www.semiconductors.org/wp-content/uploads/2018/06/5_...
[2] https://ieeexplore.ieee.org/document/1645639
Money line, but I strenuously disagree.
We need both, but thankfully, we have that. Games like Breath of the Wild, Death Stranding, and Kingdom Hearts III; and services like YouTube, TikTok, Twitch, Stadia and Steam wouldn't exist without both. 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.
There's a lot more incentive to get more out of a piece of equipment that will likely never be serviceable by humans again but is still serving a valuable role than there is to get more out of a piece of equipment only ten years old, taking up space and easily replaceable by something that is a capabilities upgrade and quality of life improvement in every measurable way.
There's sentimental value to be had in old hardware and a lot of great games that are 30 or 40 years old; and it's entirely possible there's a fair amount of hardware we never exploited to its full potential before replacing it with something much more capable, but that's life, tech and economics.
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.
Breath of the Wild would not be Breath of the Wild as we know it without the subtle details, more objects in memory, more intelligent AI, graphical details, increased draw distance, made possible by the beefier hardware. The Switch isn't exactly the beefiest hardware to begin with, but there is a noticeable improvement in the gameplay compared to even just the Wii U version.
My favorite game of all time is Chrono Trigger, released in 1995 on the SNES, but part of what made Chrono Trigger special was that many of the game scenarios were hand tuned, down to the placement of enemies on screen and the ways they interacted with you. It is a fun and immersive game, and I still play it every now and then, but you can see the limitations of the original hardware in the game and how much more the all-star crew (seriously, think the Dream Team but for JRPGs, never to be replicated again) could have done with the game with just one generation more of improvements in the hardware.
And market competition engendering innovation
Progress in SW is much harder. There we are indeed still in the ancient ages.
The P90 creeks along running the modern kernel. 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.
In this whole exercise I've learned something valuable:
This is all very reasonable.
If someone told me they'd spend an immense effort to speed something up by 0.15 seconds I would think them extremely foolish. That 0.15 seconds translates to 60 seconds on the P90.
My AMD has literally 1,000 times more memory than the P90.
If someone said they spent some enormous effort and took the memory footprint of something from 40MB down to 28MB I'd think they're just doing a hobby but of course on the P90 that's 10% of the memory available.
As machines have progressed, the great wins of the past have become nearly unmeasurable noise.
The OpenSSH server, for example, a fairly competently written piece of software, takes about 8 seconds to serve me a password prompt.
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.
---
Here's me doing a
* side-by-side gcc compilation: https://www.youtube.com/watch?v=GUk9f7Nv2dM
* trying to play a video I had transcoded to 160x120 in a futile attempt https://www.youtube.com/watch?v=ZMTz5PNpkcw (original video I'm attempting to play is here: https://shop.cpurecords.net/track/sheffield-bleep)
---
Edit: I'll give y'all access.
* telnet bootstra386.com:1994
* ssh bootstra386.com:1995
* user/pass: hn/hn
cat /proc/cpuinfo and /proc/meminfo if you want to gawk. I've put some nice things in /usr/pkg/bin. Try not to wreck it.
It also has a PATA card to support the larger disk (I'm using 20GB) and has a PCI USB card to support well, basically anything (it's kinda fun using a wireless keyboard on it).
http://getpostdelete.com/PXL_20201126_073138155.jpg
http://bootstra386.com/~hn/
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...
Here's a youtube livestream of the machine. The monitor is hooked up and running X under the hn user account along with a set of speakers. You can feel free to run things with the DISPLAY=:0 environment set.
Have fun.
https://www.youtube.com/watch?v=xcA8kiqd_n4
When I installed Windows 2000 on my Pentium 150 box it was pretty much rock solid. Proper memory protection and PCI made life so much better.
> 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.
Developer work is expensive and there's always a backlog of fixes and features. Spending non trivial time on lowering memory consumption from 40 to 28 MB in case of normal end user desktop applicaton is not reasonable in the sense that very few users will care or even notice. This time could be spend developing features with actual user impact.
This hides a big problem of today’s software. Instead of having time to actually think about their software and optimise it, it’s all about throughput and making the economists happy. That’s why projects use various ready-to-use frameworks and get bloated very quickly. And time to look at the whole monstrosity and think about how you can slim it down “is not reasonable” as nobody pays for that. Users are supposed to get a better computer instead.
Applying this to the original question one gets that if performance ceases to increase users can no longer be expected to endlessly ramp up their specs so suddenly optimisation and slimming-down will be in vogue.
Developers focused on building their resume or playing with the latest fadtech are at least as much to blame!
such a very-first-world country way of thinking.
Hell, I live in france, in a fairly affluent city (Bordeaux), and my two neighbors run their stuff on 15 year old computers as buying newer computers is not really an expense they can make that easily. But they will never be able to complain to anyone & make their voice heard (except to me, their computer geek neighbor) that things are slow - they don't even know that things could be faster.
But there's a cost - my apps will suffer in other ways and won't be able to offer other features.
Software doesn't have to be slow. My favorite example is Total Commander - a file manager that is still under active development for Windows which not needs almost very little memory (right now i have it open with 10 tabs -and had it open for a while- and it uses 7.3MB of memory) but even runs on something like a P133 with 16MB of RAM running Win95. It wont be that fast, but it will be perfectly usable and packs so many features (actual visible features, not stuff that theoretically might be useful but are behind 29301 layers and i may not even see them or even care about them) that i do not mind.
[0] http://www.symbos.de/
> * ssh bootstra386.com:1995
Ha! These port numbers made my day:)
For web browsing I did dillo and links -g ... it worked on a lot of the internet which at the time still did not heavily rely on stylesheets and javascript for baseline functionality. For email reading I used one of the many terminal readers, I believe pine.
For instant messaging I used naim. Social networking through websites wasn't a thing yet nor was youtube. I used mpg123 to do music and I believe I ran in screen without X up most of the time.
Before that I had an IBM 360c (https://en.wikipedia.org/wiki/IBM_ThinkPad_360) with 8MB of ram. I used I believe NetBSD 1.2 on that. I could even recompile the kernel without hitting swap with some very interesting gcc flags that I have long forgotten - but it still took I believe most of a day (maybe 7 hours?).
NetBSD 1.6 was really where the split began ... the priorities were different and things seemed slower. It is mostly meant for academics and research so this ultimately makes sense.
It's like a lifetime ago.
So when I got this up and running, NetBSD was exactly what I turned to. It's different of course now. But the P90 is surprisingly able to reasonably keep up as long as you have patience and modest expectations.
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...
Surely you can fix 40-year-old machine with new software, but how long did it take to write that software and how much more could the machine do if it could be upgraded today?
Also good luck taking iPhone photos in real time with a Pentium 3.
The original Atari 2600 Pac Man was notoriously bad. Someone made a much better version in 2014.
http://retrogamingmagazine.com/2015/09/07/pac-man-on-atari-2...
https://atariage.com/forums/topic/229152-new-pacman-for-atar...
The interesting question is how much of a performance gain is there from hyperoptimizing for an architecture, how much from porting your code to C (or maybe assembly), and what's the cost. Considering how much more complex software has gotten than Wolfenstein 3D, the porting cost would be pretty expensive. I'm also not sure if the performance gain would be as good as hoped; compilers have gotten a lot better, architectures have gotten a lot more complex and harder to understand.
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 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.
In practice, we aren't quite there yet.
And we're already there. Single core CPU speed has been stagnating for years. We used to get ~1.5x performance boost every 2 years. Today's CPU's are only twice as fast as designs from a decade ago.
Everything is going parallel, which buys us some time. But long term, I think the biggest factor will be "slow" programming languages going extinct.
When you can't depend on CPU performance constantly increasing, companies will look elsewhere. The 10-50x speed difference in programming languages will become a target.
IMO you can already see this happening to Ruby, and Rust. Increasing attention to making low level languages more palatable. And decline of slow languages that don't have other advantages. And I think this is just the beginning with all the focus on energy efficiency.
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.)
then make this language faster, problem solved :)
For instance, Donkey Kong Country does run on an unmodified SNES purchased on its launch day, but its creation shouldn't have been possible were it not for the Silicon Graphics workstations used to create the art, which was most likely vastly faster than the development hardware used to create the earliest SNES games. 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.
What we're seeing on the BBC Micro, MegaDrive/Genesis or other evergreen demo platforms is not "what would happen if computers never got any faster," rather it's more like "what would happen if only the computer running the final product never got any faster." We still need faster, better hardware.
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.
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.
I had the same experience, until I (we)found that the knowledge of those magazines were taken from books, so I(we) went to the source, the library of the University.
I was a kid at the time and had friends that shared the same interests as me. The library was magical.
Even today, when there is lots of amazing materials on the web, the real deep stuff is in books.
One of the great things of Internet, specially videos is that they introduce you to a topic so you can understand the book.
Years ago my then 7yo was given an assignment: Find out how long woodchucks live in captivity. It was in late January in the USA so the idea is there would be many possible sources of info due to "Groundhog Day": newspapers, books, the Internet, TV... All the kids heard "blah, blah, the Internet, blah" (this was before smart phones and kids that age typically didn't use the Internet so it was exciting).
Much to his annoyance I forced my kid to come with me to the library where the librarian happily showed him how to find the answer. We made some photocopies and wrote the answer at the top. He actually brought home a book full of animal pictures.
I was in school there next day and discovered every other kid had brought a printout of the web (Wikipedia, an article about Groundhog Day, etc) but none actually had the answer to the question. Our photocopies did.
Whether my intransigence had any long term value to the kid is unclear to me.
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.
I've coded myself a Bad Apple video demo for the Apple 2+. Takes minutes of compression on my I7 but can be decrunched on a 1Mhz 6502.
As we are not limited to a single i7 today, the C64 was hardly the most powerful machine of that time. A Cray X-MP released just after the C64 might take hours to run that same compression, which would have been expensive but hardly impossible.
First an i7 920 is up to 54,000 megaflops vs a cray X-MP at 800 MFlops X minutes on a first gen i7 is ~1.1 hours in terms of pure flops. However, that i7’s architecture has many compromises that tend to make it significantly less efficient.
Newer i7’s have significantly more power, but it’s still few minutes > Y hours not days or anything.
Over time you can expect various people to have made such investments and historic examples would still be valuable on “modern” hardware.
Well, if by "many" you mean "mostly games", yes. Not true for other kinds of software...
1: https://en.wikipedia.org/wiki/Parkinson%27s_law
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.
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.
Yes, but, oh ... yeah :-)
"The moment the robots realize that the three laws of robotics are just socially constructed norms"
[1] https://twitter.com/Thinkwert/status/1325980944654856193
...
Wait a minute.
Currently that old PC has become unstable and occasionally crashes or reboots. No idea why. I'd love to get it working again, but it feels a bit pointless for such an old PC. But it feels wasteful to just chuck it out; there are tons of things it can still do. Maybe if I just upgrade the CPU?
So do we really need games to continue to demand more and more from the hardware, or should games be made to do more with less? There are excellent games that run fine on lesser hardware.
Arguably the best game of the past decades in Minecraft, and it runs fine on my son's crappy school laptop without GPU (though not at very high framerate, and not when he wants to stream). (I'd really like that laptop to last him for ages, but it turns out he needs Blender for school, and rendering Blender movies requires more GPU.)
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.
We've seen the same mind-shift happen for storage: remember the pre-gmail days when Microsoft/Yahoo/Your internal IT department gave you 2MB of email storage, and you had to optimize your mail archive to fit this constraint? Do we really want humans that are better at optimizing mail archives? Of course not, we want mail storage we don't have to think about. And the same is true for computation.
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.
An example of this is declarative GUI design. It's a good design idea to use a declarative language for this, as it helps with GUI design tooling (drag-and-drop editors), and eliminates the bugs that could arise from doing the work 'by hand' in a programming language. Most solutions end up parsing XML (or something similar) at runtime, rather than compiling down to an optimised binary. It's possible to 'have it all', in this instance.
I specify "on the web" because almost all browsers execute the content retrieved from the website with no user interaction besides navigating to a url. Contrast that with operating systems, which all require separate download + run steps (and often a bit flip in between, to mark the file as executable). That's a lot more friction / time for the user to notice if something is not as they expect or want.
Simple use case of doing a compile to generate a binary. Imagine if that process was only a few milliseconds, C language could be reclassified as an interpreted language. :-)
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
Why not both? Configurable CPUs and a upgradable runtime, all this we have now.
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.
I did. 30 minutes of code writing (of which about 20 was spent making sure I didn't miss something) and then less than 3 seconds of computing time later, I had the answer for him. Nothing clever at all -- just trying all the possibilities and seeing if that set fit.
Eg https://projecteuler.net/problem=2 "By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms." has a nice (almost) closed form solution that you only need a few integer multiplications and additions to evaluate.