20 ms·

I just kind of figured we'd stop having UI lag by now. I work on a 24 core workstation with 64GB of RAM and things lag all the time. Not slow to complete, lik

by habosa 8y ago

I just kind of figured we'd stop having UI lag by now. I work on a 24 core workstation with 64GB of RAM and things lag all the time. Not slow to complete, like jittery key entry and non-responses. Haven't we figured out thread prioritization by now? Can't we make sure something draws 60 times per second while things are going on in the background? My Android Studio build should be totally isolated from my inbox. I know this is a bit orthogonal to the article and that I'm certainly not well informed about Operating Systems these days, I'd love to get schooled in the comments.

daeken 8y ago
I have a similar workstation (though 12 core I think) and recently I've thought about just running entirely separate VMs, each with dedicated cores and RAM. I'm sick of random slowdowns like you mentioned.
- scns 8y ago
  I think qubes os could be a good fit for that workflow
brucedawson 8y ago
I'll go into more details in part two, but part of the problem would have reliably disappeared if I had been running a single-core CPU. Locks are hard.
- raattgift 8y ago
  > Locks are hard. Yes, especially when the OS does nothing to help a backing-off contender acquire a resource that is greedily dropped and contended by another thread. > I'll go into more details in part two Great! In anticipation of that, I have a couple questions: > but part of the problem would have reliably disappeared if I had been running a single-core CPU Single-core or single-thread? Does the atomic instruction switch to the other HyperThread generally? Do you see the same symptoms if you have a sufficient number of other unrelated CPU-intensive threads trying to run that the OS will want to deschedule the aggressive contender thread(s) from time to time? The ways to deal with this that come to mind are the aggressive contender thread(s) sleeping from time to time, or yielding in hopes the decision about waking up the thread recovers some fairness lost by the decision about which lock waiter win. Perhaps one could just put the lock's cache line on as equal a NUMA footing as it can (a flush, for instance) so the aggressive contender has a chance to lose a race. However, having to reason about cache coherency protocols (differing from vendor to vendor and even same-vendor model to model) seems like a huge headache that anyone would want to avoid if possible. Is a fix described in the long crbug discussion?
  - brucedawson 8y ago
    On a single-core/single-thread Windows system the problem would be avoided because when the waiting thread is signaled it gets a priority boost. With just a single core this boost means that it gets to run instead of the other thread. With multiple cores it gets to run as well as the other thread. Making the locks fair or occasionally fair would solve this problem, but perhaps cause others. I think that an appropriate CPU-saturating background task might have made my machine more responsive, which is deliciously weird.
speeder 8y ago
I have a core i5 with 32gb of factory oced ddr3 ram that is faster than many ddr4 ones My machine randomly has input delay or mouse even after new install...
tomc1985 8y ago
Didn't BeOS get this right? I too wonder why UI threads are still so obnoxiously tied to... everything else. Put UI in the fast lane! (At least until some bug tries to make a bajillion calls a second) Then I remembered how much more complicated it is to write proper multithreaded GUI code :P
- rangibaby 8y ago
  I remember Safari in the iPhone 3G would ALWAYS scroll even if it meant showing a checkerboard pattern while the page rendering caught up.
  - tomc1985 8y ago
    Safari did that for a while too
- speedplane 8y ago
  I remember old Mac OS 9. If you started a print job, and held down the mouse holding down a click, the printer would just stop. The entire system wasn't properly multi-threaded.
  - dasmoth 8y ago
    That’s something that I remember people in my circle joking about at the time, but in retrospect maybe the joke was on us. User input should always be absolute top priority, and if that means something else has to stop then so be it. (Although with 24 cores...)
    - speedplane 8y ago
      To your point, I also remember working with early windows systems and when the network went down for a moment, the mouse and screen would freeze. Given the two options, Most would probably take the Mac.
rambojazz 8y ago
Could this be because many programs are still single threaded (eg. javascript on the browser), but multi-cores workstations usually have a lower performance per single-thread?
- askmike 8y ago
  The article states that this problem actually came from service workers (and how MS allocates pages so V8 can spawn this them). Service workers are specifically designed to circumvent issues regarding UI lag from a single thread..
