16 ms·

Given the speed of modern computers, I'm fascinated by the fact that so many processes complete in human-scale time (seconds-minutes), rather than milliseconds

by glial 9y ago

Given the speed of modern computers, I'm fascinated by the fact that so many processes complete in human-scale time (seconds-minutes), rather than milliseconds or years+, depending on problem complexity. If times for compute tasks have some power law distribution (a big if...), I'd expect a very small part of that distribution to overlap with the 'seconds' range. Then again, computers do so many things in the millisecond range and faster that maybe what we observe IS only a small fraction of the total.

adambyrtek 9y ago
I think it's mostly a cognitive bias, we don't even notice processes that take milliseconds, and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical.
- tome 9y ago
  > and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical. Or we just don't do them.
dagss 9y ago
You have it on the head. The tasks we pick for computing are the ones that can be completed in seconds. There is plenty of interesting computation we could and would do if what now requires a year would only require a second.
- bo1024 9y ago
  I think the opposite direction is actually more telling. Developers tolerate bloat and BS up to the level of seconds. So there is plenty of computation being done that only requires milli or microseconds, but due to development practices now stretches just out into the annoying time frame. (Prime example: the growth of web pages to match increases in processing, RAM, and internet speeds, means that the web is actually slower to use these days.)
  - bjterry 9y ago
    When the web was young and most people were on dialup, having access to a T1 meant that everything happened nearly instantaneously. All the sites were optimized for dialup levels of complexity. Now that everyone has broadband there is no equivalent. The slowness is either because the page is so heavyweight in terms of memory or processing power (note that more money does not buy much single-threaded performance), or because it's making so many network requests that everyone faces at a similar latency. Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.
    - digi_owl 9y ago
      All programs grow to outstrip available computing resources?
    - 15charlimit 9y ago
      > Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again. Until you install an adblocker and disable javascript. An enormous amount of modern-web overhead is adtech and user tracking cancer. If you don't believe me, install privacy badger/ghostery and ublock origin, visit any popular news/entertainment website, and look at the number of blocked elements/requests as you load a few articles. All of those take time and suck up resources.
      - flappysquirrel 9y ago
        Bufferbloat.
- buckminster 9y ago
  I've experienced this. My first computer managed about 100 flop/s, or 3 Gflop/year. A modern PC can do that year's work in a millisecond! Yet when my current computer struggles to display a web page there isn't much interesting computation going on.
Cthulhu_ 9y ago
It's a relief to do a bit of Go from time to time, render a complete html template in 40 ms (with almost 2 MB of JSON data) instead of spending forever figuring out the JS framework du jour to do the same thing, only with it feeling a lot more involved, heavyweight, and slow - even if said framework claims to be faster than all the other JS frameworks. I think I want to do back-end or terminal-based interfaces again. Native interfaces. Mmmmm
- zaarn 9y ago
  I've had a similar experience on a current project. Even after disabling any and all caching and minification (read: basically parsing all templates per request, a bit like PHP), the entire render process take less than 20ms of time to the point that I've simply left out caching during some production runs. I also keep the interface free of any expensive rendering precisely because I don't really need all of the niceties of JS frameworks. Surely, the page could be more fancy but vanilla HTML5/CSS3/JS can do the job too. (And document.querySelector has replaced jQuery for me)
- mwcampbell 9y ago
  > Native interfaces. Mmmmm If you decide to work on native GUIs, please don't create your own toolkit on the assumption that you can do better than the OS. You'll almost certainly break at least one thing: accessibility for blind people.
- wesleytodd 9y ago
  This has nothing to do with Go and a lot to do with choosing the right tool for the job. Maybe Go is the best tool for you in this job, but a given js framework can serve someone else just as well if it is in their expertise area. Don't confuse your expertise with language/ecosystem pros and cons.
  - theon144 9y ago
    This has nothing to do with choosing the right tool for the job, but with performance, which this discussion is about. Practically all JS frameworks, having multiple levels of (near-inscrutable) abstractions naturally degrade the performance and certainly contribute to the trend the submitted twitter thread is talking about.
dredmorbius 9y ago
It's pretty much an availability heuristic / complexity (or cost) constraint. If the operation cannot be done quickly -- in a few seconds at most for reasonably interactive work, in a few minutes to, perhaps, a few days for batch -- then it's very, very very rarely done. It it occurs in less than about 1/10 second, there's not much incentive to try to speed it up, and inefficiencies that bump process time up to even a few seconds tend to creep in. That despite the fact that there are psychologically and outcomes-measurable differences between interfaces with even 1/10s vs. 1/1000s delays or responses. The Jevons Paradox plays into this, balancing against Gresham's. Stuff that's cheap (clock time) happens, stuff that's non-discernable (under perceptible / outcomes limits) tends not to get constrained.
skizm 9y ago
Software engineers optimize for human scale time.
- Chaebixi 9y ago
  I kinda feel that UI developers should work with crappy, old PCs. Then they could optimize to the point where things are barely usable to them, but then they'd be snappy for everyone else.
  - SirZimzim 9y ago
    Luckily Google Chrome has added device emulation recently for slower devices and network conditions. Hopefully tooling like that will make it in many developers Workflows.
