4 ms·

On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Tod

by Faark 7y ago

On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Today's systems are complicated, and we try to hide that complexity behind abstractions. All of those with buffers. Input buffers, OS message buffers, tripple image buffers, and so on. All of it adding time. Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.

dahart 7y ago
There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there. > we won't again have the responsiveness we had 30 years ago. Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response. Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip. > the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.
- mntmoss 7y ago
  The raw throughputs are definitely better but there is concern regarding latency even at the lowest levels, since today's CPUs have complex cache, power state and frequency throttling mechanisms. You cannot guarantee that something will perform with identical runtime in all expected use-cases unless you take care to use hardware that is optimized in that direction. And because the software environments are more complex a lot of capability is just dropped on the floor because the intermediate layers get in the way. W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today. With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels. Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.
  - dahart 7y ago
    Ah, I've been meaning to read Racing the Beam for years! That's all true, and thanks for an insightful comment! I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying. Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.
- bbojan 7y ago
  Check out https://danluu.com/input-lag/ https://danluu.com/input-lag/ , where the author measured latency between a keypress and the display of a character in a terminal for systems built 1977-2017. For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.
  - dahart 7y ago
    This is a great chart, and I've seen it before here on HN. Just in case you were thinking this is perhaps a counter-example to what I said, I think it's the other way around, it very much supports my claim. The processors have (obviously) gotten faster, and yet for some applications latency has seemingly gone down. Why? Software and requirements are the reason, not hardware. Terminals also are not an example of the "best systems" in terms of latency. You'd be much closer if you looked at video game latency, or tracked industrial applications that have low latency requirements from the start. The whole reason terminals have gotten slow is that they aren't trying to go fast. Quite a few of today's most modern terminals have recently added performance as a feature, started rendering with the GPU, and quite predictably, they are restoring super fast response times to our terminals. iTerm2 would be an example of this.
novok 7y ago
You can make apps with complicated, animated UIs that respond in 16ms just fine with the hardware of an iPhone 4, which is way past the era of CRTs and direct keyboard polling. We know this because we made those apps 7 years ago. Performance is always a business decision. Most people don't want to pay for it.
- Faark 7y ago
  I admit not having good, hard data. My most vivid related memory is comparing the back then new flat screen to the my CRTs and being disappointed with both delay and sharpness (CRTs exponential decay is way nicer imo). Obviously wouldn't expect those to have gotten worse, though. Anyway, you mentioned phones: 16ms from touch to response on screen? That's hard for me to believe and I'd love to read up on that, if you got any sources. The ones I've found were not that great but don't paint such a good picture. [0] is an article claiming touch sensors scan only once per frame, aka 16ms at the time. [1] claims ~85ms to response on an iPhone 4, ~55ms on iPhone 5. How were you able to easily beat those by such a margin? [0] https://www.anandtech.com/show/9605/the-ios-9-review/9#InputLag https://www.anandtech.com/show/9605/the-ios-9-review/9#Input... [1] https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-than-best-android-screen/ https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-tha...
  - novok 7y ago
    There are other parts of the program beyond touches, such as scroll performance and what you do in reaction to touch events. Also the user doesn't move their finger within 85ms anyway if you think about it. That is moving to tap the phone, smushing their finger into the phone and then moving their finger away from the phone to see the result. Nowadays you have 120hz scrolling on the ipad and the very fast responsiveness of things like the apple pencil, which shows you that responsive hardware and software is definitely possible.
varjag 7y ago
I have a distributed networked system on $35 off-the-shelf modules running Linux synced to under 100 microseconds measured deviation. There is no good technical reason for slow UI elements in 2019.

by Faark 7y ago

dahart 7y ago

There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there. > we won't again have the responsiveness we had 30 years ago. Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response. Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip. > the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.

mntmoss 7y ago
The raw throughputs are definitely better but there is concern regarding latency even at the lowest levels, since today's CPUs have complex cache, power state and frequency throttling mechanisms. You cannot guarantee that something will perform with identical runtime in all expected use-cases unless you take care to use hardware that is optimized in that direction. And because the software environments are more complex a lot of capability is just dropped on the floor because the intermediate layers get in the way. W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today. With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels. Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.
- dahart 7y ago
  Ah, I've been meaning to read Racing the Beam for years! That's all true, and thanks for an insightful comment! I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying. Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.
bbojan 7y ago
Check out https://danluu.com/input-lag/ https://danluu.com/input-lag/ , where the author measured latency between a keypress and the display of a character in a terminal for systems built 1977-2017. For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.
- dahart 7y ago
  This is a great chart, and I've seen it before here on HN. Just in case you were thinking this is perhaps a counter-example to what I said, I think it's the other way around, it very much supports my claim. The processors have (obviously) gotten faster, and yet for some applications latency has seemingly gone down. Why? Software and requirements are the reason, not hardware. Terminals also are not an example of the "best systems" in terms of latency. You'd be much closer if you looked at video game latency, or tracked industrial applications that have low latency requirements from the start. The whole reason terminals have gotten slow is that they aren't trying to go fast. Quite a few of today's most modern terminals have recently added performance as a feature, started rendering with the GPU, and quite predictably, they are restoring super fast response times to our terminals. iTerm2 would be an example of this.

novok 7y ago

You can make apps with complicated, animated UIs that respond in 16ms just fine with the hardware of an iPhone 4, which is way past the era of CRTs and direct keyboard polling. We know this because we made those apps 7 years ago. Performance is always a business decision. Most people don't want to pay for it.

Faark 7y ago
I admit not having good, hard data. My most vivid related memory is comparing the back then new flat screen to the my CRTs and being disappointed with both delay and sharpness (CRTs exponential decay is way nicer imo). Obviously wouldn't expect those to have gotten worse, though. Anyway, you mentioned phones: 16ms from touch to response on screen? That's hard for me to believe and I'd love to read up on that, if you got any sources. The ones I've found were not that great but don't paint such a good picture. [0] is an article claiming touch sensors scan only once per frame, aka 16ms at the time. [1] claims ~85ms to response on an iPhone 4, ~55ms on iPhone 5. How were you able to easily beat those by such a margin? [0] https://www.anandtech.com/show/9605/the-ios-9-review/9#InputLag https://www.anandtech.com/show/9605/the-ios-9-review/9#Input... [1] https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-than-best-android-screen/ https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-tha...
- novok 7y ago
  There are other parts of the program beyond touches, such as scroll performance and what you do in reaction to touch events. Also the user doesn't move their finger within 85ms anyway if you think about it. That is moving to tap the phone, smushing their finger into the phone and then moving their finger away from the phone to see the result. Nowadays you have 120hz scrolling on the ipad and the very fast responsiveness of things like the apple pencil, which shows you that responsive hardware and software is definitely possible.

varjag 7y ago

I have a distributed networked system on $35 off-the-shelf modules running Linux synced to under 100 microseconds measured deviation. There is no good technical reason for slow UI elements in 2019.