fulafel 8y ago
The "C++, threads and locks" programming model is inherently performance-unpredictable, since a high priority thread can't interrupt a low priority thread holding a lock to a contended resource. The field has made progress in "figuring out" the general problem in the form of other programming models but that stuff is not close to gaining popularity on the desktop. Things like STM, lockless peristent data structures, and shared-nothing concurrency. There are also attempts to make C++ & locks real-time friendly, but the programming model is already prohibitively hard wrt correctness, and the added complexity explosion from handling aborted locks would make it completely unmanageable.
- devxpy 8y ago
  Yeah,the only sane way to do parallelism is message passing. (preferably using zmq)
- speedplane 8y ago
  The C++ (and many other languages) model of threads and locks have clearly proven overly complex and bug prone. It's incredibly easy to write software with race conditions and incredibly difficult to debug. The best advance in recent years, is recognizing that most latency is due to network access, and using single-threaded, but asynchronous models like in javascript. It definitely does not remove race conditions, but makes them much easier to understand and debug.
bartread 8y ago
This isn't meant to be an especially religious comment, but I regularly switch back and forth between OSX and Windows 10 and wanted to make mention of the differences. I also use Ubuntu fairly regularly but only over ssh so I'll discount it from this comparison. Both OSX and Windows 10 do suffer from UI lag but, in my experience, it is far worse on Windows 10 to the point where I have come to absolutely detest Windows 10. It's particularly bad on the login/unlock screen, which often takes multiple seconds to even appear when you get back to your machine - frustrating when you're in a hurry. With that said, some of it is certainly application specifically. Office 365 Outlook, for example, is particularly egregious in this regard: switching between windows, or between mail and calendar is awful. Microsoft Teams also regularly hangs for multiple seconds when switching between teams, or between chats. Extremely aggravating.
- coding123 8y ago
  Just curious, is that windows machine possibly not on an SSD? My windows 10 rig opens a profile faster than my MacBook
  - jjeaff 8y ago
    Ya, I just built a new windows 10 rig. I went for single core speed over more cores (i7 8086k) for the very reason of stamping out any UI lag. It's buttery smooth and I get no noticeable lag. Exactly 7 seconds from power button to login screen on a cold boot too.
  - bartread 8y ago
    A fair question, but both SSDs so it's definitely not that. Since we're on hardware differences though the Macbook Pro is 3 years old and has a quad-core i7, whereas the Windows 10 laptop is 1 year old and has a dual-core i7. I'm not in love with having only dual cores but I don't think that's the issue either.
  - awiesenhofer 8y ago
    its not about opening the profile its about getting to enter your password from a locked screen - i love my w10 machine and its quite snappy when logged in but every unlock has this half-second or so lag until it lets me enter my password - i suspect the animation of the appearing login-form but who knows...
devxpy 8y ago
Are you using gnome? And a slow hard disk is often the bottleneck, in case of windows.
thoughtfunction 8y ago
Almost all UI programing is single threaded. If the main thread is blocked for more than 10-16ms, then frames start dropping and the UI is unresponsive for that time. Add locks and you add many more causes for the main thread to be blocked beyond pure computation.
- speedplane 8y ago
  Not just UI programming, almost all programming is single threaded. What programmer wants to deal with threads, really? They only do because they need to get more performance out of a chip. And that leads us to the real problem. Chips are not advancing at the rate they should. Additional performance gains come from adding multiple chips to the same die, not making the chips faster. This forces programmers to think about parallelism, which makes everything harder. In the mid-90s, chips were improving so faster that you wouldn't need to consider special tricks, you could just wait 3 or 4 months and a chip would come out that handled your application. Now single processor performance is basically at a standstill and it's up to the software developer to spread work in parallel to make things faster.
  - fipple 8y ago
    > Chips are not advancing at the rate they should. A weird interpretation of a singular event in the history of technology. No wheel maker complained because wood wasn’t getting twice as strong every 18 months.
    - speedplane 8y ago
      Moore’s law and folks like Ray Kurzweil have for decades been driving the point that this isn’t a single event, but a trend that will continue indefinitely. I don’t buy it myself, but it’s now become conventional wisdom. We’ve been taught for decades that chips will double in performance every 18 months (I know Moore said transistor count, not performance). It’s now turning out to be untrue. We think about the singularity all the time, but haven’t properly considered what will happen if technology improvements stall.
  - 8y ago
