9 ms·

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 over

by dreta 10y ago

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 https://pavelfatin.com/typing-with-pleasure/#windows

0xcde4c3db 10y ago
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 https://en.wikipedia.org/wiki/Bufferbloat

by dreta 10y ago

0xcde4c3db 10y ago

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 https://en.wikipedia.org/wiki/Bufferbloat