jayd16 9y ago
We're usually not computationally bound. Often its disk or network I/O and that basically means tasks are content bound. We tune for maximum content in the acceptable human scale time. The moment we take less than a second to load something it means we can find more things to load.

by glial 9y ago

adambyrtek 9y ago

I think it's mostly a cognitive bias, we don't even notice processes that take milliseconds, and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical.

tome 9y ago
> and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical. Or we just don't do them.

dagss 9y ago

You have it on the head. The tasks we pick for computing are the ones that can be completed in seconds. There is plenty of interesting computation we could and would do if what now requires a year would only require a second.

bo1024 9y ago
I think the opposite direction is actually more telling. Developers tolerate bloat and BS up to the level of seconds. So there is plenty of computation being done that only requires milli or microseconds, but due to development practices now stretches just out into the annoying time frame. (Prime example: the growth of web pages to match increases in processing, RAM, and internet speeds, means that the web is actually slower to use these days.)
- bjterry 9y ago
  When the web was young and most people were on dialup, having access to a T1 meant that everything happened nearly instantaneously. All the sites were optimized for dialup levels of complexity. Now that everyone has broadband there is no equivalent. The slowness is either because the page is so heavyweight in terms of memory or processing power (note that more money does not buy much single-threaded performance), or because it's making so many network requests that everyone faces at a similar latency. Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.
  - digi_owl 9y ago
    All programs grow to outstrip available computing resources?
  - 15charlimit 9y ago
    > Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again. Until you install an adblocker and disable javascript. An enormous amount of modern-web overhead is adtech and user tracking cancer. If you don't believe me, install privacy badger/ghostery and ublock origin, visit any popular news/entertainment website, and look at the number of blocked elements/requests as you load a few articles. All of those take time and suck up resources.
    - flappysquirrel 9y ago
      Bufferbloat.
buckminster 9y ago
I've experienced this. My first computer managed about 100 flop/s, or 3 Gflop/year. A modern PC can do that year's work in a millisecond! Yet when my current computer struggles to display a web page there isn't much interesting computation going on.

Cthulhu_ 9y ago

It's a relief to do a bit of Go from time to time, render a complete html template in 40 ms (with almost 2 MB of JSON data) instead of spending forever figuring out the JS framework du jour to do the same thing, only with it feeling a lot more involved, heavyweight, and slow - even if said framework claims to be faster than all the other JS frameworks. I think I want to do back-end or terminal-based interfaces again. Native interfaces. Mmmmm

zaarn 9y ago
I've had a similar experience on a current project. Even after disabling any and all caching and minification (read: basically parsing all templates per request, a bit like PHP), the entire render process take less than 20ms of time to the point that I've simply left out caching during some production runs. I also keep the interface free of any expensive rendering precisely because I don't really need all of the niceties of JS frameworks. Surely, the page could be more fancy but vanilla HTML5/CSS3/JS can do the job too. (And document.querySelector has replaced jQuery for me)
mwcampbell 9y ago
> Native interfaces. Mmmmm If you decide to work on native GUIs, please don't create your own toolkit on the assumption that you can do better than the OS. You'll almost certainly break at least one thing: accessibility for blind people.
wesleytodd 9y ago
This has nothing to do with Go and a lot to do with choosing the right tool for the job. Maybe Go is the best tool for you in this job, but a given js framework can serve someone else just as well if it is in their expertise area. Don't confuse your expertise with language/ecosystem pros and cons.
- theon144 9y ago
  This has nothing to do with choosing the right tool for the job, but with performance, which this discussion is about. Practically all JS frameworks, having multiple levels of (near-inscrutable) abstractions naturally degrade the performance and certainly contribute to the trend the submitted twitter thread is talking about.

dredmorbius 9y ago

It's pretty much an availability heuristic / complexity (or cost) constraint. If the operation cannot be done quickly -- in a few seconds at most for reasonably interactive work, in a few minutes to, perhaps, a few days for batch -- then it's very, very very rarely done. It it occurs in less than about 1/10 second, there's not much incentive to try to speed it up, and inefficiencies that bump process time up to even a few seconds tend to creep in. That despite the fact that there are psychologically and outcomes-measurable differences between interfaces with even 1/10s vs. 1/1000s delays or responses. The Jevons Paradox plays into this, balancing against Gresham's. Stuff that's cheap (clock time) happens, stuff that's non-discernable (under perceptible / outcomes limits) tends not to get constrained.

skizm 9y ago

Software engineers optimize for human scale time.

Chaebixi 9y ago
I kinda feel that UI developers should work with crappy, old PCs. Then they could optimize to the point where things are barely usable to them, but then they'd be snappy for everyone else.
- SirZimzim 9y ago
  Luckily Google Chrome has added device emulation recently for slower devices and network conditions. Hopefully tooling like that will make it in many developers Workflows.

jayd16 9y ago

We're usually not computationally bound. Often its disk or network I/O and that basically means tasks are content bound. We tune for maximum content in the acceptable human scale time. The moment we take less than a second to load something it means we can find more things to load.