Comment by 1718627440
6 hours ago
And how ridiculously slow software is. Unless you are doing bulk processing most task should be ready in milliseconds.
6 hours ago
And how ridiculously slow software is. Unless you are doing bulk processing most task should be ready in milliseconds.
In terms of throughput, absolutely.
In terms of latency... well... we also could do a lot better there, but as I understand it, even if you do your best to cut away as much software bloat as possible, the latency "floor" seems to be higher than in the old days[0]. And the many layers of abstraction that is the average software stack don't help. Like, I'm doing my best to keep a web-app snappy, but there's only so much you can squeeze out of a browser.
[0] https://danluu.com/input-lag/
Latency can be reduced with removing the memory management-as with uclinux- https://github.com/EI2030/FemtoTX/blob/gh-pages/uclinux_intr...
But chips today are much larger and are basically a cruise ship or an aircraft carrier- bigger with more work than a bike. https://www.inkandswitch.com/slow-software/
https://youtu.be/oE4cbIP5ieQ?si=h1I51dWw5w-OulVs
Actually latency is way less of a problem, if the input is buffered, as you can just type ahead.
I think we're talking about different interpretations of the word "latency", both valid. You are thinking more about UI freezes and missing input, right? EDIT: or do you mean that bad latency numbers are less crucial as long as input isn't dropped or out of order? In that case I think it depends on the task.
I meant "time between input and visible change on screen", or lag between writing on a tablet and the screen or eink showing the drawn line. It's not really as crucial when typing, but especially for writing or drawing on a tablet low input latency is the difference between getting in a real flow state or not.
1 reply →