Basically, one byte of CFG memory "controls access" to 64-bytes of executable memory - indicating which addresses are valid indirect branch targets. With appropriate compiler and OS support this can help stop some exploits.
Unfortunately it quickly gets really complicated so a bit of hand waving is necessary.
Every other paragraph the ad box tries to run a full screen video with unmuted audio by default. I got headache some half way thru article and then gave up reading. From authors work, it doesnt seem this particular blogger needs my two cents from ads he runs to live a decent life. Its sad how the state of internet looks like these days ;(
You are a serious author and your articles are of top quality. Don't you think you should invest some time and effort in self-publishing? (Read: run far away from WordPress.)
I too hate side activities when I'm in the zone but you have to admit this situation can eat away at your audience. :(
Seriously. Adblock is the way you have to fight back, to change the economics of the internet. Install it, use it indiscriminately, and make sure you tell others to use it.
My company makes a decent chunk of money from ads btw. Not because we can't make money another, better and cleaner way, but because it makes no sense to leave money off the table when the adblock rates are so low.
He cant say 350MB for just one tab is bloatware while he is partially responsible for it. Sinclairs "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" comes to mind. Poor Bruce herding all those Google javascript cats.
I ended up going to Thunderbird for my main email addresses (work & personal), with Rainmail for quasi-disposable addresses on my various domains. Works much better than Gmail did towards the end of my years using Gmail.
I have to use Thunderbird for work and I wish it was 1% as good as Gmail. The search sucks, it's slow to receive mail, it crashes quite often. Either your Gmail is profoundly broken or you have a magic Thunderbird. In case the latter is true: do you have any tips to optimise Thunderbird?
Have been running Thunderbird for G-Apps based work email for over a year (Fedora 26,27). Using the Provider for Google Calendar extension works well for integrating calendar into Thunderbird.
Other than fighting with the calendar occasionally (sometimes needing to force a manual sync to see coworkers' events), Gmail in Thunderbird has been pretty smooth. I have not noticed slow search, slow mail receipt, or application crashes. In fact, the search is often too good, in that after running it it matches hundreds of more emails than I usually expect. I usually stick with the quick filter which is a bit less flexible, but generally returns more useful results.
Another advantage, on Linux at least, is that if you copy your ~/.thunderbird folder to another machine, all accounts, GUI layouts, settings, search results, tabs, etc move over flawlessly. I think you just have to re-sign in for Google accounts on the new machine and you are good to go.
Thunderbird is quite a piece of crap. Apart from the core, everything else is written in javascript and thus it is a single-core web application.
I have decided to just leave it be, and let it hog my computer, because it interface decently with google calendar.
That being said, I can definitely vouch for clients like Claws Mail (a bit ugly, but does its job) and Evolution (super fast, but it's written in C#/Mono)
I would check that Google isn't ratelimiting you, and I would also check that your hard drive/SSD and RAM aren't dying. I've experienced issues like what you describe, but the first time was caused by a dying hard disk, and the 2nd by Google limiting the number of IMAP connections to a hilariously low number.
I usually append /h/ to the URL (/mail/h/) and get a HTML version. It can work even without JS and it has classic design with small rows that works well on my small screen. No Material Design and no huge elements with large offsets.
Oh wow that is a stark contrast. yahoo.co.uk, yahoo.co.in, yahoo.co.id, etc. are all incredibly low-density as well. I have always loved the Japanese aesthetic, I wonder if any other cultures have a similar preference for websites.
Sounds like me. On the couch or walking around I'm at 10-12 inches away. I wonder--do people who don't prefer high information density hold their devices farther away?
I hope you have noticed that in GMail you can swtich between different "density" modes. In your Inbox, click on the cogwheel on the right-hand top corner and select the second option "Display density". The "Compact" setting is actually rather dense. Although, it mostly affects the density of rows (conversations) in your inbox and does not scale e.g. the search box input field above.
I just tried that, and noticed promotions in the inbox, the non-HTML version separated the "primary" from the "promotions". Are they merging them to keep HTML version annoying?
I always assumed the behaviour and categorization was in their backend. I think its weird that the view (HTML vs javascript) is not decoupled from the model?
While that is possible it would make no sense. Why spend time refactoring code to improve a legacy UI for old browsers almost nobody is using? Legacy UI doesn't know anything about categorization because it was added later.
Actually Gmail's approach is sane. They just keep old UI working as it used to many years ago although the backend could have changed completely.
what exactly are they supposed to do in the backend?
they probably have an api in which you can limit the results by category. As the old interface doesn't have any limiter implemented, they're getting all the results back.
you can also disable categories in the newer interface and the effect would be the same (everything in the inbox)
yeah inbox basically causes chrome to beachball on OS X. They control the browser, the webapp and have still managed to put together an experience like this.
And their latest interface broke middle-click to open an email in a new tab. One the major advantage of using Gmail in a browser vs in the app, gone. Oddly ctrl-click still works.
I'm confused about your suggestion. I work on the Chrome web browser on the Windows platform. If we want to allocate memory we, ultimately, need to call VirtualAlloc.
I could work on Chrome for Linux, but then this bug on Windows might never get found or fixed. I am satisfied with my choices, despite the occasional glitches.
I modify the source code of the Chrome browser in order to make the final PE files that are compiled from the aforementioned source code work more efficiently.
For what it's worth I also read it as "I use the Chrome browser on Windows to get work done" and only slowly figured out the correct interpretation as the debugging adventure got crazier and crazier.
So basically it is the problem with CFG (exploit protection) which is not ready for the cases when there are many allocations and freeing of excutable memory blocks.
Normally a freelist is a tradeoff between memory and speed, but in this case there is essentially no tradeoff. If you look at the fix you will see that we don't maintain a freelist of memory in any traditional sense. We just retain a freelist of addresses. These addresses are then used as hints for where to allocate future CodeRange objects. If that address is gone, we'll go somewhere else.
Because the memory is fully freed and reallocated this also avoids security concerns.
Side note... not related to the same root cause, but related to a similar end user problem... I've been staying in a lot of hotels lately and using a lot of very slow internet connections (not by choice, that's just what is available) and I wish Chrome had some sort of "low bandwidth" mode where it would only allow requests from your current tab, or maybe current window (easily open a new window to control which tabs could use bandwidth). That would make a big difference for us road warriors and nearly everyone when they're on vacation.
Vivaldi is based on Chrome and adds some poweruser features. For example you can hibernate tabs. In your case, right-click on the tab you want to use, select "hibernate background tabs", done. I think Chrome has a tab hibernation extension you could try as well.
I was visiting the US for a conference recently (not defcon) and I bought a T-mobile tourist sim, great idea, cost me less than 1/3rd of what my normal sim would have cost; however they had a data cap at 2Gb before they aggressively throttled you.
I was very conservative in my use (thank you hacker news for being data-light) but managed to reach the cap near the end of my stay; my girlfriend who has no concept of what is heavy and what isn’t reached the cap in less than 2 days - after which; mobile data was effectively useless for her.
I can’t imagine what life is like for those who /live/ on data caps- I feel like most web developers don’t give a shit about how much resources they use, not just in terms of CPU/Memory (“lol, it’s 2018 buy a better pc!”) but also in terms of bandwidth; which is regularly out of user control.
Vodafone CZ have this same aggressive throttling on their pre-pay monthly tariffs with the extremely annoying feature that if you run out of data it is basically impossible to top-up unless you're on wifi because they don't exclude Vodafone CZ sites or IP addresses from the throttling!
It was even worse a few years back - once you had used your data allowance you had no way whatsoever to top up at all.
Ironically, I think people on slow connections were early pioneers of using tabs for asynchronous/background page loading.
I don't remember where I learned the technique first, but when I was roaming the world and getting work done via GPRS internet, I'd open links in a new tab and let them slowly load in the background. I'd view the tab later and see the fully rendered content. It would absolutely kill this use case if the tabs would not perform their necessary AJAX calls until foregrounded.
For those not familiar with GPRS of those times, imagine a 9600-14.4 modem speed but with the latency of a satellite connection, so with almost any activity you start seeing 1 second ping times. Even when on ridiculously fast connections, I still retain the muscle memory which causes me to browse in breadth-first mode, opening articles and discussions into tabs in one sweep and then working through the tab list from left to right and closing each as I go.
Yes, that's funny. I guess for me it's when I open my browser to do something quickly, but can't do it quickly because I have to wait for all those tabs to load first.
pthreads don't guarantee fairness. futexes, the underlying locking primitive on Linux and the driver of the glibc implementation, don't either.
Futexes do support priority inheritance, so you can use process priority safely. You might drop priority after releasing a lock to ensure some other thread gets a go, and as long as you control the priority of the other contenders, that can work well.
Ironically, priorities as a way of "giving control" to another thread only work if you have a shortage of CPU cores. On my 24-core workstation I can normally run all runnable threads, regardless of priority. The implications are non-obvious.
Yes because if you have a shortage of cores, you have more threads that are blocked or in a run queue. When you have threads queued, that's when prioritizing works: you need a backlog of waiting threads in order to choose the "best" one to proceed. If threads have cores, the prioritizing loses value.
Fairness is expensive. A lock must go to the thread that is eligible to get that lock according to fairness, even if another ineligible thread is executing on a CPU and is ready to grab that lock. The ineligible thread is forced to block, and the ineligible one may have to be woken up and assigned to a CPU. Until the eligible thread is dispatched and grabs the lock, multiple cores may wastefully go through a thread switch due to hitting that lock instead of just grabbing and releasing it.
People on this website, in systems programming communities, and in articles about performance are constantly telling people not to use fair locks because they're slower, arguing that the overhead of fair locking is far too high for the problem it solves, which (they say) practically never occurs anyway on modern machines. It's hard to blame people for taking them up on it.
Those do cause a lot of problems in general, but this particular issue had a different root cause. He traces it all the way back from the symptoms in the article. Worth a read!
Interesting story in particular, but in general, performance and memory behave like any other resource that is plentiful: they get used up until things are slowish again. Like road space. Things get added on top of each other until the reduction in speed becomes visible.
Because these days, unlike in the 90's, it's no help waiting for the next Pentium processor to come out this usually results in a heavy optimisation cycle in the underlying engine. For example Firefox has advertised a speed-up several times in the last 10 years, each coming from a focused effort to rewrite or optimise the JS engine, the rendering engine, or something else. Then things accumulate again, until things are too slow.
Obviously the cycles aren't wasted as you can do things with a few lines of high-level script that would've taken months to implement in the "good old times". But this development inevitably creates bizarre flashbacks where, occasionally, you're doing something simple like typing text on today's monster machines and it takes a few seconds for the screen to catch up your typing.
When I started programming, things were roughly and more or less instant. Typing was instant. There was a very short code path from handling the interrupt to updating screen. The computers reacted more like physical apparatus. Terminals at shops, warehouses, hospitals, with text-based programs to update data were pretty much instant too. Good clerks could bang their keyboard through multiple subscreens of their program in seconds, and you were checked in, goods reserved, or patient data updated. Later, when multitasking hit the mainstream, flipping between programs was instant. (Not on Windows, though.) Things like I/O took its time, of course, but at one point there was a peak moment where a software machine had nearly as low latencies as a physical machine.
From those times things have mostly gone downhill. Yes, we have immense processing power and near endless fast memory and disk storage. You can switch between browser tabs 300MB each pretty fast but there is a constant, nagging sense of slowness present all the time. Maybe sometimes switching that tab or bringing up another program takes longer, surprisingly, or there is something simple that just doesn't happen right away. The feeling of instant responsiveness is broken into shards: you can still see a reflection of it if you happen to look at the right angle but mostly its crumbles are pointing elsewhere.
Things like BeOS tried to reach back to that, with varying but acknowledgeable success. But real success in terms of popularity and market penetration seems to come from piling up stuff until things get too slow. So I doubt we never get back to the old world of instant response in spite of processing power keeps climbing up.
As someone who remembers those times, web apps have been a terrible movement. On the other hand I'm kind of happy that I can do almost everything the same between Linux and Windows, so it's not all bad.
The move from CRT to LCD adds a few milliseconds depending on the screen. We're so used do it by now, that typing on old hardware is almost jarring. It feels almost TOO responsive.
I think the dynamic was more that that software was slow when it was written, but had a long shelf life, so after a hardware upgrade or two it seemed very fast. I remember using Norton Commander (in DOS) on an 8086 and it was laggy scrolling a directory with 50 files.
On a completely different matter... have just switched to Gmail new UI, and now my mac Mail keeps hanging on threaded emails while consuming very high CPU. Anyone else encountered this issue?
For the last couple of years it seems I'll get some issues on some Google properties if I dare use a different browser than Chrome.
For a while it was search results doing interval training on my CPU, while the page was supposedly idle.
Last it got to the point where I started troubleshooting it was calendar that acted up.
You'd think a company like Google had resources to verify the UI across at least the 3 or for biggest browsers across the three biggest desktop platforms, -but it doesn't seem like.
> You'd think a company like Google had resources to verify the UI across at least the 3 or for biggest browsers
Should they ever want to do that. I think I've read multiple discussions in the past about how Google is optimizing exclusively for Chrome while hurting the performance and compatibility with any other browser. Which is why Chrome is now basically called the new IE6.
I have also been noticing this for a while now... there was a hacker news recently about banks and other firms mining behavioral biometric data (cursor freezing, typing speed, phone angle, probably a load of other metrics likehow often you backspace and pause to reflect what you write or rewrite) for authentication purpouses...
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.
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.
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?
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.
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
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.
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.
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.
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?
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..
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.
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.
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.
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.
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...
OSX capturing and buffering the password input on the login overlay is definitely nice, compared to windows 10 dropping inputs until it is ‘ready’ for the last 2 characters of my password.
Thanks to PAM on Linux, "<hostname> login: " is printed by an entirely different set of processes than the "Password: " that follows it.
At least in Windows you aren't at a TTY that echos everything to the screen by default until PAM has hauled itself (and its umpteen libraries) off the disk (yes people still have 5400RPM HDDs :D), initialized, and put the terminal into no-echo mode...
On FreeBSD, at least, you can tinker with the sshd to switch between PAM, to get "Password: " and some other sshd-internal mechanism, which prints "<whatever login you just typed>'s password: " instead. Kind of cute.
And you can always run strace -f on whatever handles login (getty, logind, systemd, etc), drop to a TTY and login, to see all the stuff that gets loaded.
I wonder why so many are talking about SSD vs. HDD in this discussion. From my experience on Linux it doesn't really matter if you have enough RAM. Yes, booting from a SSD is faster, but once everything is loaded the system mostly works on top of the RAM (waiting for FS sync is rare).
I don't know much about the situation on Windows but at least on linux your HDD is hardly going to cause lags if you have a well configured hardware setup.
This is a blatant lie that needs to stop. I've been using linux exclusively on laptops for more than 10 years. The first 5 with the HP EliteBook like, currently with Lenovo X1 line.
On my current X1 Yoga 1st gen, I do regularly get almost 1.5x the uptime on battery compared to windows 10.
We got a batch of X1 Carbon 6th gen, which are "optimized for windows 10", where the S3 sleep state was replaced by the S0I3, which is OS-assisted. The X1 Yoga with S3 can both suspend and resume faster than windows 10, despite not having S0I3 (and has longer battery lifetime to booth).
And by fast I mean that by the time the lid is up, the OS is ready. By contrast, windows 10 seems to always shuffle for several seconds after resume, even on the carbon 6th gen.
Sure, however I really like to see what downvoters have to say. The "power management is bad" is pretty generic, isn't it?
High-end laptop lines (Dell, HP, Lenovo) have actually pretty good linux support, they are almost always intel i5+ cpus with integrated graphics which are all very similar. There is next to zero setup required in almost any case. This is known. The drivers are tried and tested. I've never experienced any random "power management issue". Suspend/resume/battery consumption/acpi is working perfectly fine. What else does qualify for "power managment"??
I've been supporting a team of 20+ people with these lines in a mixed environment, and linux since more than a decade was always basically plug and play.
There have been some quirks in some models, which generally required some tweaks in the kernel boot line, to fix issues with backlight tweaking.
Linux shines also on low-end laptops as long as you're still decent hardware. Nowdays it's still generally an intel core with integrated graphics, memory and I/O controller, so the result will be pretty much the same. Old, good laptops work even better than brand new editions of current laptop lines.
But this doesn't save you from crappy hardware, which is why this kind of argument is a non-starter for me. How well does current windows editions work on low-end crappy laptops that sell for the lowest tier? Not great. These laptops have plenty of little issues on windows as well.
Maybe better than linux, because the drivers have way more work-arounds than linux has.
Have you ever seen the internal linux quirks table to work around buggy and downright horrid hardware? That's what you get with those. If it works at all is thanks to the patience of people that put in the time to work those issues around. I frankly do not blame linux if it doesn't work well with such hardware.
My wife just got the Carbon 6th gen. There is an ACPI patch to restore S3. See https://delta-xi.net/#056. Once you've got the patched dsdt.aml, I highly recommend not following their directions, and just loading the file in grub by creating /boot/grub/custom.cfg with the line:
acpi patched_dsdt.aml
This has the advantage of not requiring any manual intervention every time your kernel is updated. The downside is that if you try to dual boot W10, it will BSOD on boot with an ACPI error. To overcome this, take the original dsdt.aml and load it in a custom (not auto-probed) menu entry for windows. You can just clone the auto-probed line, and add before the chainloader line:
I already did it, and I'm really glad I can do that since I have no use for S0I3 and I'd rather have the extended battery lifetime. However on windows there's no way to disable this sleep mode, and the laptop has consequently lasts way less when put to sleep in Windows 10, even compared to the 3rd edition (which we also have so that I can compare). How does this put linux in power management, huh?
Sadly, the 6th edition of the Carbon also runs waaay hotter than the 3rd, and I did notice occasional coil whine which was previously absent. When running normally the kernel writes regularly about thermal warnings. It seems that power and heat management is not well managed in this edition, and I see similar reports for the x1 yoga 3rd gen.
I get 6-8 hours out of my Zenbook with ArchLinux. Nowhere near the touted 9 hours of the specs, or the 12+ of the Macbook.
My system is exceptionally lean. I run bspwm and the radios are always off except WiFi. Still, I feel like I could get a lot more from this laptop. I cannot (and I certainly wouldn't want to) install Windows on dual boot to make a comparison though.
How can you compare two different laptops? I'm comparing windows and linux on the same laptop.
I personally use debian unstable with a tiling window manager (awesomewm) without a specific DE. However, I generally setup Mint for all my colleagues on the same laptop lines, and there's one colleague running Arch. We all have very similar battery lifetimes.
I am not sure if I would categorize it as a lie. I think it is unprecise and probably misleading. I have very little expertise on the subject but from my perspective, it is more like a driver/support problem. If everything is supported (e.g. some Laptops, but also Smartphones) Linux has quite a good energy footprint, but there seem to be many devices out there which do not have good support (at least out of the box).
One of the problems here is that power-draining can happen by different components. Quite popular are graphics chips, but other components can be part too. For example, a friend of mine has problems with his device waking up from s2idle during transport. That is not exactly what you would expect in such a discussion, but from a users perspective, he has less time to work with his device given his usage pattern.
For me, this isn't much of a problem as I prefer working on a desktop, but I wouldn't accuse someone of being a liar just because he had a bad experience with power consumption on Linux.
Ubuntu w/Gnome is possibly the worst offender. I actually like Gnome a lot but anytime I leave my PC on for more than a day the UI gets incredibly sluggish. Just moving windows around gets choppy and there is a annoying pause whenever I click the application launcher (happens even without the animation).
I've also found macOS provides the smoothest experience. I haven't found W10 that bad, but I haven't used it that extensively. I really only boot into Windows to play games these days.
I'm running Gnome and for the most part it has been excellent; Linux in general, though, still has a lot of trouble maintaining good UI speed at the same time as I/O throughput. I'm on Fedora, and dnf/rpm is an excellent example - even though I'm on an SSD, I can tell when something is updating in the background because stuff will lag for a little while. It feels like this has been a problem forever, and while it has definitely improved over time it's still not really possible to say, in a simple way, "I care more about interactivity than other stuff, prioritise that" (as far as I know, anyway).
> while it has definitely improved over time it's still not really possible to say, in a simple way, "I care more about interactivity than other stuff, prioritise that
that's not what mainline kernel optimizes for, you have to use liquorix or another kernel (https://liquorix.net/)
RedHat's business is servers' support: it's quite logical that the desktop they provide is as much as possible similar to the server's configuration because developers will test on their workstation..
So no, I don't expect that RedHat will do this.
I've found alt-f2 then r (ie. restarting gnome) puts it back in as good a state as a fresh boot. Sometimes my extensions won't load and this also restarts those.
You should try cinnamon. There's no accounting for taste, but after using gnome 3 for three years I tried cinnamon (version 3.6, older versions weren't good) and I found it better across the board.
Tried it with for my now very old netbooks (because 1024x600 is low-res now), kept it on my desktop machine because it's simple, out of the way and fast.
I love Cinnamon and run it on a few machines, and as soon as they sort out mixed DPI support I'll be switching back from Gnome on my main machine too. It's been a while since I've tested actually...
I've been very happy with Cinnamon for a while on Mint 18.x, and since I upgraded to Mint 19 last night, Cinnamon is even better. It's just a bunch of small improvements all over, that just make the overall experience that much better.
There's a bad memory leak in gnome-shell which was found & fixed back in March, but the Ubuntu devs still haven't merged the full fix into Bionic for some reason: https://bugs.launchpad.net/gnome-shell/+bug/1672297
Edit: Having tried in on my laptop, installing the gjs + libgjs0g version 1.53.3 debs from http://gb.archive.ubuntu.com/ubuntu/pool/main/g/gjs/ onto a bionic install seems to work fine. Worth trying if this bug is affecting you?
This is strange. I run a 6 year old PC with win 10 on it. It has 4GB of RAM. I use an SSD and an M.2 drive. The thing is snappy as hell. I face zero lags, jitters, or switching delays at all. I get the feeling that writing things to disk is causing delays.
I had a friend telling me "check out my new computer it's so snappy!" once and the darn thing was so slow it made my hands shake from the stress. Can't believe anyone on the internet telling they don't have any lag.
Every time we get snappier hardware, we just add more software bloat. I pretty much run two kinds of GUI apps (on Linux with a lightweight, tiling window manager): web browsers and terminals. My terminal apps are always very snappy, the web browsers not so much. I'm of the opinion that the computer should wait for me, not the other way around. Doesn't seem to work out that way with "modern UIs".
I run a 6 core desktop with 32G, and 1TB M2 SSD, and after an upgrade from Windows 7 to Windows 10 last Christmas, input lag in mintty terminals was dramatically worse. Even just holding down a key and observing the stream of characters at 15 per second or whatever my repeat rate is, it glitches and stutters.
A brand new laptop I bought this year can't run Windows 10, the system is basically unusable. Not a cheap laptop, either, it was one of the more expensive ones. It runs Ubuntu no problem. All of Microsofts products seem to have latency issues, and I still can't figure out for the life of me why it takes longer to open a file in Visual Studio or in Word on my gaming desktop than it does to load a current year $60 video game. I wish designers focused what they call "gamefeel" in video games: how quickly, clearly, and satisfyingly does the program react to user input.
Edit: on the other hand, computers do start up a heck of a lot faster than they used to.
I'm typing this on a 5 year old netbook that had cost me $300 back then with 2GB, which I later upgraded to 4GB. It runs Windows 10 very smoothly, it's my living room TV computer for browsing, torrenting (up to 1080p) etc. At this time I'm running Firefox, Chrome, VLC and uTorrent seeding and performance is decent, certainly not "unusable".
Windows 10 is really inconsistent. I have it running in a VM on a Fedora host and it's snappy as hell. Also on a pretty basic office-spec Celeron, but then running it on a new Ryzen 7 sometimes it lags. I don't think it's directly related to the performance of the hardware, there must be something else going on.
Windows 10 has all kids of debuggers enabled on millions of computers, MS calls this telemetry :) Go to Management and check out startup event trace sessions. Those are the source of mysterious >hundreds of megabytes of logs written to disk per day.
At work we've recently moved from XP to Win7 and they seem to perform about the same for heavy office use.
I'm playing with a Win10 machine at home, the CPU and RAM is far in excess of our work machines but it is so slow to use. It seems to regularly become unresponsive, programs take ages to start, it seems to be continually working away in the background doing 'nothing'. It's a truly horrible experience.
i really like office 365 but the most productive thing i ever did was get rid of it on my work machine and install office 2010 again. it's just so much snappier there is no comparison. (although i also tried office 2003 for a day and boy it's blazingly fast. on a modern system you don't even see the startup screen, not to mention any input lag.)
On Win10 you need to have enough swap space on an SSD; HDD I/O has totally kneecapped latency, seemingly due to blind usage of NCQ (AHCI driver got replaced from Win7), so it chokes out entirely when combined with the even more broken swap manager.
"Enough" meaning "infinite", because you're going to have something leaking all that memory. Task manager doesn't even show memory usage by default (add the "commit size" field), only the working set (and the swapping is insanely aggressive, so memory leaks just don't show up). Nobody seems to actually check that; even built-in stuff like Windows Update leaks pretty badly.
One thing can't wrap my head around: if I receive a big (10Mb) email through a slow connection, Outlook completely freezes until the email has finished downloading. I'm talking, not even rendering correctly, and showing white rectangles instead of drawing components. How on earth can this not be a tested use case? Is there no separate thread to connect to the Internet?
Meanwhile my experience is opposite. I use Windows 7 at home and OSX for work. My personal machine is responsive, zippy, and most important of all, predictable
Meanwhile, my SSD filled work mac bogs down in completely unpredictable ways, with weird antivirus scans that I cannot control somehow destroying javascript performance, and needing to be rebooted more than weekly to stay functional in multiple ways. I was similarly dissatisfied with OSX in the mid 2000s when I used it at school. I just don't get it
I should probably make a video of me opening an i7 2017 Macbook Pro with 16 GB RAM and waiting 3-5 seconds until the system allows me to type the password (also, I sometimes switch to Czech keyboard, and High Sierra has a bug where it randomly shows one input language as active in a top right but actually uses a different input language in a password field - this happens in about half of login attempts).
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.
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.
> 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.
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.
We need multi-threading to be super simple but for that we need mass adoption of new programming tools and techniques (and the corresponding mass-abandoning of old ones).
But good luck with that! You're fighting against the most powerful force in the universe: economics (more specifically sunk cost into existing investments). "Soft"ware is a lot "harder" once economics are taken into account.
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.
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.
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.
Wasn't the lock in the article kind of async? From my understanding, the problem was not the wait time on the lock alone, but that the lock is not fair: so even if you asynchrounously locked, someone else (in this case the WMI scan) can get the lock everytime before you get it so you are blocked a long time (you cannot continue with this particular operation until you get the lock, even in the async case).
In the article, they illustrate a poor design choice. Or probably more likely, a continuation of the programming practice utilized elsewhere in the kernel. That being, slap a lock on any resource contention. That practice is necessitated solely by the need to support a linear calling interface. Even if this particular issue were to be fixed through queuing instead of locking, the existence of locks elsewhere will still become an issue in a given use case.
My point is, by design, an operating system that has a fully async interface can dispense with locks altogether. Resource contention is then properly resolved through queuing. The OS can then strictly enforce a priority scheme on its various queues, preventing an opportunistic thread from dominating the system. Or enabling higher priority requests to be serviced first. But that decision is made intelligently, not as a result of optimizing to minimize context switching.
Don’t see the fundamental difference between locks and queues. In a system that uses locks, the kernel can still internally use queues to grant some lock requests before others.
The fundamental difference is this. With locking, when a thread’s time slice expires while holding a lock, the dispatcher switches to a different thread and no other thread can gain that particular lock until the dispatcher resumes the thread holding the lock.
If every OS required async calls, it would require every developer to learn async programming. They probably wouldn't learn it properly, and you'd end up with more race conditions and bugs than if async was optional.
Closures/blocks really make it a lot easier to follow the flow of async coding.
Async style enforces a kind of minimalism that in my opinion simplifies the problem space overall. Obviously, one has to learn different approaches to problem definition and solution to embrace event-driven coding.
To me, in the comparison of linear programming handling an exception when your call stack is 5 levels deep (or maybe 3 in a different use case), having to bubble the appropriate handling at each of those levels, versus async where in your closure you have a 4-line if/else construct that fires off one event for success and a different event for failure, async wins the simplicity competition every time.
If race conditions are an issue, events should be dispatched through a single-threaded finite state machine dispatcher for resolution. Such events can fire up multiple worker threads to do their bidding, but when state changes, that goes through the dispatcher which inherently resolves all races.
The problem is not that we cannot parallelize hardware. The problem is that the software making use of it is lacking. 24 cores is plenty, but if most software only uses one core even more cores won't help.
GPUs can just do fast matrix multiplications in parallel, but it’s up to the developer to reframe their software into matrix multiplications. For some applications it’s great, but for most it isn’t realistic.
Also if General processors are now hitting a wall, it’s only a matter of time before GPUs do.
This has nothing to do with Moore's Law or improving processors directly. If anything, this is a software optimization problem. Half of what I mentioned was locks and schedulers, which are directly software problems. Layer on the fact that a helloworld application in most languages and frameworks is 100s of KB to dozens of MBs, and you have really, really, unoptimized software. 30 years ago, lots of software was written in Assembly and some C. But software has gotten fatter and slower at a much much faster rate than hardware has gotten faster/more parallel since the industry introduced ILP, caches, multi-stage instruction pipelines, etc. with the Pentium/5x86 class microcomputers & processors. Most people never learn to write multi-processing, multi-threaded, multi-programming, event-driven, decentralized or distributed applications. The model that browsers and most languages & frameworks provide is usually inherently sequential and single processing.
If web developers never learn to write multi-processing, multi-threaded, multi-programming, event-driven, decentralized or distributed applications the web will forever look like it looks today.
> This has nothing to do with Moore's Law or improving processors directly. If anything, this is a software optimization problem.
This is such a contradictory sentence. The whole point of Moore's law was that software developers could do what they want, freed by limitations of hardware because in 18 months, when their product was ready for launch, the hardware became capable enough to handle it.
Forcing developers to focus more and more on performance (via threading, distributed systems, and custom die co-processors), rather than innovating new applications, is a huge shift. It's like the hardware developers gave up, and tell the software developers that it's in your hands now.
Also, comparing a hello world program 10 years ago to today is a meaningless comparison because no one uses hello world to do anything. A better example would be Excel in 1998 and Excel in 2018. Sure today, it's a 500 megabytes instead of a just a handful, but it does quite a bit more (for better or worse).
You don't understand Moore's Law. Moore's Law says nothing about software devs doing what they want or processor speed or even hardware capabilities or qualities. It's about the manufacturing capability and integration by semiconductor fabs. Specifically, "Moore's law is the observation that the number of transistors in a dense integrated circuit doubles about every two years.' [0]. Hardware engineers never gave up; they're the reason your bloated apps takes 60 secs to startup instead of 3600 secs.
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.
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.
In the scenario described in the article, where was the bad engineering? It seems to me that the developers of each component (Chrome, OS, other processes) did things that, while perhaps not perfect, are quite reasonable, and definitely not exceptionally bad. Only together did they interact in this undesirable way.
This case isn't some web app that uses infinite memory; the contended resource is a lock.
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.
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
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)
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.
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.
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.
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..
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.
> For some reason most people see either no symptoms or much milder symptoms than I do.
This seems to be right for "most people". But there are definitely a few people who are annoyed by issues like this but aren't in a position to troubleshoot and report it.
Even I, after helping people with computers since mid nineties I still can't troubleshoot like that. I'll fall back to latency checking and turning off services one by one, combined with a fair amount of experience + googling.
Our IT department was running regular WMI scans of our computers
This seems like a big part of the problem.
While I recognise that IT departments at Google-sized companies do have some extra worries, I do feel that we’re gradually losing the “personal” from PC, and that seems pretty unfortunate.
Hi Bruce. This is a fantastic article, but I needed to read it twice to understand everything. Very dense in information, and sometimes the order of things make it hard to follow. Sometimes you tell us what you did (e. g. modified the virtual memory scanner) before telling us why (what CFG is, how it works), which was confusing.
> It turns out that reproducing the slow scanning from the sampling data was quite easy.
This was the first thing that went over my head. Going from one stack trace to reproducing it is quite the jump. Maybe add a sentence "The interesting part of this trace is NtQueryVirtualMemory, which is used to scan process memory." Might be obvious to you, but for me that trace was "just a bunch of Windows stuff" at first.
The full investigation covered about two weeks and I was having trouble condensing the story into a single post. I appreciate having a particular problematic transition pointed out. Fixed.
Have to give it to Apple for acknowledging the difficulty in writing responsive (as in no lockups) applications and designing multiple developer framework solutions to solve it (Grand Central Dispatch and NSOperationQueue).
Both those are designed to enable developers to easily offload work to background threads and prioritise queued work for the user. No open-for-interpretation thread priorities, but named QoS priorities (User Interactive, User Initiated, Utility and Background). It makes much more sense for that abstraction.
Maybe more developers would make use of it if it was open source, existed for other platforms, and available for languages people actually use on those other platforms.
So why are we in this mess? Because there are still buffer overflows.
Address space randomization is done because buffer overflows allow exploits. But rather than fixing the underlying problem, we now have complex schemes to spread programs over the entire 64 bit address space to make such exploits unreliable.
Then, apparently Microsoft's Javascript JIT engine has enough problems with buffer overflows that each compiled program is in a different random part of the address space to try to prevent Javascript exploits.
Isn‘t that a bit ignorant when nobody is forced to access their e-mail through a website running JIT-compiled JS in a browser with built-in OS features on a bloated, graphical UI of an OS with the burden of 25+ years of backwards compatibility?
A fast client running on a lean OS would not exhibit these problems - and AFAIK gmail still supports IMAP.
(I use Fastmail on MacOS&IOS/Safari and have no such issues either).
Web applications are the best example for Wirth's law. It's really mind-boggling if you think about it. None of the client-side components of a web application were originally designed for what they are used for today:
1. a programming language (Javascript) that turns into a nightmare if you try to write programs with more than a few thousand lines
2. a user interface that requires you to learn two additional declarative languages (HTML and CSS), both of them equally incomplete and crappy.
3. an API between 1 and 2 that is so lacking that you need an external library (e.g. jQuery) to reduce the amount of boilerplate code to a sane level.
4. a network protocol (HTTP) that was designed for static web pages with a few pictures and that has serious performance issues for anything more complex.
5. and finally, the whole thing implemented in a language (C or C++) that is fast but offers you plenty of opportunities to shoot yourself in the foot in obscur ways security-wise.
Things are changing fortunately (HTTP/2, QUIC, Rust).
This is Google's. The problem manifested in Chrome. From the article:
> It turns out that v8 (Chrome’s JavaScript engine) has CodeRange objects for managing code-gen [...] But what if you have multiple CodeRange objects, and what if those get allocated at random addresses and then freed?
Because the underlying problem cannot be solved, until all the programs and systems currently in use can be completely rewritten and reimplemented with a widely-accepted programming language and methodology to ensure correctness and security.
If the current approach from the C+Unix era to programming and OS is still in use, there are only three solutions available...
1. Fix-and-miss all the bugs, safe programming practice.
2. Isolation
3. Mitigation
Isolation is useful to limit the scope of a security breach but cannot stop attackers from exploiting the bugs. The only solution which is able to stop attackers from exploiting existing programs is mitigation - you don't fix and miss individual bugs, bugs are always there, what we need stop attackers from exploiting them. Some exploits are easy to stop, hence NX. Others can only be stopped in a probabilistic way, hence ASLR.
319 comments
[ 4.7 ms ] story [ 271 ms ] threadUnfortunately it quickly gets really complicated so a bit of hand waving is necessary.
The sparse/virtual bit mask is an optimisation technique so the validation of the target address is quick.
I too hate side activities when I'm in the zone but you have to admit this situation can eat away at your audience. :(
https://chrome.google.com/webstore/detail/ublock-origin/cjpa...
Seriously. Adblock is the way you have to fight back, to change the economics of the internet. Install it, use it indiscriminately, and make sure you tell others to use it.
My company makes a decent chunk of money from ads btw. Not because we can't make money another, better and cleaner way, but because it makes no sense to leave money off the table when the adblock rates are so low.
_____________________________
Says the person with +500 tabs on chrome android
https://adnauseam.io/
It's funny how tides turn. Initially Gmail was the king of performance.
What is all this stuff even doing?
Other than fighting with the calendar occasionally (sometimes needing to force a manual sync to see coworkers' events), Gmail in Thunderbird has been pretty smooth. I have not noticed slow search, slow mail receipt, or application crashes. In fact, the search is often too good, in that after running it it matches hundreds of more emails than I usually expect. I usually stick with the quick filter which is a bit less flexible, but generally returns more useful results.
Another advantage, on Linux at least, is that if you copy your ~/.thunderbird folder to another machine, all accounts, GUI layouts, settings, search results, tabs, etc move over flawlessly. I think you just have to re-sign in for Google accounts on the new machine and you are good to go.
I have decided to just leave it be, and let it hog my computer, because it interface decently with google calendar.
That being said, I can definitely vouch for clients like Claws Mail (a bit ugly, but does its job) and Evolution (super fast, but it's written in C#/Mono)
Ive always loved Japanese website layouts. Content is beauty.
Actually Gmail's approach is sane. They just keep old UI working as it used to many years ago although the backend could have changed completely.
they probably have an api in which you can limit the results by category. As the old interface doesn't have any limiter implemented, they're getting all the results back.
you can also disable categories in the newer interface and the effect would be the same (everything in the inbox)
Outlook the Windows app deserves to be the most awful app ever, but Skype for Business worked harder!
When, and compared to what? I'm pretty sure it was never faster than Thunderbird let alone something like Mutt.
...
So don’t use a proprietary kernel that performs poorly?I could work on Chrome for Linux, but then this bug on Windows might never get found or fixed. I am satisfied with my choices, despite the occasional glitches.
"I use the Chrome browser on Windows to get work done"
and
"I work at Google, making Chrome for Windows".
Human languages, what are you going to do?
I modify the source code of the Chrome browser in order to make the final PE files that are compiled from the aforementioned source code work more efficiently.
"I work at Google, making Chrome for Windows".
That said, WPA (the UI for ETW) is complex for new users, but mostly only necessarily so.
It also uncovered a "bug" (performance weakness?) in v8 that they were able to fix so less CFG blocks were allocated.
So kind of a win/win in the end, bugs fixed, world a slightly better place.
They implemented a freelist, it's a common workaround for problematic allocators, but has its own issues (https://www.tedunangst.com/flak/post/analysis-of-openssl-fre...)
Because the memory is fully freed and reallocated this also avoids security concerns.
We already do throttle hidden tabs, but I don't think we throttle their bandwidth usage directly. It is tricky, unfortunately.
I was very conservative in my use (thank you hacker news for being data-light) but managed to reach the cap near the end of my stay; my girlfriend who has no concept of what is heavy and what isn’t reached the cap in less than 2 days - after which; mobile data was effectively useless for her.
I can’t imagine what life is like for those who /live/ on data caps- I feel like most web developers don’t give a shit about how much resources they use, not just in terms of CPU/Memory (“lol, it’s 2018 buy a better pc!”) but also in terms of bandwidth; which is regularly out of user control.
It was even worse a few years back - once you had used your data allowance you had no way whatsoever to top up at all.
I don't remember where I learned the technique first, but when I was roaming the world and getting work done via GPRS internet, I'd open links in a new tab and let them slowly load in the background. I'd view the tab later and see the fully rendered content. It would absolutely kill this use case if the tabs would not perform their necessary AJAX calls until foregrounded.
For those not familiar with GPRS of those times, imagine a 9600-14.4 modem speed but with the latency of a satellite connection, so with almost any activity you start seeing 1 second ping times. Even when on ridiculously fast connections, I still retain the muscle memory which causes me to browse in breadth-first mode, opening articles and discussions into tabs in one sweep and then working through the tab list from left to right and closing each as I go.
Get better OS; problem solved.
Linux locks? I have no idea and would be interested to know.
I suspect that occasionally fair locks would be ideal, but I don't know if they can be implemented efficiently.
Futexes do support priority inheritance, so you can use process priority safely. You might drop priority after releasing a lock to ensure some other thread gets a go, and as long as you control the priority of the other contenders, that can work well.
Basics of futexes are here, but nothing about PI or fairness: https://eli.thegreenplace.net/2018/basics-of-futexes/
Because these days, unlike in the 90's, it's no help waiting for the next Pentium processor to come out this usually results in a heavy optimisation cycle in the underlying engine. For example Firefox has advertised a speed-up several times in the last 10 years, each coming from a focused effort to rewrite or optimise the JS engine, the rendering engine, or something else. Then things accumulate again, until things are too slow.
Obviously the cycles aren't wasted as you can do things with a few lines of high-level script that would've taken months to implement in the "good old times". But this development inevitably creates bizarre flashbacks where, occasionally, you're doing something simple like typing text on today's monster machines and it takes a few seconds for the screen to catch up your typing.
When I started programming, things were roughly and more or less instant. Typing was instant. There was a very short code path from handling the interrupt to updating screen. The computers reacted more like physical apparatus. Terminals at shops, warehouses, hospitals, with text-based programs to update data were pretty much instant too. Good clerks could bang their keyboard through multiple subscreens of their program in seconds, and you were checked in, goods reserved, or patient data updated. Later, when multitasking hit the mainstream, flipping between programs was instant. (Not on Windows, though.) Things like I/O took its time, of course, but at one point there was a peak moment where a software machine had nearly as low latencies as a physical machine.
From those times things have mostly gone downhill. Yes, we have immense processing power and near endless fast memory and disk storage. You can switch between browser tabs 300MB each pretty fast but there is a constant, nagging sense of slowness present all the time. Maybe sometimes switching that tab or bringing up another program takes longer, surprisingly, or there is something simple that just doesn't happen right away. The feeling of instant responsiveness is broken into shards: you can still see a reflection of it if you happen to look at the right angle but mostly its crumbles are pointing elsewhere.
Things like BeOS tried to reach back to that, with varying but acknowledgeable success. But real success in terms of popularity and market penetration seems to come from piling up stuff until things get too slow. So I doubt we never get back to the old world of instant response in spite of processing power keeps climbing up.
For the last couple of years it seems I'll get some issues on some Google properties if I dare use a different browser than Chrome.
For a while it was search results doing interval training on my CPU, while the page was supposedly idle.
Last it got to the point where I started troubleshooting it was calendar that acted up.
You'd think a company like Google had resources to verify the UI across at least the 3 or for biggest browsers across the three biggest desktop platforms, -but it doesn't seem like.
Should they ever want to do that. I think I've read multiple discussions in the past about how Google is optimizing exclusively for Chrome while hurting the performance and compatibility with any other browser. Which is why Chrome is now basically called the new IE6.
Perhaps google is doing this too?
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.
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?
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.
My machine randomly has input delay or mouse even after new install...
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
(Although with 24 cores...)
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.
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.
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.
It's buttery smooth and I get no noticeable lag. Exactly 7 seconds from power button to login screen on a cold boot too.
At least in Windows you aren't at a TTY that echos everything to the screen by default until PAM has hauled itself (and its umpteen libraries) off the disk (yes people still have 5400RPM HDDs :D), initialized, and put the terminal into no-echo mode...
Ah! So that's what's going on :D.
And you can always run strace -f on whatever handles login (getty, logind, systemd, etc), drop to a TTY and login, to see all the stuff that gets loaded.
I don't know much about the situation on Windows but at least on linux your HDD is hardly going to cause lags if you have a well configured hardware setup.
Laptop users are many, and they care about boot up times. Especially since Linux power management is still awful.
On my current X1 Yoga 1st gen, I do regularly get almost 1.5x the uptime on battery compared to windows 10.
We got a batch of X1 Carbon 6th gen, which are "optimized for windows 10", where the S3 sleep state was replaced by the S0I3, which is OS-assisted. The X1 Yoga with S3 can both suspend and resume faster than windows 10, despite not having S0I3 (and has longer battery lifetime to booth).
And by fast I mean that by the time the lid is up, the OS is ready. By contrast, windows 10 seems to always shuffle for several seconds after resume, even on the carbon 6th gen.
So please...
High-end laptop lines (Dell, HP, Lenovo) have actually pretty good linux support, they are almost always intel i5+ cpus with integrated graphics which are all very similar. There is next to zero setup required in almost any case. This is known. The drivers are tried and tested. I've never experienced any random "power management issue". Suspend/resume/battery consumption/acpi is working perfectly fine. What else does qualify for "power managment"??
I've been supporting a team of 20+ people with these lines in a mixed environment, and linux since more than a decade was always basically plug and play.
There have been some quirks in some models, which generally required some tweaks in the kernel boot line, to fix issues with backlight tweaking.
Sure, but Linux really ought to shine on the low-end laptops.
But this doesn't save you from crappy hardware, which is why this kind of argument is a non-starter for me. How well does current windows editions work on low-end crappy laptops that sell for the lowest tier? Not great. These laptops have plenty of little issues on windows as well.
Maybe better than linux, because the drivers have way more work-arounds than linux has.
Have you ever seen the internal linux quirks table to work around buggy and downright horrid hardware? That's what you get with those. If it works at all is thanks to the patience of people that put in the time to work those issues around. I frankly do not blame linux if it doesn't work well with such hardware.
acpi patched_dsdt.aml
This has the advantage of not requiring any manual intervention every time your kernel is updated. The downside is that if you try to dual boot W10, it will BSOD on boot with an ACPI error. To overcome this, take the original dsdt.aml and load it in a custom (not auto-probed) menu entry for windows. You can just clone the auto-probed line, and add before the chainloader line:
acpi old_dsdt.aml
Sadly, the 6th edition of the Carbon also runs waaay hotter than the 3rd, and I did notice occasional coil whine which was previously absent. When running normally the kernel writes regularly about thermal warnings. It seems that power and heat management is not well managed in this edition, and I see similar reports for the x1 yoga 3rd gen.
My system is exceptionally lean. I run bspwm and the radios are always off except WiFi. Still, I feel like I could get a lot more from this laptop. I cannot (and I certainly wouldn't want to) install Windows on dual boot to make a comparison though.
What distribution do you use?
I personally use debian unstable with a tiling window manager (awesomewm) without a specific DE. However, I generally setup Mint for all my colleagues on the same laptop lines, and there's one colleague running Arch. We all have very similar battery lifetimes.
One of the problems here is that power-draining can happen by different components. Quite popular are graphics chips, but other components can be part too. For example, a friend of mine has problems with his device waking up from s2idle during transport. That is not exactly what you would expect in such a discussion, but from a users perspective, he has less time to work with his device given his usage pattern.
For me, this isn't much of a problem as I prefer working on a desktop, but I wouldn't accuse someone of being a liar just because he had a bad experience with power consumption on Linux.
https://news.ycombinator.com/item?id=17786400
I've also found macOS provides the smoothest experience. I haven't found W10 that bad, but I haven't used it that extensively. I really only boot into Windows to play games these days.
that's not what mainline kernel optimizes for, you have to use liquorix or another kernel (https://liquorix.net/)
Edit: Having tried in on my laptop, installing the gjs + libgjs0g version 1.53.3 debs from http://gb.archive.ubuntu.com/ubuntu/pool/main/g/gjs/ onto a bionic install seems to work fine. Worth trying if this bug is affecting you?
I've recently given KDE Plasma a try and was really impressed by it's speed and smoothness.
I think it shows when your desktop does not rely on interpreted langues so much.
Edit: on the other hand, computers do start up a heck of a lot faster than they used to.
I'm playing with a Win10 machine at home, the CPU and RAM is far in excess of our work machines but it is so slow to use. It seems to regularly become unresponsive, programs take ages to start, it seems to be continually working away in the background doing 'nothing'. It's a truly horrible experience.
"Enough" meaning "infinite", because you're going to have something leaking all that memory. Task manager doesn't even show memory usage by default (add the "commit size" field), only the working set (and the swapping is insanely aggressive, so memory leaks just don't show up). Nobody seems to actually check that; even built-in stuff like Windows Update leaks pretty badly.
Oh and the memory accounting doesn't even work.
Meanwhile, my SSD filled work mac bogs down in completely unpredictable ways, with weird antivirus scans that I cannot control somehow destroying javascript performance, and needing to be rebooted more than weekly to stay functional in multiple ways. I was similarly dissatisfied with OSX in the mid 2000s when I used it at school. I just don't get it
This isn’t how it used to be. Sigh.
And a slow hard disk is often the bottleneck, in case of windows.
Add locks and you add many more causes for the main thread to be blocked beyond pure computation.
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.
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.
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.
But good luck with that! You're fighting against the most powerful force in the universe: economics (more specifically sunk cost into existing investments). "Soft"ware is a lot "harder" once economics are taken into account.
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.
My point is, by design, an operating system that has a fully async interface can dispense with locks altogether. Resource contention is then properly resolved through queuing. The OS can then strictly enforce a priority scheme on its various queues, preventing an opportunistic thread from dominating the system. Or enabling higher priority requests to be serviced first. But that decision is made intelligently, not as a result of optimizing to minimize context switching.
No locks means this can never happen.
Async style enforces a kind of minimalism that in my opinion simplifies the problem space overall. Obviously, one has to learn different approaches to problem definition and solution to embrace event-driven coding.
To me, in the comparison of linear programming handling an exception when your call stack is 5 levels deep (or maybe 3 in a different use case), having to bubble the appropriate handling at each of those levels, versus async where in your closure you have a 4-line if/else construct that fires off one event for success and a different event for failure, async wins the simplicity competition every time.
If race conditions are an issue, events should be dispatched through a single-threaded finite state machine dispatcher for resolution. Such events can fire up multiple worker threads to do their bidding, but when state changes, that goes through the dispatcher which inherently resolves all races.
Also if General processors are now hitting a wall, it’s only a matter of time before GPUs do.
If web developers never learn to write multi-processing, multi-threaded, multi-programming, event-driven, decentralized or distributed applications the web will forever look like it looks today.
This is such a contradictory sentence. The whole point of Moore's law was that software developers could do what they want, freed by limitations of hardware because in 18 months, when their product was ready for launch, the hardware became capable enough to handle it.
Forcing developers to focus more and more on performance (via threading, distributed systems, and custom die co-processors), rather than innovating new applications, is a huge shift. It's like the hardware developers gave up, and tell the software developers that it's in your hands now.
Also, comparing a hello world program 10 years ago to today is a meaningless comparison because no one uses hello world to do anything. A better example would be Excel in 1998 and Excel in 2018. Sure today, it's a 500 megabytes instead of a just a handful, but it does quite a bit more (for better or worse).
[0] https://en.wikipedia.org/wiki/Moore%27s_law
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.
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.
This case isn't some web app that uses infinite memory; the contended resource is a lock.
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.
This is so ugly I hesitated to post it, but here: 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.
Software will always expand in resource usage as computing becomes faster. This ought to be an adage that more programmers should think about.
http://danluu.com/input-lag/
This seems to be right for "most people". But there are definitely a few people who are annoyed by issues like this but aren't in a position to troubleshoot and report it.
Even I, after helping people with computers since mid nineties I still can't troubleshoot like that. I'll fall back to latency checking and turning off services one by one, combined with a fair amount of experience + googling.
This seems like a big part of the problem.
While I recognise that IT departments at Google-sized companies do have some extra worries, I do feel that we’re gradually losing the “personal” from PC, and that seems pretty unfortunate.
> It turns out that reproducing the slow scanning from the sampling data was quite easy.
This was the first thing that went over my head. Going from one stack trace to reproducing it is quite the jump. Maybe add a sentence "The interesting part of this trace is NtQueryVirtualMemory, which is used to scan process memory." Might be obvious to you, but for me that trace was "just a bunch of Windows stuff" at first.
The full investigation covered about two weeks and I was having trouble condensing the story into a single post. I appreciate having a particular problematic transition pointed out. Fixed.
Both those are designed to enable developers to easily offload work to background threads and prioritise queued work for the user. No open-for-interpretation thread priorities, but named QoS priorities (User Interactive, User Initiated, Utility and Background). It makes much more sense for that abstraction.
We just need more developers to make use of it.
Address space randomization is done because buffer overflows allow exploits. But rather than fixing the underlying problem, we now have complex schemes to spread programs over the entire 64 bit address space to make such exploits unreliable.
Then, apparently Microsoft's Javascript JIT engine has enough problems with buffer overflows that each compiled program is in a different random part of the address space to try to prevent Javascript exploits.
A fast client running on a lean OS would not exhibit these problems - and AFAIK gmail still supports IMAP.
(I use Fastmail on MacOS&IOS/Safari and have no such issues either).
1. a programming language (Javascript) that turns into a nightmare if you try to write programs with more than a few thousand lines
2. a user interface that requires you to learn two additional declarative languages (HTML and CSS), both of them equally incomplete and crappy.
3. an API between 1 and 2 that is so lacking that you need an external library (e.g. jQuery) to reduce the amount of boilerplate code to a sane level.
4. a network protocol (HTTP) that was designed for static web pages with a few pictures and that has serious performance issues for anything more complex.
5. and finally, the whole thing implemented in a language (C or C++) that is fast but offers you plenty of opportunities to shoot yourself in the foot in obscur ways security-wise.
Things are changing fortunately (HTTP/2, QUIC, Rust).
Pretty certain Google Apps administrators can disable IMAP and POP for their organizations.
This is Google's. The problem manifested in Chrome. From the article:
> It turns out that v8 (Chrome’s JavaScript engine) has CodeRange objects for managing code-gen [...] But what if you have multiple CodeRange objects, and what if those get allocated at random addresses and then freed?
If the current approach from the C+Unix era to programming and OS is still in use, there are only three solutions available...
1. Fix-and-miss all the bugs, safe programming practice.
2. Isolation
3. Mitigation
Isolation is useful to limit the scope of a security breach but cannot stop attackers from exploiting the bugs. The only solution which is able to stop attackers from exploiting existing programs is mitigation - you don't fix and miss individual bugs, bugs are always there, what we need stop attackers from exploiting them. Some exploits are easy to stop, hence NX. Others can only be stopped in a probabilistic way, hence ASLR.