131–140 of 183 posts
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 lang…
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 t…
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 an…
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.
Earlier quoted context omitted.
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 deco…
> 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…
Earlier quoted context omitted.
operations per second is what ultimately matters.
How do ops/s relate to clock speed, core count and architecture (x nm) then?
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).
Earlier quoted context omitted.
> 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 info…
>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 m…
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 t…
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.
Earlier quoted context omitted.
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) a…
Earlier quoted context omitted.
operations per second is what ultimately matters.
How do ops/s relate to clock speed, core count and architecture (x nm) then?
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.
Earlier quoted context omitted.
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 an…
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 decrun…
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.
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 who…
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.