Comment by vanderZwan
4 hours ago
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.
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.