Comment by 0xcde4c3db | Hacker News Reader

Comment by 0xcde4c3db | Hacker News Reader

Parent Full thread

> “why was my Comodore64 more responsive than a PC i bought in 2016?”

Not because of C; that's for sure. The two biggest reasons are:

1) Your Commodore 64 is doing at least a couple orders of magnitude less actual work. This has less to do with language choice than it does with a programmer who is fully in touch with the problem to be solved and can identify unnecessary work to eliminate.

2) Your Commodore 64 is effectively designed in a way that prioritizes latency over throughput. Pipelines and buffers are small-to-nonexistent. When you read the joystick port, you sample the state of that joystick at that very microsecond; you're not asking one microcontroller to ask another microcontroller to start thinking about sending the input it sampled 10 milliseconds ago. The worst-case latency from changing the video data to seeing it on screen is measured in lines, not frames (assuming a low-latency display like a dumb CRT). Virtually nothing is asynchronous. Systems aren't built that way anymore because we want to be able to push massive amounts of data through subsystems that can't all run in lockstep to one fast master clock, and that means lots of buffering and burst transfers.

I don't understand why you guys hang on the fact C64 wasn't coded in C. I never said it was. I talk about C-like languages, so low-level, with little to no overhead.

I understand that computers worked differently back then, and that software usually had full control over the machine, but please, don't talk to me about buffering, etc. when we're talking 6502 versus an i7, or an A8. I understand that input and output aren’t instant these days, but that’s an order of tens to hundreds milliseconds of delay. It doesn’t explain why Visual Studio takes tens of seconds to compile “Hello, World!” on a 16 core processor. Or why your Chrome tab eats 600MB of RAM.

Since you want to talk about buffering and built-in input delay, here’s a comparison of text editor performance:

https://pavelfatin.com/typing-with-pleasure/#windows

I guess what I'm getting at -- and could have communicated better -- is that this approach of "buffer/queue/cache/defer everything because it's faster right now, never mind that we might have to stall and flush the pipeline all at once later" has worked its way up the stack, with the worst-case stall growing in magnitude as the path cascades through progressively more layers and bigger buffers (cf. bufferbloat in networks [1]). Among other issues, it fools people into thinking that expensive operations are cheap. I think that pattern is far more responsible than language-imposed overhead for the weird quasi-random delays that are seen in modern systems. You can certainly connect this to popular idioms and some standard library facilities in some higher-level languages, but I think that connection is largely a historical accident rather than having much to do with the languages themselves.

[1] https://en.wikipedia.org/wiki/Bufferbloat

Reply on news.ycombinator.com