oso2k 8y ago
More cores, more RAM, more cache, more concurrency will help create higher total throughput but usually also mean higher latency because of increased context switching, natural need for more resource locks, increased delay in searching/reading larger stores like cache & RAM, and, higher latency penalties when there are cache misses and/or applications that require write-through policies. Things like faster clocks (which is why we now have dynamic, turbo clocks, aka Intel Turbo Boost), lock-free schedulers, and O(1) (constant-time) schedulers. However, notice that we have few CPU SKUs that go above 4GHz or 5GHz? Why don't we have 10GHz, 25GHz or 50GHz CPUs? It's because silly things like heat, cross-talk, speed of light, and physics at nano scale get in the way. Higher clocks would improve latency. Also, applications can improve their latency if they're written to take advantage of multiple cores, their workloads are inherently parallel or mostly parallel, manage their own thread/process scheduling, and use lock-free work stealing schedulers. CPU OEMs have proven developers prefer the manage all this complexity AND also calculate their ILP (instruction level parallelism) for them. Intel's Itanium failed because it required explicitly declared ILP (from compiler and/or developer) which can be tricky especially when most CS literature/education materials, programming languages, software constrains itself to using simplistic single thread of execution mental/computer models.
- speedplane 8y ago
  All the concerns in your comment are real, but they can be boiled down to one simple fact: Moore's law is dead. Our processors are now not advancing nearly as quickly as people can create solutions for them. Case in point - Virtual Reality, which has technically been on the market for years, but out of reach for most users. If processors are not improving, everything else slows down. Graphics, games, and the internet ten years from now will look pretty much the same as it does today.
  - CodeWriter23 8y ago
    If we had an operating system where every system call used an async calling interface, the type of spinlock latency observed in this article would be greatly reduced. It wouldn’t bring Moore’s Law back but it would make the most of what CPU resource we have.
ndesaulniers 8y ago
Priority inversion.
zaarn 8y ago
It's simple: Bad Engineering is cheaper. Just today on Patreon, I was going through a creators posts. After about 100 posts or so the page was barely usable. Animations took minutes to complete, loading more posts took 30 seconds and Firefox (Chrome quit after 80 posts when Linux' OOM decided that the fun was over) was struggling to repaint the view port, lots of white areas. At the end other applications were severely lagging too both because Patreon's webshit was pulling 80% of all cores when doing nothing on the page and the Linux kernel was shoveling everything into ssd swap like crazy. Animations didn't work at all (likely if I waited 60 minutes it would have shown the first frames) and clicking on links to open in a new tab took about 15 seconds until the JS behind the scenes completed. It's simply shitty design that there is no obvious way to say "show all posts from January 2016" and jump back month by month. Or atleast UNLOADING posts I've long scrolled past. I have 8 Cores and 32 GB of RAM at my disposal, a website has no excuse to have that much of a shit performance. Especially when it's a platform where lots of money flows. But hey, it's cheaper this way. --- The issue is not thread priorization. Or processes. Your mail app and android studio are both competing for resources and either android studio will lag because the mail app is running on all the CPUs or the other way round. The OS doesn't have a way to tell which is more important and trusting applications to tell is not really reliable (devs will just say "I'm the most important"). A real partial issue is that a lot of modern apps are not engineered to save resources. They just take what they need and the user better provide enough CPU and RAM to do it. There is no sense in self-limiting in a lot of modern apps. Frontend devs should wake up to the reality that they aren't running on the only instance of the chrome browser with only one tab open. There is other apps around too. There are other browsers around too. Sharing resources gives the user a better experience than just taking them all for yourself.
- mikekchar 8y ago
  What's weird is, I have 8G (edit: it did say megs -- of course I have more than that :-) ) of memory and no swap. Never OOMed this machine in 3 years of development work. My colleagues run out of memory constantly. Sometimes I wonder if there isn't some other problem that isn't obvious. I run a very tight ship -- nothing runs on my machine that I don't know about. I'm going to go have a look at the Patreon page and see what happens... Edit: Apart from being able to confirm the less-than-stellar performance problems, I had no trouble with memory at all. Chromium hovered at about 2G of memory. It fairly aggressively garbage collected as I browsed different sections and different creators.
