Slashdot Mirror
24 Cores and the Mouse Won't Move: Engineer Diagnoses Windows 10 Bug (wordpress.com)
Longtime Slashdot reader ewhac writes: Bruce Dawson recently posted a deep-dive into an annoyance that Windows 10 was inflicting on him -- namely, every time he built Chrome, his extremely beefy 24-core (48-thread) rig would begin stuttering, with the mouse frequently becoming stuck for a little over one second. This would be unsurprising if all cores were pegged at 100%, but overall CPU usage was barely hitting 50%. So he started digging out the debugging tools and doing performance traces on Windows itself. He eventually discovered that the function NtGdiCloseProcess(), responsible for Windows process exit and teardown, appears to serialize through a single lock, each pass through taking about 200 microseconds each. So if you have a job that creates and destroys a lot of processes very quickly (like building a large application such as Chrome), you're going to get hit in the face with this. Moreover, the problem gets worse the more cores you have. The issue apparently doesn't exist in Windows 7. Microsoft has been informed of the issue and they are allegedly investigating.
Not a program, a process.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Not 200S each, which is off by a factor of one million. But, hey.
7 come 11. Baby needs new shoes.
We just don't have priority...
“He’s not deformed, he’s just drunk!”
Well you should probably stop using Windows 98.
If there is an issue that keeps process termination and cleanup from being properly parallelized; I can understand why that might cause unexpectedly poor utilization of additional cores for computationally intensive tasks that also massacre lots of processes; but why would that cause the GUI to stop responding?
Unless moving the cursor also depends on terminating a bunch of processes; and hangs until that task is finished, wouldn't the inefficiency imposed on the build process be expected to keep the GUI more responsive; by preventing it from occupying as much CPU time as it otherwise would?
Am I just confused? Does keeping the desktop and cursor drawn actually involve lots of time sensitive process killing? Does this indeed not make sense?
Marketing - "How do we monetize this...."
Engineers - "You mean after we fix it?"
Marketing just begins laughing - "Only if it get more money then leaving it in and marketing it as a feature"
More specifically, why are OSes not designed, and computing hardware not designed, so that the GUI cannot be slowed down by other slow processes, process switching, or I/O / virtual memory thrashing.
The most brain-dead design-avoidable situation in the computing universe is where my computer is thrashing due to some resource over-use, and the UI is inoperable so I can't fix the problem e.g. by killing processes/programs. DOH!
The UI and user input devices should be a completely separate set of processes and memory than the rest of application processing. It should operate as a service, through data pipelines, to the rest of the applications. It should be completely separate, in terms of resource management. Or failing that, certain aspects of GUI, such as program kill controls, should be highly prioritized over pretty much everything else.
Again, slow and over-used everything else should not slow the UI and user input processes. This is basic.
Where are we going and why are we in a handbasket?
7 right?
being the only OS I've ever seen in my life move a window around screen w/o tearing. Yeah, it doesn't make much difference, but you'd think in 2017 my quad core CPU and 8 gigs of ram could do what a 400 mghz AMD K6 did in 1996 with 512 mb ram.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
It's not even wrong (to quote a famous scientist about a really ill-formed idea).
At this point with multi-core computers, the GUI and mouse etc should be on a completely separate core that is managed somewhat separately than all of the others.
Where are we going and why are we in a handbasket?
Probably a dumb question... Is there such a thing as firewalling or sandboxing a GPU for that?
That could be related to the hardware acceleration. If I had to guess, the Windows desktop would need to wait for the game to release it's GPU resources and load its own in to the GPU memory.
Back in the XP days, going from game to desktop was very quick, but going from desktop back to game was very slow. When Vista came along, the Os started using the GPU to accelerate the desktop. Made it slow both ways
I'm glad you've volunteers to help with their concurrency programming. Good luck, it's not easy.
Usually at some point, access to shared resources needs to be controlled. There are easy ways to do it and there are hard ways. Easy isn't fast, but it's predictable and less error-prone.
Made it slow both ways
And more expensive. Oh, the irony!
2 Core for DRM
2 Core for DRM Protection
2 Core for Telemetry
2 Core for Telemetry Protection
2 Core for Genuine Advantage
2 Core for Genuine Advantage Protection
2 Cores for Driver Signing Validation
2 Cores for Driver Signing Validation Protection
2 Cores for Cortana
2 Cores for Cortana Telemetry
2 Cores for Cortana Telemetry Protection
1 Core for the Base OS
1 Core, at 25% for user processes
Yeah except the issue doesn't exist in 7 so they can just roll back this very tiny part of Windows.
In my basement office I have six computers I use regularly. Two are running MacOSX, one is running Ubuntu, two are Windows XP, and one is Windows 10. I just went around the room and checked uptimes. All of them were up for more than 3 months, except the Windows 10 computer. This one computer is supposed to be pretty fast compared to the rest but it gets bogged down where I feel compelled to reboot it. It also has the nasty habit of demanding to reboot when I'm trying to get work done, but that's a different problem. After reading this I'm somewhat relieved to think I'm not doing something wrong that's making it run slow, or that I'm just imagining things.
One of the Windows XP computers claims to have been on for over 15 years. I know this is not true since it's not even that old. Does the system uptime clock rollover or something to where it cannot track uptime accurately after a few months?
I dislike rebooting or powering off computers, preferring instead to just allow them to go to sleep when I'm done with them. They tend to stay on unless there is a power outage, and the power has been unusually stable with so many lightning storms in the area. It wasn't that long ago when such lengthy periods of uninterrupted time between crashing was unheard of. I'd probably have had longer uptimes if the power had not blinked.
People may ask why I run Windows XP. It's because I have some old software that I like and it won't run on my newer Windows 10 computer. So long as the hardware keeps going I feel no need to upgrade them in any way.
People may ask why I run MacOSX. Because fuck you, that's why. I'd give a serious answer but few people ask this seriously, they just want to be snobs.
I am armed because I am free. I am free because I am armed.
MS always had pretty bad engineering. This is just one place where it really shows.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Use Unicode for micro, yo insensitive clod!
We're on Slashdot not Soylent, here's no Unicode support. You don't expect those who wrote Slashcode to be able to enable a feature that's ready since a decade ago, do you?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
This has happened when starting Chrome since first trying Chrome.
Tried limiting Chrome to 3/6 cores and even then mouse goes jerky.
It may not be the exact same cause, but it is the exact same symptom.
There's also the matter that until somewhat recently, most lower-end GPUs were designed to accelerate lower resolution and/or shallower bit depths than the max the card could use for Windows. For example, the card might have allowed up to 2560x1600 @ 24/32bpp, but only supported hardware 3D acceleration up to 1280x800@15/16bpp. Even when resolution finally caught up, bit depth w/acceleration was stuck at 16bpp until well into the Windows 7 era. This is why so many computers with semi-ok gaming specs still couldn't do Aero Glass transparency when Windows 7 came out... they couldn't hardware-accelerate 32-bit color.
The problem still semi-persists among many phones & tablets. If an Android device seems to get blurry for a moment during transitions, it's not your imagination... Android is dropping to lower-res/fewer colors to accelerate the transition, then going back to high-res/color dumb framebuffer mode when it's done (and text suddenly becomes sharp & clear a moment later)
That is similar to question I asked while using Windows NT.
It is how I got into UNIX.
Yes. When everyone gets to high school, OS scheduling should be a priority. And if biology needs to be pushed out to make time for OS scheduling, then so be it. After all, noone needs to know the difference between a penis and a vagina. Transgenders don't. But I sure fuckin hope they know about OS scheduling! Fuckity FUCK!
BeOS was designed explicitly with this goal in mind. Here is one such recollection.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
Again, slow and over-used everything else should not slow the UI and user input processes. This is basic.
The oversimplified, but short answer is that there is no such thing as a multiprocess CPU. All CPUs can execute on only a single thread per cycle. The kernel exists to allow multiple processes to be resident and to provide the illusion of multiple thread execution. In other words, the essential function of the kernel is scheduling, and in doing this the kernel has to make decisions about process priority that impact responsiveness and resource utilization in often diametrically opposite fashions. To gain responsiveness, a process that is further down the execution queue has to preempt processes further up the queue, delaying their execution. This has a negative impact on overall thread performance as your CPU will be mostly underutilized if there is a lot of preempting going on. If the kernel inhibits (or prohibits) preempting, it can more efficiently utilize your CPU, allowing many threads to get as much CPU time as possible, but this will have a very negative impact on responsiveness.
UI and user input processes are just processes to the kernel. You can, of course, just give UI and user input processes the highest possible priority at all times, but this is not automatically the best thing to do in every circumstance. For example, you probably don't want your audio stream in the background to stutter or stop playing just because you started moving the mouse. And if you are flushing a file to disk, you probably want that operation to complete atomically, rather than be interrupted by a pop-up dialog, because corrupted filesystems tend to make users pretty unhappy.
I don't really know enough about Windows process scheduling, but the basic concept of compartmentalising various process types isn't new.
The level of control in minicomputer and mainframe operating systems is astonishing when viewed from the Windows/Linux/Apple world.
My favourite OS for control of user processes was OS400/IBM i. 90* priority levels, batch/spool/compile processes were automatically lower priority than interactive sessions, etc, etc
* there were actually 100 levels but the highest 10 were reserved for system processes.
They sentenced me to twenty years of boredom
Yeah, I spend way too much time watching the windows wheel spin around for no apparent reason other than the OS's inability to use more than one core.
I wonder if Process Lasso would fix the problem. It solved a weird issue with Xplane11 for me.
Because the GUI and 3D graphics were considered bolt-ons to an existing OS kernel. Not all systems may have 3D acceleration. Some servers even avoid having a desktop as that is considered a security risk.
When the GUI is in use, the user input processing becomes the dominant process; what event happened, which widgets have been changed. A desktop with a good number of windows might have 1000+ widgets, all of which have icon images for various states. TrueType and Unicode fonts are converted into images as well. A thread or process context switch has to happen to process each window.
I've seen it myself; copying data from the hard disk drive to a backup USB drive completely slows down everything. That's with a system with eight CPU cores. The bottleneck is the CPU L1/L2 cache memory and PCI bus. All the external storage data gets swapped in and out again just to do the file transfers. This could be avoided using DMA transfers.
But there are https://stackoverflow.com/ques...">security risks associated with raw DMA file transfers.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Android is dropping to lower-res/fewer colors to accelerate the transition
Or did it swap the high-res texture for a low-res one to save memory while it was not in use?
GPU's have been able to do 32bit acceleration for a long time.
Semi-OK gaming video cards that didn't support DirectX 9 couldn't run Vista Aero because it used the DirectX 9 API, required hardware based Pixel Shader 2.0 (not emulated in the driver) and at least 128MB of RAM. Not because of bit-depth.
Don't be a PC dork. We don't care that you have an ATX motherboard, nor are we interested in what brand of processor you use.
GPU speeds things up quite a bit. Even with Intel graphics. Throwing everything on the cpu makes things like a browser a chop chop fest.
[
http://saveie6.com/
I was kicked off the high school varsity team because I couldn't answer a pop quiz on operating system architecture.
“Common sense is not so common.” — Voltaire
Win10 on something with so much grunt?
Why turn an expensive system into a limited toy?
If you need to run MS compatible stuff MS Win7 and various MS server systems are available.
Windows is rather hoggish on hardware resources.
I am the unwilling control for my Origin.
Nope, I have dedicated hardware fifos for audio on the "sound card". If moving the mouse is enough to stutter audio, then I need more machine.
If I'm moving the mouse enough to toss the filesystem while committing to disk, then I have a poorly built file system in need of replacement.
Highest priority in a desktop should be UI with ability to pop up a limited system control panel to nuke bad behaving programs/processes/services.
Slashcode and /. actually support Unicode just fine. They implement a whitelist of allowed Unicode codepoints because there was a LOT of abuse of Unicode to basically screw up the webpage. From excessive decorations of characters that cause any web browser to render 10000 pixels up and down the page unreadable to messing with the page layout using the various control codes like right-to-left override.
Unicode support was added a long time ago (there is/was a Slashdot Japan, which is where the support came from). It's just too many people abused it back in the day (when /. was one of the top sites and thus trolls loved messing around with the site pages to annoy everyone).
So the admins decided that since Unicode was an evolving format, you can't really blacklist "bad" codepoints (there are lots, and more added all the time, including character adornments) they decided to whitelist instead, by using a simple UTF-8 breaking filter of fixing the MSB to 0.
Soo, that means that a simple DoS is possible via old-school fork bombs ? In 2017 ? Well done Microsoft !
More specifically, why are OSes not designed, and computing hardware not designed, so that the GUI cannot be slowed down by other slow processes, process switching, or I/O / virtual memory thrashing.
That is EXACTLY how BeOS was designed! In the 1990s! it's pathetic, really, that in 2017 no other OS has figured out this shit, yet. Not even Linux, in spite of all the development going on, there. I guess with Linux the excuse is that it's a server OS, not a desktop one.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Windows has detected that your mouse has moved. Please restart your computer for the change to take effect.
Escher was the first MC and Giger invented the HR department.
This issue didn't exist, so someone went and added synchronisation around the tear-down process. Why? People don't generally add mutexes at random, so this was probably done because they found a race condition in process tear-down that resulted in either a resource leak or kernel data structure corruption. Simply removing the mutex will probably fix this problem, but make the computer either run out of some kind of resources or crash. Probably not the correct fix...
I am TheRaven on Soylent News
Fork is heavily optimised on *NIX operating systems, because it's the primary way of creating new processes. Unfortunately, it's also a completely brain-dead one. It originates from old systems that had the running process in one form of storage and switched by writing it out to another. Fork made sense then, because you'd create the new process by writing out your current state and still have a copy of it in online storage for free. On modern systems, you need to mark all of the memory copy-on-write, create copies of the file descriptor table in the kernel (incrementing reference counts for all open devices) and do fairly complex things with each thread.
Windows post-dates the systems where fork made sense as an abstraction and so combines creating and launching a new process into the same operation (modern *NIX systems do this with posix_spawn as well). Implementing fork on Windows requires emulating all of the behaviour of fork: you have to create a new process with a copy of the current file descriptor set and then set up CoW shared memory mappings for all of your memory. If you're then doing an exec afterwards, then this is entirely wasted effort.
I am TheRaven on Soylent News
Since when does moving the mouse involve closing a process? Oh wait! Microsoft Windows.
...and that is all completely avoidable.
This is the result of bad design not any inherent limitation in the hardware or lack of DMA use. The PCI bus is involved in all cases (DMA doesn't transfer things magically).
Not only is there no need to keep copied data in memory (or even swap out other processes to increase the disk cache like Windows is fond of doing), but you can even turn off caches for copy processes to avoid trashing them.
Furthermore, rules can be created to govern when something is worthy of caching and when it is not (and many systems have those, taking into account things like type of access, random, sequential, which process interactive/background, how many accesses are queued up, big or small read/writes). Limits can also be set as to how much space a disk cache can consume.
As an example of how stupid Windows is/was, I remember the days when leaving Windows running overnight while downloading some torrents would leave me with a completely unresponsive system in the morning because everything was swapped out... why? Because Windows thought it was a good idea to cache all your overnight downloads (which is a stupid thing to do when your disk can read/write 50 MB/sec+ and your internet can hardly manage 1 MB/sec).
My solution at the time was: add enough real memory, and turn off the swap file. That artificially limited the amount of memory that could be devoted to disk caching.
Did it occur to you that there could be more than 1 bug in Windows? (Or elsewhere)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
There are many cases where the back end is more important than the GUI processing. This is a RT case problem where most of the products that have this issue just dedicate hardware to the backend processing and separate the GUI using message parsing, DDS, or some other way of clearly marking the boundaries.
Having a single hardware set with processors doing both GUI and high end back processing end up having issues. Graphics Chips are a result of taking the backend software and pushing it to hardware to speed it up. Either way, GUI processing is still limited.
Poor Dumb Human time becomes less important than auto detecting a Torpedo coming at you.
I can program myself out of a Hello World Contest!!
I was going to say something like this: https://www.neowin.net/forum/t...
Yes. A whitelist that barely let's most of ASCII through. That hardly counts as support.
Windows doesn't do fork. That is a technical choice.
Complaining that using fork on Windows is slow is funny (shows that the user thinks everything is Unix). Responding that it is due to bad engineering is hilarious and very sad at the same time. It shows that you are arrogant enough to think you understand the issue while completely failing to do so.
Exactly.
I've been writing high performance concurrent software since a week after I started programming. Not only can I count all of the discovered concurrency bugs for all of my projects on one hand, but I've discovered more concurrency bugs in .Net than my code. I typically fix my concurrency bugs in less than an hour, some times it takes a day, but only for the non-reproducible ones that only happen under very high loads when no one is around.
"Easy" is relative. I self discovered race-conditions when I was 8 and read about dual-socket 486 CPUs. The first few seconds were "awesome, twice as fast!", immediately followed by "you never get anything for free, how do the CPUs keep in 'perfect sync'. Hmm, you can't without making certain concessions that would be costly". After a few minutes of thinking, I figured there must be a way for CPUs to asynchronously send data and notify the other CPU when that there was new data or you had to be very careful about the order you changed data in memory. Of course I didn't realize the kinds of ordering issues OoO execution or memory operation reordering could cause, but I was intuitively aware of the problem.
Concurrency problems are fun to me, one of the few ways I'm challenged.
Is there such a thing as firewalling or sandboxing a GPU for that?
Yes and no.
Yes, there's a possibility to firewall against hardware.
- that's what IOMMU is for on modern processors.
So hardware with DMA (Direct Memory Access. That can directly read the RAM e.g.: FireWire, Infiniband, 10Gigabit Ethernet, Thunderbolt, etc.) can be isolated and cannot be used to dump the whole PC memory (see earlier attack with FireWire RDMA on Windows).
- modern GPU processors have even implemented their own MMU layer for additional fencing - so that 3D game that you've downloaded (or even WebGL and WebVulkan online game) doesn't secretely try to peek into other applications on your dekstop.
No, it won't help at all in the problem of scheduling.
That's a software problem.
The kernel is scheduling CPU cycles to thread wanting execution, and it scheduling access to resource for I/O requests by thread.
It's the kernel job to decide when to interrupt one task to give access to another (either CPU cycles or I/O access).
Knowing that interrupting more often give chance to other background task to work (gives better responsivity, even the mouse cursor gets the necessary cycles while a big computation is in progress)
And knowing that keeping task uninterrupted lets them finish quicker (gives better performance).
Balancing this responsivity vs. performance is a complex dark art.
Windows simply sucks at this.
This is even complicated by the fact that the modern mouse comunicates over USB or Bluetooth instead of PS/2 which are much more protocols with more component in the complex stacks that handle them.
This requires even more time shares given to these component to make sure that the mouse moves responsively - while knowing that this will kill the performance.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Windows not forking is not bad engineering? Funny. Architecture falls under engineering as well, you know.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
More specifically, why are OSes not designed, and computing hardware not designed, so that the GUI cannot be slowed down by other slow processes, process switching, or I/O / virtual memory thrashing.
That's why OSes such a Linux (not even over-optimized for responsivity) have an entire zoo of CPU schedulers and IO schedulers.
(with BFQ being the latest popular IO scheduler for responsivity),
and linux specifically has hte non-POSIX "CGROUPS" extension that enables it to arrange the various processes into a tree hierarchy with each node supporting its own scheduling tactics between its childern (see demos of 256 GCC compiler jobs launched in parallel and the GUI still being responive).
(That's also part of the reasons why modern complex manager like systemd are getting popular, they have modules to handle all this : session, seats, etc. concepts that POSIX lacks)
BeOS was an OS whose entire purpose was exactly that : no matter what, keep UI responsive and avoid media stuttering.
(Well, running initially on architecture with less expensive context switches did also help a lot).
The UI and user input devices should be a completely separate set of processes and memory than the rest of application processing.
Actually, in most OSes, they already are.
It should operate as a service, through data pipelines, to the rest of the applications.
That's a tiny bit less obvious. Some graphical tool-kits run their UI in the main thread.
Some software would need to have the processing moved into a background thread or process.
WebApps are an obvious counter-exemple where the UI is an entirely different process (And depending on where the sever is executed - even different machine).
Or failing that, certain aspects of GUI, such as program kill controls, should be highly prioritized over pretty much everything else.
Again, slow and over-used everything else should not slow the UI and user input processes.
And then you'd complain that any complex calculation (compression of a video) takes ages, because the process is constantly being interrupted to give time to your GUI and mouse (i.e.: to the various driver and daemons and libraries processing USB and/or Bluetooth) even if they don't need.
Balancing responsivity (i.e. constantly interrupting everything just to be sure that everyone get their share of CPU cycles and IO) and performance (running as much un-interrupted as possible so the task finishes as fast as possible) is a complex dark art.
But, yeah, Windows is significantly worse at this compared to everyone else.
Which also explains you'll never see any deployment of Windows on the TOP500 (it's nearly Linux all the way, with a few excption like BSD - i.e. other Unix-type of OSes), and Azure is the only known cloud running it.
It's also why Linux is popular in most embed systems (modems, routers, smartphone, tons of IoT gizmos, smart TVs, etc. - basically nearly anything with a CPU that is not a desktop computer is likely to run some Unix-like kernel like Linux)
It's not that Linux is magic, it's that Windows is *THAT* awfully bad at anything.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Nope, I have dedicated hardware fifos for audio on the "sound card".
And if you are streaming audio from the Internet, does your sound card also have dedicated hardware to set up a TCP/IP stack...?
If I'm moving the mouse enough to toss the filesystem while committing to disk, then I have a poorly built file system in need of replacement.
Yes, that was exactly my point. Your filesystem is one of the responsibilities of the kernel, and it is impacted by kernel scheduling just like every other kernel subsystem. You do want your filesystem to be able to handle atomic commits to disk, so the kernel scheduler has to allow that.
Highest priority in a desktop should be UI with ability to pop up a limited system control panel to nuke bad behaving programs/processes/services.
I would argue that if you need a special UI dedicated to nuking bad behaving processes, you have a fairly poor operating system design in general.
Although not perfect, I think Linux gets the balance about right. The completely fair scheduler does round-robin load balancing of processes and threads on the available CPU resources, while also doing its best to avoid context switches. It has a heuristic to determine whether a process that has suddenly asked for CPU time should be allowed to preempt other processes, so that it can have acceptable responsiveness while under load. The end result is that if you are doing a build or crunching a data set in the background, you can still operate the UI and check your email, albeit sometimes with a little bit of lag. The alternative would be to make the UI crisp and smooth at all times, but then you would be taking a bit hit in performance on your background computations. The Linux kernel can and does occasionally deadlock, but it is a fairly rare circumstance in my experience and is not usually a failure of the scheduler.
posix_spawn still does the fork/exec. It is a library function after all, not a system call.
That's true on FreeBSD, and I think it's true on Linux. It's not true on NetBSD, XNU or Solaris, and I don't think it's true on AIX either. posix_spawn was designed to be possible to implement as a library routine, but (particularly in the presence of threads) it's much more efficient to implement it in the kernel.
And it doesn't take as long as you seem to think to mark things COW.
On a system designed for it, no it's not terribly expensive (though the IPIs required for synchronising the page tables across multiple cores actually add quite a bit to the cost on modern hardware), but on a kernel not designed for fork (such as Windows NT), it's expensive to do it post factor.
It only marks open file descriptors, not devices. A much shorter list. Usually only three, stdin/stdout/stderr. There can be more though, but rarely over 5.
Not even slightly true.
One of the reasons Windows isn't used for supercomputers
And that's where I can tell that you have no idea what you're talking about. Thread creation time is completely irrelevant to supercomputing (as are most OS processes). Supercomputing workloads aim to spend 100% of their time in the userspace code that's actually solving the problem. They usually run the entire network stack in userspace to avoid kernel entry (Infiniband has supported this for decades, modern Ethernet NICs do now for low-end systems), set one thread per core, pin it, and avoid entering the scheduler. They also typically try to avoid any I/O. There are several reasons why Windows isn't used in supercomputers (license fees, difficulty of customisation by third parties), but that's definitely not one of them.
I am TheRaven on Soylent News
Sure, it definitely helps when your OS can be extremely specialized towards a specific task. BeOS was designed for the explicit purpose of being a multimedia desktop platform, and it did what it did very well. But there were a lot of things it did not do.
I heard this differently: that the database /. uses is currently in ISO-8859-1, and would need to be migrated to UTF-8; the front-end can be switched between both.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
It depends how you define CPU, and I think Rutulian was defining it as a single core, in which case he's actually mostly right. I mean, now we have hyperthreading, which can attempt to execute two threads, but stalls when the execution paths of both threads would cross, so that it can decide which thread should be allowed to execute first. This happens more often than you might imagine, so the performance boost can be anywhere from absolutely none at all, all the way up to nearly double. That is to say, a CPU (core) with hyperthreading can execute, on average, just under 1.5 threads per cycle.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It will STILL take thirty seconds to show a list of files in a folder.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
...you will have a quantum computer and the mouse will still get stuck.
When that happens the mouse will behave erratically because you are observing the pointer.
This. Bad engineering more often reflects bad management than bad engineers. Of course, if they live under bad management long enough, a good engineer will eventually become a bad one.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Like I said, an oversimplification. There may be multiple CPUs, but there is only one kernel. There is one kernel because those multiple CPUs have to share memory, an i/o bus, and all of the rest of the hardware in the system. The kernel's responsibility is to manage which processes get access to which hardware resources at any given time. More (or faster CPUs) aids in the performance of CPU-bound processes, but does nothing to help, and often hurts other resource sharing requirements, including the i/o bus and interprocess communication.
I read the title and thought it was about the Disney corporation.
This problem exists in both Windows Server 2012 AND Windows Server 2016. It's annoying as hell.
I do not respond to trolls (AKA Anonymous Cowards)
Win7 was NT based... Win10 is WinME with new shell... (that's how they managed to get Win10 much more memory/power efficient than a whole previous generation of NT based Windows).
Highest priority in a desktop should be UI with ability to pop up a limited system control panel to nuke bad behaving programs/processes/services.
How about "Press [BREAK] to pause the system and open a debug prompt" Which then has commands available to show process statistics,
terminate any process, set breakpoints, or Read/Modify any memory address on the system ?
Bad engineering is *always* the fault of bad management, no exceptions. It's management's job to manage the engineers, and identify and fire the bad ones, while facilitating the rest and ensuring their time is productive. Engineers have no power; only management does, so management gets 100% of the blame for the outcome.
That falls apart when considering a lone engineer...
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Aren't there Linux-based soft realtime OSs that are still pretty close to Linux?
Frankly very few people care if their GUI stutters. Heck I would go the opposite, I'd complain if the GUI was prioritized over something more important that a computer may be wanting to do.
You must hang with an odd crowd. On a desktop machine, nothing is more important that the UI being responsive - because nothing happening on the box is more important than me, the user. A server is very different, of course.
The UI needs realtime "slice" big enough to remain always responsive. On a modern system, that shouldn't take much as a percentage of resources, but the maximum latency between UI thread dispatches needs to be kept in check.
Socialism: a lie told by totalitarians and believed by fools.
This is why I never like to comment by phone. Autocorrect decided I didn't want to use a verb in my sentence.
1 core to rule them all, 1 core to find them,
1 core to bring them all and in the darkness bind them
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Aren't there Linux-based soft realtime OSs that are still pretty close to Linux?
Yes though. I can't say I've ever run X on one, and if I did I sure as hell wouldn't want the GUI to take priority over anything.
On a desktop machine, nothing is more important that the UI being responsive
Being responsive 100% of the time, and the occasional stutter at full load are two very different things. There's a lot of things to call Windows and X11, but unresponsive is not one of them.
I actually think quite the opposite. I like the idea of the UI stuttering at full load. At least that provides a visual queue that something in the system is going on and that it has been given priority.
The UI needs realtime "slice" big enough to remain always responsive.
I need to disagree with that. The UI needs to be responsive, but not always 100% responsive.
There is an element to truth in what you say though, the UI ALWAYS needs to remain responsive enough to allow you to recover from a bad situation. The mouse stuttering at full load, no big deal, the mouse frozen, the task manager not coming up, and being unable to kill a process because the UI isn't working on the other hand is a complete no-go.
Comment removed based on user account deletion
What does docking have to do with the OS?
I sure as hell wouldn't want the GUI to take priority over anything.
On your personal desktop? Why on earth not? It's there for you. When gaming, I want the game to run as well as possible; when editing something, I want the editor to be as smooth as possible.
Being responsive 100% of the time, and the occasional stutter at full load are two very different things. There's a lot of things to call Windows and X11, but unresponsive is not one of them.
What is the "occasional stutter" if not "briefly unresponsive"? I guess I see what you mean, farther down. I see Windows become intermittently unresponsive to mouse and kb input under heavy I/O load somewhat regularly, and I find it quite annoying. Not just the mouse stuttering, but clicks getting dropped,windows not gaining focus, that sort of thing.
Socialism: a lie told by totalitarians and believed by fools.
More specifically, why are OSes not designed, and computing hardware not designed, so that the GUI cannot be slowed down by other slow processes, process switching, or I/O / virtual memory thrashing.
The same reason all browsers will run all scripts unless you stop all scripts or install an addon that makes script handling more sane: You do not matter. The hardware matters. The software matters. The business trying to get money from you matters. Everyone/everything matters but you. It is incredibly obvious; otherwise, things would be different. The reason you do not matter is because there are 7 billion more just like you.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
'm glad you've volunteers to help with their concurrency programming. Good luck, it's not easy.
I am not entirely certain why I feel like being so rude here... but, shut the fuck up.
Lots of things are not easy and yet they are done on a daily basis anyways. That is not an excuse that is tolerable. Microsoft can easily afford the smartest people on this planet to solve such an issue and they do not even have to share how they did with other people! Hurray for closed source software right?
Such mealy mouthed excuses are unbecoming of a person on Slashdot. Some of us have written software that is guiding a robot on Mars. Some of us have written software that is behind some of the strongest AI on this planet. Some of us have done scientific research that makes dealing with concurrency look like childs play.
And you want to throw out the excuse of "it's not easy"? Really? You did not think you would get called out on such bullshit? By people who have done concurrent programing?
Whatever. I should not have been rude. Carry on kind sir. Life is not easy.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
News flash: Microsoft can afford the smartest people on the planet. The smartest people on the planet also find this stuff hard.
ps: I write software for a living
Congratulations on blowing your own horn?
Windows has many single-threaded allocators and still does polling for some desktop functions.
Compare this to linux where I can run a kernel build saturating 12 cores for a few minutes, that has no effect on linux UI performance. This is due to the scheduler that is able to separate out cpu-intensive loads from interactive loads allowing their scheduling to be optimized.
It's not true that cpus only execute single threads per "cycle". Today's cpus -- not running "hyper-threaded", still execute several threads in parallel due to speculative execution. On top of that, there are many HW processors in a modern computer other than the cpu -- audio, graphics, multiple-IO processors are just a few. It's evident that windows does polling when you suspend a background process and it causes long desktop lockups -- that just doesn't happen on linux.
On your personal desktop?
Huh? You brought Linux based RTOS into the conversation. No definitely not n the desktop. Why would I run that on the desktop. Please don't switch contexts.
What is the "occasional stutter" if not "briefly unresponsive"? I guess I see what you mean, farther down. I see Windows become intermittently unresponsive to mouse and kb input under heavy I/O load somewhat regularly, and I find it quite annoying. Not just the mouse stuttering, but clicks getting dropped,windows not gaining focus, that sort of thing.
Speaking of context I'm still talking in terms of the general person here. That "odd" crowd I hang with are the normal people who rarely if ever find their computers even remotely placed under load unless one of their browser tabs is misbehaving or they downloaded some bitcoin mining malware.
I agree for the power user it would be quite irritating, but that makes up only the tiniest portion of the user base.
If your mouse won't move, try applying some cleaning product to your desktop. In the future, drink less Mt. Dew and find a sock to use for watching Redtube.
https://www.eff.org/https-everywhere
Ah, you missed the point of my original post - perhaps I was unclear. I'm so hardcore about wanting a responsive UI that I'd like a Linux-based RTOS (at least, soft realtime) just to guarantee a consistently responsive UI.
And you'd be surprised how many unsophisticated users have their system under heavy load - the multiple random antivirus and anti-malware programs can create a heavy load, especially when coupled with the malware that got in anyway.
Socialism: a lie told by totalitarians and believed by fools.
Fair comment. My point was to attempt to explain why scheduling by the kernel is necessary, why kernels need to use locks, and why there are trade-offs in deciding which processes/threads to execute when. But I left out a lot of details, hence the "oversimplified" qualifier at the beginning of my comment. Agree that Linux has generally better scheduler performance overall when compared to Windows. Linux has had the benefit of being able to go through quite a few radical scheduler changes over the years with accompanying changes to the various locks. While the Windows kernel team can probably do some, they are definitely not able to be as flexible with the internals as Linux.
Point taken, but not quite sure why you felt it necessary to be so rude in your rebuttal. Yes, I described a gross oversimplification in order to keep my comment short, simple, and to the point: kernels need to do scheduling.
However, modern operating systems could at least give soft realtime guarantees
And while Linux does this to some degree, you already described the trade-off.
it's because kernels with realtime scheduling are slower
Getting a real-time guarantee will help responsiveness, but at the cost of performance, which is the essence of what I said in my above comment.
No, it doesn't. The lone engineer is doing two jobs: engineering and management. So management is still to blame.
The scheduling algorithm in Linux is also configurable. Microsoft could make the choice to allow alternate schedulers without changing the default schedulers. They *could* be alot more creative and flexible in what they allow, but they have little to no incentive to do so.
They forced Win10 down people's throats complete with forced updates and advertising. They need only look at Adobe's huge rise in profitability as they moved to a subscription-only model that Adobe moved to because they couldn't be troubled to produce products anymore that would motivate people to upgrade and/or buy. Microsoft is in a similar position -- new development costs too much -- they desktop dreams of Bill Gates introducing use of 3D graphics and relational file system for information processing and presentation never materialized, with Win7 being MS's pinnacle of desktop systems as the masses are separated from their general purpose creativity stations (PC's), and are given consumer devices that need cloud (read "mainframe") support again that will be time shared just like computer systems in the 70's.
Sorry, guess I veered off from MS's lack of incentive to improve technological innovation or attempt excellence into market directions. Remember the movie "Pirates of Silicon Valley", where Gates claimed he had won? Did he?
Rest assured, that your finding have been forwarded to Microsoft's legal team. Expect a cease and desist letter soon. If you do not desist, Microsoft will explore further legal actions to stop you investigating this problem, and others in the future. Even if Microsoft cannot find a legal reason to stop you, they will just sue you into the ground
Thank you for using Microsoft. Remember, our code does not have any bugs, only features.
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
Good luck getting WinDOS to run in Long Mode.
And on the Eighth Day, Man created God.
It's a good thing we now have really powerful GPUs to make the GUI of newer systems as fast as the GUI on older systems which lacked powerful GPUs. Imagine how slow the GUI would be if we were still using 2D accelerators.
Nah, I have a learning disability that makes me horrible at most simple problems. Anyone can do what I do, I have several learning disabilities. I have a horrible general memory, just functional enough to get by in life. 6 months to remember my wife's name.
I guess you could say some mentally disabled person who barely passed school wonders why people with no learning disabilities find concurrency so difficult.
I'm not very good at the maths behind it all. I mostly just have a strong intuition. Doesn't make for very good PHD material, but pretty decent for in practice.
On the other hand, one of the best theoretical astrophysicists has a disability that does not allow her to do simple math like arithmetic or algebra, but she is a genius at calculus.
BeOS seems to have a complex mess of clones, derivatives and reimplementations, so I see there might be a minefield of IP issues to navigate.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Then whoever is responsible for maintaining that whitelist is really, really incompetent and unresponsive to user comments. Where's Rei when you need him, with his comment about not being able to type his name, which includes a thorn letter. And the number of times I get Cyrillic script mangled by the back-end ... it's going to get worse when I start learning Arabic.
I never knew about Slashdot Japan. As a Go player (note the incorrect letter "o" in that name), I would have liked to see some evidence of correct handling of any of the Japanese scripts.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Actually, you can. The Linux CPU scheduler is pluggable by design, and several schedulers are available to choose from in the stock kernel. Con Kolivas was an active kernel developer for many years with a vested interest in improving kernel latency. He was one of the prime motivators behind a redesign of the scheduler to make it more suited for desktop use. And even after he stopped working on the main kernel, he maintained a few of his own out-of-tree patches, including the infamous Brain Fuck Scheduler (BFS). You can read about it here,
http://ck.kolivas.org/patches/...
The main argument between CK and the rest of the kernel team was that CK wanted extremely good latency in the linux kernel, and he wanted to set it up in a way to be configurable, so you could purpose a machine for a specific task (desktop or server) with different priorities. The main kernel team (Linus, Alan Cox, Greg Kroah-Hartman, Ingo Molnar, etc) wanted a more elegant solution. They wanted an intelligent CPU scheduler that could scale well depending on the load and hardware capabilities, with the idea being that a sysadmin should not have to think too much about it. A mainframe has very different hardware, but it also is used for a very different purpose, from a desktop machine, so the kernel should be able to realize that and figure out what it needed to prioritize. There were a few tuning variables exposed, but it was not supposed to require an extensive configuration. Also, they specifically had the developer workstation in mind when they were working on the scheduler. That is, they were considering situations where a user likely wanted both interactivity and throughput performance. The best of both worlds as best they could manage. They went back and forth a few times until CK finally got frustrated and left, because he didn't think it was possible.
So, there is BFS, and it probably still can be used to patch the stock kernel, but CK didn't design it to be pluggable. So if you patch your kernel with it, you will lose the other options, like the Completely Fair Scheduler (CFS). However, this thread on Stack Overflow might be a good resource if you are either interested in writing a new scheduler, or you want to modify BFS to be pluggable.
https://stackoverflow.com/ques...
And, I was Googling a bit and found that CK is apparently working on another scheduler (MuQSS) which he is intending to be the successor to BFS,
http://ck-hack.blogspot.pt/201...
In the end, though, while CFS is not as good as BFS at latency, it strikes a pretty good balance. And GKH has been working on soft realtime patches to the kernel for a number of years that are slowly getting incorporated into the main branch. So Linux is pretty good in general; much better than it was when CK first started his work. Here is an old, but nice, comparison of the two schedulers,
http://cs.unm.edu/~eschulte/cl...
This is a school example of how [not] to use synchronization mechanisms. A total lockup of a trillion-core system is easily achieved if the programmer doesn't understand the implications of when to use locking and when not to. Of course it's appealing to use sometheing like a semaphore to solve some problems. But when thinking BIG you have to employ a different way of thinking. Not an easy feat.