AJRF 8y ago
I've gone from Windows -> macOS -> Fedora running i3wm. Totally agree that Windows is the worst of the bunch and its still a huge problem on macOS. On Fedora+i3wm, when my desktop opens from the login it is "immediately" ready for input. I've tried to ask some people to compare between macOS and my laptop and they say they don't notice a difference, so I think people are conditioned to waiting with these little unconscious pauses they don't notice. I wonder is there a way to do accurate and meaningful timings for responsiveness in these situations.
fouc 8y ago
We probably need to be using a real time OS like QNX or other.
jakeogh 8y ago
I got annoyed enough to auto -STOP every tab but the one in the foreground (using surf [with or without tabbed] and a bunch of X glue), coupled with JS disabled by default is very nice. It's got bugs, but I'll add the X plumbing to my version of surf sometime soon: https://github.com/jakeogh/glide https://github.com/jakeogh/glide
- yjftsjthsd-h 8y ago
  Thanks, this looks really nice. How are you sending SIGSTOP to background tabs? (assuming its not built in to glide; I didn't see it mentioned in the README)
  - jakeogh 8y ago
    I should have elaborated more on the "it's got bugs", it's been awhile since I worked on it, I just looked through the bash plumbing I was using and now I remember what needs to be done, the big issue is copy and paste, since the owner of the current selection needs to be woken up when you paste. This is so ugly I hesitated to post it, but here: https://github.com/jakeogh/glidestop https://github.com/jakeogh/glidestop In the case of glide, having tabbed take care of all of that would be much easier, or even better it would be integrated directly into a "tabbed like" process that acts more like a windowmanager and does not necessary have "tabs". I'm thinking of a more generalized version to tabbed with a --notabs switch or something.
feintruled 8y ago
I remember back in the Amiga days, the processes for the GUI would be totally separate from the program logic. Add the pre-emptive multitasking and you would have GUI elements that would respond instantly always, even when the rest of your program was hung! Of course, the button callbacks wouldn't fire, but the button would appear to press, you could move windows, etc. Did a lot to reduce the perception of lag, whilst obviously introducing quite a few quirks of its own.
- renox 8y ago
  The Amiga didn't have multiple address space so that's cheating.. I've never used an Amiga but BeOS was really much more responsive than either Linux or Windows but that was before SSD and multiple cores were available so maybe now the difference would be much less noticeable.. There is Haiku (in alpha or beta) but AFAIK it hasn't any native modern web browser..
  - waddlesplash 8y ago
    Depends on what you mean by "modern", I guess? https://www.haiku-os.org/files/get-haiku/webkit.png https://www.haiku-os.org/files/get-haiku/webkit.png
    - renox 8y ago
      WebKit is modern yes but it isn't really "BeOS native"
      - waddlesplash 8y ago
        It uses native APIs for drawing, text layout, media playback, and HTTP. I don't know how much more native you want...
        renox 8y ago
        WebKit wasn't designed for BeOS so I'm not sure that using native API to draw is enough to make it a real native BeOS..
larschdk 8y ago
I don't think thread prioritization is the cause of the apparent lag. We've gone from mostly synchronous systems to highly asynchronous systems. Typing on a keyboard used to be a hardware interrupt that would also print instantly on the screen. Now it's a serial bus being polled every few milliseconds, followed by a buffer copy between kernel and user space, with a/several memory allocation and transfer of ownership to a GUI thread, that when scheduled may draw the character on the screen using a DOM that needs to be recalculated which requires accessing the memory allocator in the OS which is currently locked by your Android build.
JTbane 8y ago
>I just kind of figured we'd stop having UI lag by now Software will always expand in resource usage as computing becomes faster. This ought to be an adage that more programmers should think about.
Bjartr 8y ago
You might find this study of computer latency across 40 years of hardware interesting http://danluu.com/input-lag/ http://danluu.com/input-lag/

by habosa 8y ago

daeken 8y ago

I have a similar workstation (though 12 core I think) and recently I've thought about just running entirely separate VMs, each with dedicated cores and RAM. I'm sick of random slowdowns like you mentioned.

scns 8y ago
I think qubes os could be a good fit for that workflow

brucedawson 8y ago

I'll go into more details in part two, but part of the problem would have reliably disappeared if I had been running a single-core CPU. Locks are hard.

raattgift 8y ago
> Locks are hard. Yes, especially when the OS does nothing to help a backing-off contender acquire a resource that is greedily dropped and contended by another thread. > I'll go into more details in part two Great! In anticipation of that, I have a couple questions: > but part of the problem would have reliably disappeared if I had been running a single-core CPU Single-core or single-thread? Does the atomic instruction switch to the other HyperThread generally? Do you see the same symptoms if you have a sufficient number of other unrelated CPU-intensive threads trying to run that the OS will want to deschedule the aggressive contender thread(s) from time to time? The ways to deal with this that come to mind are the aggressive contender thread(s) sleeping from time to time, or yielding in hopes the decision about waking up the thread recovers some fairness lost by the decision about which lock waiter win. Perhaps one could just put the lock's cache line on as equal a NUMA footing as it can (a flush, for instance) so the aggressive contender has a chance to lose a race. However, having to reason about cache coherency protocols (differing from vendor to vendor and even same-vendor model to model) seems like a huge headache that anyone would want to avoid if possible. Is a fix described in the long crbug discussion?
- brucedawson 8y ago
  On a single-core/single-thread Windows system the problem would be avoided because when the waiting thread is signaled it gets a priority boost. With just a single core this boost means that it gets to run instead of the other thread. With multiple cores it gets to run as well as the other thread. Making the locks fair or occasionally fair would solve this problem, but perhaps cause others. I think that an appropriate CPU-saturating background task might have made my machine more responsive, which is deliciously weird.

speeder 8y ago

I have a core i5 with 32gb of factory oced ddr3 ram that is faster than many ddr4 ones My machine randomly has input delay or mouse even after new install...

tomc1985 8y ago

Didn't BeOS get this right? I too wonder why UI threads are still so obnoxiously tied to... everything else. Put UI in the fast lane! (At least until some bug tries to make a bajillion calls a second) Then I remembered how much more complicated it is to write proper multithreaded GUI code :P

rangibaby 8y ago
I remember Safari in the iPhone 3G would ALWAYS scroll even if it meant showing a checkerboard pattern while the page rendering caught up.
- tomc1985 8y ago
  Safari did that for a while too
speedplane 8y ago
I remember old Mac OS 9. If you started a print job, and held down the mouse holding down a click, the printer would just stop. The entire system wasn't properly multi-threaded.
- dasmoth 8y ago
  That’s something that I remember people in my circle joking about at the time, but in retrospect maybe the joke was on us. User input should always be absolute top priority, and if that means something else has to stop then so be it. (Although with 24 cores...)
  - speedplane 8y ago
    To your point, I also remember working with early windows systems and when the network went down for a moment, the mouse and screen would freeze. Given the two options, Most would probably take the Mac.

rambojazz 8y ago

Could this be because many programs are still single threaded (eg. javascript on the browser), but multi-cores workstations usually have a lower performance per single-thread?

askmike 8y ago
The article states that this problem actually came from service workers (and how MS allocates pages so V8 can spawn this them). Service workers are specifically designed to circumvent issues regarding UI lag from a single thread..

fulafel 8y ago

The "C++, threads and locks" programming model is inherently performance-unpredictable, since a high priority thread can't interrupt a low priority thread holding a lock to a contended resource. The field has made progress in "figuring out" the general problem in the form of other programming models but that stuff is not close to gaining popularity on the desktop. Things like STM, lockless peristent data structures, and shared-nothing concurrency. There are also attempts to make C++ & locks real-time friendly, but the programming model is already prohibitively hard wrt correctness, and the added complexity explosion from handling aborted locks would make it completely unmanageable.

devxpy 8y ago
Yeah,the only sane way to do parallelism is message passing. (preferably using zmq)
speedplane 8y ago
The C++ (and many other languages) model of threads and locks have clearly proven overly complex and bug prone. It's incredibly easy to write software with race conditions and incredibly difficult to debug. The best advance in recent years, is recognizing that most latency is due to network access, and using single-threaded, but asynchronous models like in javascript. It definitely does not remove race conditions, but makes them much easier to understand and debug.

bartread 8y ago

This isn't meant to be an especially religious comment, but I regularly switch back and forth between OSX and Windows 10 and wanted to make mention of the differences. I also use Ubuntu fairly regularly but only over ssh so I'll discount it from this comparison. Both OSX and Windows 10 do suffer from UI lag but, in my experience, it is far worse on Windows 10 to the point where I have come to absolutely detest Windows 10. It's particularly bad on the login/unlock screen, which often takes multiple seconds to even appear when you get back to your machine - frustrating when you're in a hurry. With that said, some of it is certainly application specifically. Office 365 Outlook, for example, is particularly egregious in this regard: switching between windows, or between mail and calendar is awful. Microsoft Teams also regularly hangs for multiple seconds when switching between teams, or between chats. Extremely aggravating.

coding123 8y ago
Just curious, is that windows machine possibly not on an SSD? My windows 10 rig opens a profile faster than my MacBook
- jjeaff 8y ago
  Ya, I just built a new windows 10 rig. I went for single core speed over more cores (i7 8086k) for the very reason of stamping out any UI lag. It's buttery smooth and I get no noticeable lag. Exactly 7 seconds from power button to login screen on a cold boot too.
- bartread 8y ago
  A fair question, but both SSDs so it's definitely not that. Since we're on hardware differences though the Macbook Pro is 3 years old and has a quad-core i7, whereas the Windows 10 laptop is 1 year old and has a dual-core i7. I'm not in love with having only dual cores but I don't think that's the issue either.
- awiesenhofer 8y ago
  its not about opening the profile its about getting to enter your password from a locked screen - i love my w10 machine and its quite snappy when logged in but every unlock has this half-second or so lag until it lets me enter my password - i suspect the animation of the appearing login-form but who knows...

devxpy 8y ago

Are you using gnome? And a slow hard disk is often the bottleneck, in case of windows.

thoughtfunction 8y ago

Almost all UI programing is single threaded. If the main thread is blocked for more than 10-16ms, then frames start dropping and the UI is unresponsive for that time. Add locks and you add many more causes for the main thread to be blocked beyond pure computation.

speedplane 8y ago
Not just UI programming, almost all programming is single threaded. What programmer wants to deal with threads, really? They only do because they need to get more performance out of a chip. And that leads us to the real problem. Chips are not advancing at the rate they should. Additional performance gains come from adding multiple chips to the same die, not making the chips faster. This forces programmers to think about parallelism, which makes everything harder. In the mid-90s, chips were improving so faster that you wouldn't need to consider special tricks, you could just wait 3 or 4 months and a chip would come out that handled your application. Now single processor performance is basically at a standstill and it's up to the software developer to spread work in parallel to make things faster.
- fipple 8y ago
  > Chips are not advancing at the rate they should. A weird interpretation of a singular event in the history of technology. No wheel maker complained because wood wasn’t getting twice as strong every 18 months.
  - speedplane 8y ago
    Moore’s law and folks like Ray Kurzweil have for decades been driving the point that this isn’t a single event, but a trend that will continue indefinitely. I don’t buy it myself, but it’s now become conventional wisdom. We’ve been taught for decades that chips will double in performance every 18 months (I know Moore said transistor count, not performance). It’s now turning out to be untrue. We think about the singularity all the time, but haven’t properly considered what will happen if technology improvements stall.
- 8y ago

oso2k 8y ago

More cores, more RAM, more cache, more concurrency will help create higher total throughput but usually also mean higher latency because of increased context switching, natural need for more resource locks, increased delay in searching/reading larger stores like cache & RAM, and, higher latency penalties when there are cache misses and/or applications that require write-through policies. Things like faster clocks (which is why we now have dynamic, turbo clocks, aka Intel Turbo Boost), lock-free schedulers, and O(1) (constant-time) schedulers. However, notice that we have few CPU SKUs that go above 4GHz or 5GHz? Why don't we have 10GHz, 25GHz or 50GHz CPUs? It's because silly things like heat, cross-talk, speed of light, and physics at nano scale get in the way. Higher clocks would improve latency. Also, applications can improve their latency if they're written to take advantage of multiple cores, their workloads are inherently parallel or mostly parallel, manage their own thread/process scheduling, and use lock-free work stealing schedulers. CPU OEMs have proven developers prefer the manage all this complexity AND also calculate their ILP (instruction level parallelism) for them. Intel's Itanium failed because it required explicitly declared ILP (from compiler and/or developer) which can be tricky especially when most CS literature/education materials, programming languages, software constrains itself to using simplistic single thread of execution mental/computer models.

speedplane 8y ago
All the concerns in your comment are real, but they can be boiled down to one simple fact: Moore's law is dead. Our processors are now not advancing nearly as quickly as people can create solutions for them. Case in point - Virtual Reality, which has technically been on the market for years, but out of reach for most users. If processors are not improving, everything else slows down. Graphics, games, and the internet ten years from now will look pretty much the same as it does today.
- CodeWriter23 8y ago
  If we had an operating system where every system call used an async calling interface, the type of spinlock latency observed in this article would be greatly reduced. It wouldn’t bring Moore’s Law back but it would make the most of what CPU resource we have.

ndesaulniers 8y ago

Priority inversion.

zaarn 8y ago

It's simple: Bad Engineering is cheaper. Just today on Patreon, I was going through a creators posts. After about 100 posts or so the page was barely usable. Animations took minutes to complete, loading more posts took 30 seconds and Firefox (Chrome quit after 80 posts when Linux' OOM decided that the fun was over) was struggling to repaint the view port, lots of white areas. At the end other applications were severely lagging too both because Patreon's webshit was pulling 80% of all cores when doing nothing on the page and the Linux kernel was shoveling everything into ssd swap like crazy. Animations didn't work at all (likely if I waited 60 minutes it would have shown the first frames) and clicking on links to open in a new tab took about 15 seconds until the JS behind the scenes completed. It's simply shitty design that there is no obvious way to say "show all posts from January 2016" and jump back month by month. Or atleast UNLOADING posts I've long scrolled past. I have 8 Cores and 32 GB of RAM at my disposal, a website has no excuse to have that much of a shit performance. Especially when it's a platform where lots of money flows. But hey, it's cheaper this way. --- The issue is not thread priorization. Or processes. Your mail app and android studio are both competing for resources and either android studio will lag because the mail app is running on all the CPUs or the other way round. The OS doesn't have a way to tell which is more important and trusting applications to tell is not really reliable (devs will just say "I'm the most important"). A real partial issue is that a lot of modern apps are not engineered to save resources. They just take what they need and the user better provide enough CPU and RAM to do it. There is no sense in self-limiting in a lot of modern apps. Frontend devs should wake up to the reality that they aren't running on the only instance of the chrome browser with only one tab open. There is other apps around too. There are other browsers around too. Sharing resources gives the user a better experience than just taking them all for yourself.

mikekchar 8y ago
What's weird is, I have 8G (edit: it did say megs -- of course I have more than that :-) ) of memory and no swap. Never OOMed this machine in 3 years of development work. My colleagues run out of memory constantly. Sometimes I wonder if there isn't some other problem that isn't obvious. I run a very tight ship -- nothing runs on my machine that I don't know about. I'm going to go have a look at the Patreon page and see what happens... Edit: Apart from being able to confirm the less-than-stellar performance problems, I had no trouble with memory at all. Chromium hovered at about 2G of memory. It fairly aggressively garbage collected as I browsed different sections and different creators.

AJRF 8y ago

I've gone from Windows -> macOS -> Fedora running i3wm. Totally agree that Windows is the worst of the bunch and its still a huge problem on macOS. On Fedora+i3wm, when my desktop opens from the login it is "immediately" ready for input. I've tried to ask some people to compare between macOS and my laptop and they say they don't notice a difference, so I think people are conditioned to waiting with these little unconscious pauses they don't notice. I wonder is there a way to do accurate and meaningful timings for responsiveness in these situations.

fouc 8y ago

We probably need to be using a real time OS like QNX or other.

jakeogh 8y ago

I got annoyed enough to auto -STOP every tab but the one in the foreground (using surf [with or without tabbed] and a bunch of X glue), coupled with JS disabled by default is very nice. It's got bugs, but I'll add the X plumbing to my version of surf sometime soon: https://github.com/jakeogh/glide https://github.com/jakeogh/glide

yjftsjthsd-h 8y ago
Thanks, this looks really nice. How are you sending SIGSTOP to background tabs? (assuming its not built in to glide; I didn't see it mentioned in the README)
- jakeogh 8y ago
  I should have elaborated more on the "it's got bugs", it's been awhile since I worked on it, I just looked through the bash plumbing I was using and now I remember what needs to be done, the big issue is copy and paste, since the owner of the current selection needs to be woken up when you paste. This is so ugly I hesitated to post it, but here: https://github.com/jakeogh/glidestop https://github.com/jakeogh/glidestop In the case of glide, having tabbed take care of all of that would be much easier, or even better it would be integrated directly into a "tabbed like" process that acts more like a windowmanager and does not necessary have "tabs". I'm thinking of a more generalized version to tabbed with a --notabs switch or something.

feintruled 8y ago

I remember back in the Amiga days, the processes for the GUI would be totally separate from the program logic. Add the pre-emptive multitasking and you would have GUI elements that would respond instantly always, even when the rest of your program was hung! Of course, the button callbacks wouldn't fire, but the button would appear to press, you could move windows, etc. Did a lot to reduce the perception of lag, whilst obviously introducing quite a few quirks of its own.

renox 8y ago
The Amiga didn't have multiple address space so that's cheating.. I've never used an Amiga but BeOS was really much more responsive than either Linux or Windows but that was before SSD and multiple cores were available so maybe now the difference would be much less noticeable.. There is Haiku (in alpha or beta) but AFAIK it hasn't any native modern web browser..
- waddlesplash 8y ago
  Depends on what you mean by "modern", I guess? https://www.haiku-os.org/files/get-haiku/webkit.png https://www.haiku-os.org/files/get-haiku/webkit.png
  - renox 8y ago
    WebKit is modern yes but it isn't really "BeOS native"
    - waddlesplash 8y ago
      It uses native APIs for drawing, text layout, media playback, and HTTP. I don't know how much more native you want...
      - renox 8y ago
        WebKit wasn't designed for BeOS so I'm not sure that using native API to draw is enough to make it a real native BeOS..

larschdk 8y ago

I don't think thread prioritization is the cause of the apparent lag. We've gone from mostly synchronous systems to highly asynchronous systems. Typing on a keyboard used to be a hardware interrupt that would also print instantly on the screen. Now it's a serial bus being polled every few milliseconds, followed by a buffer copy between kernel and user space, with a/several memory allocation and transfer of ownership to a GUI thread, that when scheduled may draw the character on the screen using a DOM that needs to be recalculated which requires accessing the memory allocator in the OS which is currently locked by your Android build.

JTbane 8y ago

>I just kind of figured we'd stop having UI lag by now Software will always expand in resource usage as computing becomes faster. This ought to be an adage that more programmers should think about.

Bjartr 8y ago

You might find this study of computer latency across 40 years of hardware interesting http://danluu.com/input-lag/ http://danluu.com/input-lag/