24 Cores and the Mouse Won't Move: Engineer Diagnoses Windows 10 Bug (wordpress.com)

/sarcasm But can he call himself an engineer ? by UnknownSoldier · 2017-07-11 12:19 · Score: 0

*rimshot at Oregon retards*

Windows... by Anonymous Coward · 2017-07-11 12:22 · Score: 0, Insightful

Well... there's your problem.

Re:Windows... by presidenteloco · 2017-07-11 12:52 · Score: 5, Insightful

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?
Re:Windows... by Anonymous Coward · 2017-07-11 13:08 · Score: 1

Probably a dumb question... Is there such a thing as firewalling or sandboxing a GPU for that?
Re:Windows... by viperidaenz · 2017-07-11 13:15 · Score: 3, Insightful

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.
Re: Windows... by Anonymous Coward · 2017-07-11 13:27 · Score: 1

Yeah except the issue doesn't exist in 7 so they can just roll back this very tiny part of Windows.
Re:Windows... by Anonymous Coward · 2017-07-11 14:13 · Score: 0

No need to go down the level of concurrency problems. Just set the user quota (i.e. CPU, GPU, disk space, RAM) to never use more than 98% of all system resources. The remaining 2% should only be used by SYSTEM in those rare cases where the GUI, RAM, CPU and I/O starts trashing and swapping like hell.
Then when quota is set properly, your OS can defend itself against fork bombs too.
Re:Windows... by jimtheowl · 2017-07-11 14:15 · Score: 2

That is similar to question I asked while using Windows NT.

It is how I got into UNIX.
Re:Windows... by sydbarrett74 · 2017-07-11 14:34 · Score: 1

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
Re:Windows... by Rutulian · 2017-07-11 14:49 · Score: 3, Informative

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.
Re:Windows... by dwywit · 2017-07-11 14:53 · Score: 1

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
Re:Windows... by mikael · 2017-07-11 15:12 · Score: 2

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
Re:Windows... by Anonymous Coward · 2017-07-11 16:36 · Score: 0

remove the target= from the URL to get it to work.
better
Re:Windows... by Anonymous Coward · 2017-07-11 17:06 · Score: 0

I would think you could still accomplish this end result on Windows... just make sure that when you start one of these build processes (or sub processes) that you don't start the process directly... but use "start /LOW"... though perhaps the frequent start/stop nature of start.exe would result in the same outcome.
Re: Windows... by Anonymous Coward · 2017-07-11 19:10 · Score: 1

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.
Re:Windows... by Anonymous Coward · 2017-07-11 19:25 · Score: 0

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.
This answer is completely wrong, though.
Re:Windows... by blind+biker · 2017-07-11 20:18 · Score: 1

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.
Re: Windows... by TheRaven64 · 2017-07-11 21:52 · Score: 4, Insightful

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
Re:Windows... by swilver · 2017-07-11 23:04 · Score: 2

...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.
Re:Windows... by lordmage · 2017-07-11 23:33 · Score: 1

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!!
Re:Windows... by Bengie · 2017-07-12 00:42 · Score: 1

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.
Re: Windows... by Rutulian · 2017-07-12 01:18 · Score: 1

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.
Re:Windows... by Rutulian · 2017-07-12 01:28 · Score: 1

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.
Re:Windows... by thegarbz · 2017-07-12 01:48 · Score: 0

You say "not even Linux" whereas Linux is an example of one of the worst throwbacks to ancient cruft in the name of not changing something that exists. When there is an attempt to fix this every bearded man and their dog come out of the basement complaining that {insert new thing} doesn't have {obscure feature} and that it is "change for change's sake" without actually understanding the design intent.
The "problem" is that there are far more important design goals for an OS and a GUI than to draw itself smoothly, and one of the key ones is not breaking compatibility.
I used inverted commas because 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.
Re:Windows... by Anonymous Coward · 2017-07-12 02:34 · Score: 0

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.
Wait... He had 24 core processor. It can run 24 processes at the same damn time.
Re:Windows... by BronsCon · 2017-07-12 02:41 · Score: 2

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.
Re:Windows... by Rutulian · 2017-07-12 02:52 · Score: 1

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.
Re: Windows... by Anonymous Coward · 2017-07-12 03:00 · Score: 1, Funny

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).
Re:Windows... by Anonymous Coward · 2017-07-12 03:01 · Score: 0

Exactly. As you lay out, the GP is even wrong when you define CPU in the most idiotic way possible. But there is no need to define CPUs like that, just define it as everyone else as the thing that sits in a CPU socket and nowadays usually has different cores that process threads in parallel.
Sorry if this sounds like nitpicking to you, but the GP's comment was just too stupid and misleading to leave it standing as is. Even on a single-core CPU system it would be perfectly possible to give realtime guarantees to GUIs - you only need to validate the software in conjunction with the minimum hardware. The reason this is not done has nothing to do with CPUs or cores, it's because kernels with realtime scheduling are slower and because in order to make the timing guarantees work you need deterministic resource management all the way down. That's for hard realtime guarantees. However, modern operating systems could at least give soft realtime guarantees, which would be enough to make them snappy on fast-enough hardware. To cut a long story short, the reasons GP gives are plain and simple bullshit. There is no principal technical reason why GUIs would have to become sluggish under heavy load. It's just the result of the way the operating systems and windowing frameworks have been designed.
Re: Windows... by mysidia · 2017-07-12 03:25 · Score: 1

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 ?
Re:Windows... by Anonymous Coward · 2017-07-12 04:35 · Score: 0

In an intro to operating systems course I once listened to (UC Berkeley, Professor John Kubiatowicz), it was discussed that the kernel is supposed to allocate CPU cycles. Students implemented this in their toy Minix systems they were building. Excuse my ignorance, but what is so difficult about forcing the kernel to always reserve a certain number of cycles over a given time period to the GUI so that the mouse always responds?
Re:Windows... by Anonymous Coward · 2017-07-12 04:57 · Score: 0

If you don't have one already, you should do a CS PhD and push yourself further. There are a lot of real problems that are being tackled right now, and insight is being sought from mathematics (new and old) as well as CS, and you might enjoy tackling one.
Re:Windows... by lgw · 2017-07-12 05:11 · Score: 1

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.
Re: Windows... by Anonymous Coward · 2017-07-12 05:35 · Score: 0

Adding a mutex isn't the correct fix either, it's pure laziness.
Re:Windows... by thegarbz · 2017-07-12 05:54 · Score: 1

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.
Re:Windows... by lgw · 2017-07-12 07:26 · Score: 1

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.
Re:Windows... by strikethree · 2017-07-12 07:45 · Score: 1

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
Re:Windows... by strikethree · 2017-07-12 07:52 · Score: 1

'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
Re:Windows... by viperidaenz · 2017-07-12 08:17 · Score: 1

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
Re:Windows... by viperidaenz · 2017-07-12 08:20 · Score: 1

Congratulations on blowing your own horn?
Re:Windows... by lpq · 2017-07-12 08:34 · Score: 1

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.
Re:Windows... by thegarbz · 2017-07-12 08:43 · Score: 1

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.
Re:Windows... by lgw · 2017-07-12 09:33 · Score: 1

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.
Re:Windows... by Rutulian · 2017-07-12 09:46 · Score: 1

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.
Re:Windows... by Rutulian · 2017-07-12 10:06 · Score: 1

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.
Re: Windows... by Anonymous Coward · 2017-07-12 18:55 · Score: 0

Hahaha, that's a good one. I have an 8 core workstation with 32gb of ram. Since Linux kernel 3.8 I can't copy files and use the mouse at the same time
Re: Windows... by Damouze · 2017-07-12 20:07 · Score: 1

Good luck getting WinDOS to run in Long Mode.

--
And on the Eighth Day, Man created God.
Re:Windows... by Agripa · 2017-07-13 06:29 · Score: 1

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.
Re: Windows... by Anonymous Coward · 2017-07-13 10:23 · Score: 0

No you moron, process priority does not affect how a lock in kernel mode is acquired.
Re:Windows... by Bengie · 2017-07-13 14:46 · Score: 1

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.
Re:Windows... by Bengie · 2017-07-13 14:53 · Score: 1

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.
Re:Windows... by RockDoctor · 2017-07-15 00:37 · Score: 1

Since you seem to know more about this than most, can you puzzle this for me. If the scheduling in BeOS was so much better (well, differently prioritised) than in the stock Linux kernel), is there anything fundamental to prevent someone writing a BeOS-like scheduler and plugging that into the Linux kernel instead of the stock kernel. Obviously it would need a recompile of the kernel to incorporate into the boot image, but ... I don't see why it couldn't be done.
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"
Re:Windows... by Rutulian · 2017-07-15 12:41 · Score: 1

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...

Re:Not just when closing a program by Plus1Entropy · 2017-07-11 12:28 · Score: 2

Not a program, a process.

--
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.

The lock cycles were avg 200 us each by Anonymous Coward · 2017-07-11 12:30 · Score: 5, Informative

Not 200S each, which is off by a factor of one million. But, hey.

Re:The lock cycles were avg 200 us each by Anonymous Coward · 2017-07-11 13:04 · Score: 0

200 us? Sounds like some sort of metric. What is that in american?
Re:The lock cycles were avg 200 us each by viperidaenz · 2017-07-11 13:11 · Score: 1, Informative

5 thousandths of a second
Re:The lock cycles were avg 200 us each by vux984 · 2017-07-11 13:26 · Score: 2

er no...
2 us is 200 millionths or 0.0002 seconds.
in fractions that would be 2/10,000ths; 1/5000th
It is important to note that 5 thousandths is NOT the same as 1/5000th; 5/1000ths would be 0.005 seconds; which is out by a factor of 25.
But simply expressing it as a fraction isn't american enough. It should be like their wrench sizes... so 200 us is about 7/32768ths second.
Re:The lock cycles were avg 200 us each by Narcocide · 2017-07-11 13:30 · Score: 1

It's actually "& # 181 ; "s (microsecond) but Slashdot eats the character.
Re:The lock cycles were avg 200 us each by D.McG. · 2017-07-11 13:41 · Score: 1

Not quite. You're off by two orders of magnitude.
A millisecond (ms) is 1 thousandth of a second (0.001) or 1/1,000
A microsecond (us) is 1 millionth of a second (0.000001) or 1/1,000,000
Re:The lock cycles were avg 200 us each by Dunbal · 2017-07-11 13:54 · Score: 1

Microseconds. u is typically used by non unicode internet types to represent the Greek letter Mu which is the internationally recognized symbol for "micro" or 1 millionth. Nerd card revoked, btw.

--
Seven puppies were harmed during the making of this post.
Re:The lock cycles were avg 200 us each by vux984 · 2017-07-11 14:04 · Score: 0

Not quite. You're off by two orders of magnitude.

200 us = 200 microseconds = 200 millionths of a second.
200/1000000 second = 1/5000 second, which is exactly what I said...
Re:The lock cycles were avg 200 us each by vux984 · 2017-07-11 14:10 · Score: 1

ah i see i -did- have a typo; as per the thread topic, the subject is 200 microseconds, which is the number i had in my head and worked through with all the maths.
However i wrote down '2 us' instead of '200 us' when i started my post. That was just a typo -- i knew it was 200 us.
Re:The lock cycles were avg 200 us each by viperidaenz · 2017-07-11 15:11 · Score: 0

The world should stick to metric.
200uS is one five thousandth of a second
Re:The lock cycles were avg 200 us each by Bing+Tsher+E · 2017-07-11 15:34 · Score: 0

I never use 'extended' coding because five years from now when I need to look back at the information saved with extended coding, the coding has changed and you get nonsense units. You get *cryptic-non-character* garbage that simply amounts to information loss. So I use a lower case 'u' for Micro, which everybody can interpret.
Sorry for being an ascii redneck. Years of experience has validated my attitude to me.
Re: The lock cycles were avg 200 us each by UnknowingFool · 2017-07-11 16:56 · Score: 2

What are you taking about? UTF-8 is over 20 years old. HTML is even older. It's one thing not to use the newest emoji but to say you won't use encodings that haven't changed in 20+ years because they might change in the future isn't a great reason.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re: The lock cycles were avg 200 us each by Anonymous Coward · 2017-07-11 18:03 · Score: 0

200 us in american = 200 USA rah rah rah (approx).
Re:The lock cycles were avg 200 us each by Anonymous Coward · 2017-07-11 18:23 · Score: 0

200 us? Sounds like some sort of metric. What is that in american?
In many scientific applications (read, stuff done on a computer) microseconds are written as "us" because there is no way to write a mu in ASCII. It's a bit unfortunate that this is the subdivision of a unit that uses a non-latin based letter as a prefix.
Re: The lock cycles were avg 200 us each by sexconker · 2017-07-11 19:20 · Score: 1

What are you taking about? UTF-8 is over 20 years old. HTML is even older. It's one thing not to use the newest emoji but to say you won't use encodings that haven't changed in 20+ years because they might change in the future isn't a great reason.
Yet here we are, in the perfect of example of one encoding not working / not being supported.
ASCII for life.
Re:The lock cycles were avg 200 us each by AmiMoJo · 2017-07-11 19:46 · Score: 1

5 thousandths of a second
That would be 5 milliseconds. 1/1000th of a second is 1 millisecond.
This is 200 millionths of a second, or 1/5th of a thousandths of a second.
This is also why engineers prefer engineering notation, so 200us or 200x10^-6. I wish more calculators supported engineering units.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:The lock cycles were avg 200 us each by Shimbo · 2017-07-11 19:55 · Score: 2

The world should stick to metric.
200uS is one five thousandth of a second
Actually, it's one five thousands of a Siemen; case matters. I guess this whole newfangled upper and lower case thing is too hard for those writing their posts on an ASR-33.
Re: The lock cycles were avg 200 us each by gnasher719 · 2017-07-11 20:47 · Score: 1

What are you taking about? UTF-8 is over 20 years old. HTML is even older. It's one thing not to use the newest emoji but to say you won't use encodings that haven't changed in 20+ years because they might change in the future isn't a great reason.
Especially when Unicode guarantees that these characters are _not_ going to change.
Re:The lock cycles were avg 200 us each by Hognoxious · 2017-07-12 01:08 · Score: 1

I'd write it out in full, just to avoid ambiguity.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Re: The lock cycles were avg 200 us each by UnknowingFool · 2017-07-12 02:11 · Score: 1

If it isn't supported here on this site, then you can't use the encoding, therefore 5 years from now, it won't be cryptic. If the site supported Unicode, the code itself does not change.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re: The lock cycles were avg 200 us each by tepples · 2017-07-12 03:07 · Score: 1

These characters won't change. But new characters will be added, and if these new characters are directionality controls, they might break Slashdot's layout.
Re: The lock cycles were avg 200 us each by UnknowingFool · 2017-07-12 04:07 · Score: 1

How will new characters break Slashdot's layout when Slashdot doesn't accept Unicode. Also if Slashdot accepted Unicode, why would someone use new characters that haven't been added yet?

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:The lock cycles were avg 200 us each by Anonymous Coward · 2017-07-12 04:49 · Score: 0

It's a bit unfortunate to not support a simple greek letter. ASCII could have dumped a couple useless control characters 50 years ago and made room for it.
There is a mu key on French keyboard, and the letter is in DOS code page 850 (sort of supports Western Europe)
https://en.wikipedia.org/wiki/...
Wait, it's in the default code page, 437
https://en.wikipedia.org/wiki/...
It's also in ISO-8859-1 ! and Windows-1252.
Perhaps 8-bit ASCII from the IBM PC, or DOS/Windows extended ASCII are not necessarily where you should derive your list of most Internet-safe characters from but it's a small oddity that mu is not supported.
Re: The lock cycles were avg 200 us each by tlhIngan · 2017-07-12 05:07 · Score: 1

How will new characters break Slashdot's layout when Slashdot doesn't accept Unicode. Also if Slashdot accepted Unicode, why would someone use new characters that haven't been added yet?
Go back to over a decade and /. DID support Unicode. People were using it to break the page a lot, and it go so bad that every article's comments were overrun with people doing nothing but breaking it.
The least damage they did was use the RTL overrides to "moderate" their discussions - google for examples of "5 :erocS" ("Score: 5" backwards) and you'll see those examples. Do it right and you can appear to troll and get a +5.
They implemented the blocks shortly after that.
And people will use characters once they're added to Unicode, but likely before the blacklist is updated. Especially the moment some browser supports it (mobile or otherwise).
Re: The lock cycles were avg 200 us each by tepples · 2017-07-12 05:08 · Score: 1

How will new characters break Slashdot's layout when Slashdot doesn't accept Unicode.
As I understand it, Slashdot doesn't accept Unicode precisely because of the threat of newly introduced code points that affect directionality. I was referring to the hypothetical situation in which Slashdot were to switch on Unicode with a blacklist for currently existing code points that affect directionality, as an explanation of why Slashdot doesn't accept Unicode.

Also if Slashdot accepted Unicode, why would someone use new characters that haven't been added yet?
In the hypothetical situation, the following events would occur in order:
1. Slashdot updates a blacklist to block all currently existing code points that affect directionality and enables Unicode.
2. Unicode Consortium releases a new version of Unicode including new code points that affect directionality.
3. GUI frameworks and web browsers are updated to support these new code points, but Slashdot is not because its administrators are occupied with other, more pressing aspects of site operation.
4. Someone uses one of the new code points that affect directionality but are not on the blacklist, causing the layout of Slashdot's comment section to break.
Re:The lock cycles were avg 200 us each by Dunbal · 2017-07-12 07:23 · Score: 1

Which is still a metric scale. American scales are based on 1/3, 1/4, 1/12, 1/16, etc.
Not my problem if America refuses to catch up with the rest of the world. Sure, you might not need to know the metric system to put a few gallons of gasoline into your car or buy a pound of beef. Serious science and tech stuff is all done in metric, nowadays. Even in the US. Call me when you run into a 5.51181 x 10^-7 inch scale CPU.

--
Seven puppies were harmed during the making of this post.
Re: The lock cycles were avg 200 us each by UnknowingFool · 2017-07-12 07:52 · Score: 1

1. Slashdot updates a blacklist to block all currently existing code points that affect directionality and enables Unicode.
2. Unicode Consortium releases a new version of Unicode including new code points that affect directionality.
So you're relying on a hypothetical where the Unicode Consortium releasing a new version of Unicode but you're also ignoring the fact that there are current portions of Unicode which haven't changed in 20 years and that Unicode adds new characters but does not change existing ones.

3. GUI frameworks and web browsers are updated to support these new code points, but Slashdot is not because its administrators are occupied with other, more pressing aspects of site operation.

You do understand that many programming languages and standards like XML and Java rely on Unicode not changing right? Your hypothetical would undermine all of them not just Slashdot.

4. Someone uses one of the new code points that affect directionality but are not on the blacklist, causing the layout of Slashdot's comment section to break.
So someone uses something that isn't approved yet which would break functionality when Slashdot wouldn't accept anyway. That makes no sense.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re: The lock cycles were avg 200 us each by sexconker · 2017-07-12 08:08 · Score: 1

Except people TRY to use the encoding, often unknowingly, and we end up with cryptic barf, dropped characters, etc.
It's cryptic TODAY in many cases.
Re: The lock cycles were avg 200 us each by tepples · 2017-07-13 02:38 · Score: 1

So someone uses something that isn't approved yet which would break functionality when Slashdot wouldn't accept anyway. That makes no sense.
As of step 4, the new code points would have been approved, just not yet blacklisted on hypothetical Slashdot-with-Unicode (HSWU). I guess we disagree on whether HSWU would use a blacklist or a whitelist.
Re:The lock cycles were avg 200 us each by Shirley+Marquez · 2017-07-13 06:10 · Score: 1

To be pedantic, it's 1/5000 of a Siemens; note the S at the end. The unit is named for a person and so it always has the S, whether it's singular or plural.
Re:The lock cycles were avg 200 us each by RockDoctor · 2017-07-15 00:54 · Score: 1

I wish more calculators supported engineering units.
For anything more than a 4-function calculator for decorating calculations, I just use an application on my phone.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Re: The lock cycles were avg 200 us each by RockDoctor · 2017-07-15 01:03 · Score: 1

Except people TRY to use the encoding, often unknowingly,
This user for one, often uses the CORRECT encoding KNOWING that it will be misprepresented by Slashdot.

and we end up with cryptic barf, dropped characters, etc.
Which is a desired outcome, being short hand for a statement to the Ever-Changing Overlordship that "you claim to be 'news for nerds', but you can't even do the basic task of handling users nerdish input properly.
To be honest, it would be less frustrating if Slashcode would just decompose character entities it doesn't recognise with whitespace, instead of variably dropping them, prepending a Capital-A-Acute or otherwise mangling them. "& A E l i g ;" for example, if I try to start to spell one of my names correctly.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Re: The lock cycles were avg 200 us each by RockDoctor · 2017-07-15 01:07 · Score: 1

Since UNICODE organises things by MSB-determined "pages" (of up to several thousand characters apiece), then there's not an unmanageable filtering problem to reject some problematic "pages" but accept the rest.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Re: The lock cycles were avg 200 us each by RockDoctor · 2017-07-15 01:17 · Score: 1

4. Someone uses one of the new code points that affect directionality but are not on the blacklist, causing the layout of Slashdot's comment section to break.
5. User involved is given a permanent -BIGNUM rating and has the .GT.42char+1hourExpiryResetByEmail rules applied to their password.
OK, then someone needs to do some admin - either editing the database, or just replacing the comment with "this user was a dick" boilerplate.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Re:The lock cycles were avg 200 us each by RockDoctor · 2017-07-15 01:39 · Score: 1

Microseconds. u is typically used by non unicode internet
It's not just microseconds. It's a general prefix-multiplier for any SI unit. I use it all the time for micrometre, as my thin sections are 30um thick.
This remains a bodge. And not a very nice one either. I guess that it dates back to when "milli" was chosen as a multiplier for 1/1000. In hindsight, making the prefixes symmetrical around the base unit, so that a Captial would indicate n * base and the same lowercase would indicate base / n might have been a better idea. But it's a system that has bee developing over 2 and a quarter centuries, so perfect consistency is not really to be expected.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"

The issue apparently doesn't exist in Windows 7. by turkeydance · 2017-07-11 12:31 · Score: 1

7 come 11. Baby needs new shoes.

Windows has always been unresponsive to user input by fustakrakich · 2017-07-11 12:32 · Score: 5, Informative

We just don't have priority...

--
“He’s not deformed, he’s just drunk!”

Oh, that explains a lot by Anonymous Coward · 2017-07-11 12:37 · Score: 0

With extremely minimal effort, I ported a script from Linux to MSYS2 so I could do the same task on Windows machines too. The fork cost was so much higher that it easily ran at 1/50 the speed. There's really no excuse for having such a high fork cost for a console-only application.

Re:Oh, that explains a lot by gweihir · 2017-07-11 13:58 · Score: 1

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.
Re:Oh, that explains a lot by Anonymous Coward · 2017-07-11 16:45 · Score: 0

"MS always had pretty bad engineering."
Bullshit. If MS engineers are so bad why was a lawsuit needed to stop Apple, Google, and other tech companies from poaching their high end engineers? A software company with "bad engineering" doesn't become one of the most successful companies of all time.
Re: Oh, that explains a lot by Anonymous Coward · 2017-07-11 19:18 · Score: 0

He said bad engineering, not bad engineers.
I live in one of these bad engineering companies. The good engineers are working out how much we need to raise to buy out the bad MBAs (too redundant?) so we can turn it back into a good (profitable) engineering company...
Re:Oh, that explains a lot by TheRaven64 · 2017-07-11 22:00 · Score: 2

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
Re:Oh, that explains a lot by Megol · 2017-07-12 00:08 · Score: 1

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.
Re:Oh, that explains a lot by Megol · 2017-07-12 00:09 · Score: 1

Exactly.
Re:Oh, that explains a lot by Anonymous Coward · 2017-07-12 00:11 · Score: 0

posix_spawn still does the fork/exec. It is a library function after all, not a system call.
And it doesn't take as long as you seem to think to mark things COW. Only the data pages are marked, not the entire process map. That is still shared between both processes. It also doesn't take time for paged out entries.
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.
The clone system call on Linux is very fast, and it handles fork/vfork/thread creation... Much faster than Windows can. One of the reasons Windows isn't used for supercomputers.
Re:Oh, that explains a lot by gweihir · 2017-07-12 00:57 · Score: 2

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.
Re:Oh, that explains a lot by TheRaven64 · 2017-07-12 01:22 · Score: 2

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
Re: Oh, that explains a lot by BronsCon · 2017-07-12 02:49 · Score: 1

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.
Re: Oh, that explains a lot by Grishnakh · 2017-07-12 03:55 · Score: 2

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.
Re: Oh, that explains a lot by BronsCon · 2017-07-12 04:43 · Score: 1

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.
Re: Oh, that explains a lot by Grishnakh · 2017-07-12 10:21 · Score: 1

No, it doesn't. The lone engineer is doing two jobs: engineering and management. So management is still to blame.

Re:Windows has always been unresponsive to user in by Anonymous Coward · 2017-07-11 12:39 · Score: 1

Well you should probably stop using Windows 98.

Really? by Anonymous Coward · 2017-07-11 12:43 · Score: 0

This would be unsurprising if all cores were pegged at 100%, but overall CPU usage was barely hitting 50%.

It would be surprising. A faulty hardware causing interrupt storms, a kernel level driver problem or a memory leak issue with slow swap space would be more likely to cause such issues. Although, after the previous cumulative update or the one before that the system have been less fair to the UI (stuttering) under heavy loads even with eight cores. The jury is out yet for the today's patch.

I don't get it. by fuzzyfuzzyfungus · 2017-07-11 12:43 · Score: 5, Interesting

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?

Re:I don't get it. by Anonymous Coward · 2017-07-11 12:54 · Score: 1

GUIs usually don't have clock priority.
Re:I don't get it. by Anonymous Coward · 2017-07-11 12:55 · Score: 4, Informative

The Windows GUI interface actually uses a separate process to update the mouse on the screen. Due to various historical reasons (compatibility with old applications, mostly), it was required to recycle this process every time the mouse moved, as the process could get a memory leak (which couldn't be fixed properly, in order to preserve compatibility with the aforementioned applications). Therefore, every time the coordinates of the mouse change, the process has to be killed and replaced, therefore putting it through the same lock that this build process is hogging. Combine that with the 200 second delay to get through the lock, and the responsiveness is easily explained.
It's worth it to keep compatibility with the "After Dark" flying toasters screensaver, though.
Re:I don't get it. by epine · 2017-07-11 13:11 · Score: 1, Insightful

Combine that with the 200 second delay to get through the lock, and the responsiveness is easily explained.
I didn't believe that number for the first microsecond. Where was your brain? Stuck on "easily explained"?
From the original:

And, if each of these readying events happened after the thread had held the lock for just 200 microseconds then the 5,768 readying events would be enough to account for the 1.125 second hang.
Even Microsoft would notice 24 cores sharing a 200 s group hug.
If the question had been "total number of photons emitted from the sun over the last 4.3 billion years", I would accept +/- six orders of decimal magnitude as constituting a reasonable effort. In this case, not so much.
Re:I don't get it. by Anonymous Coward · 2017-07-11 13:40 · Score: 0

In case you hadn't noticed, the Windows mouse cursor is context sensitive. Move it over a graphic, over text, over a hyperlink, over the edge of a window, and the cursor changes.
If a process shutting down affects what's on the screen, then the mouse cursor may have to change to keep up.
Re:I don't get it. by thadtheman · 2017-07-11 13:40 · Score: 1

GDI stands for Graphical Device Interface.
To increase graphical efficiency, a long, long time ago the process subsystem and the graphics subsystem were built together. I would say merged, but they were never really separate. ( What do you think NT stands for.)
This was one of the things that made people criticise Windows in the 90s.
There used to be a similar bug in the CloseHandle call used with FindFirstFile. If you close a file handle that is not open it would freeze for 7s ( Yes seconds. ) because of a bad hash lookup.
That's IIRC correctly haven't touched Windows in a while, but then what do yiou think the Nt in the API call stands for?
Re:I don't get it. by gweihir · 2017-07-11 13:59 · Score: 2

You are not confused. A sane kernel does not have this issue. A sane GUI stays responsive even with this issue. Unfortunately, Win10 does not have either.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by gweihir · 2017-07-11 14:00 · Score: 1

What an incredibly bad design!

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by Rutulian · 2017-07-11 14:06 · Score: 1

Short answer: context switching.
I'm sure others can pipe in here with more detailed explanations because I am not that familiar with the Windows kernel, but the basic gist of the problem is that calls to this function (NtGdiCloseProcess) cause it to acquire a global kernel lock which blocks thread execution...for ~200 microseconds, usually. The problem in this scenario is that around 5,768 calls to this function are being serialized onto the Ready Thread call stack which, combined, are delaying all other processes that utilize that lock.
In summary, the delays in responsiveness and interactivity are being caused by context switches, which is the usual culprit. It has nothing to do with the speed and number of CPUs because it is not a CPU resource problem. It is purely a kernel scheduling issue.
Re:I don't get it. by Dunbal · 2017-07-11 14:10 · Score: 1

It doesn't work that way. Windows is designed as a message based operating system. Any change in position of the mouse cursor is posted as messages to the queue. Whoever gets to read those queued messages is whichever program currently owning screen real estate. When the ownership of the window/screen changes, the change is instantaneous as far as the message queue is concerned (although the actual screen drawing process you see might have a noticeable delay due to hardware/buffer constraints).
As far as "context sensitive" help/popups, etc - the way that works is a program checks how long it has been since the mouse last moved and if it's above a specified time limit, the program then checks last mouse position against locations of possible pop-up triggers. This takes very few CPU cycles - you can have a function literally firing once every 2 seconds on a timer and doing 10 lines of code or so to determine if a popup is necessary or not. 10 lines of code every 2 seconds is next to nonexistent on a modern CPU.

--
Seven puppies were harmed during the making of this post.
Re:I don't get it. by Anonymous Coward · 2017-07-11 14:12 · Score: 0

WOOOOOOOOOOSSSSHHHHH!!!!!!!!!
Re:I don't get it. by Anonymous Coward · 2017-07-11 14:12 · Score: 0

GDI was replaced with GDI+ a couple of decades ago (Windows 9x->NT transition, IIRC, but don't quote me on that). GDI+ was replaced by DXGI over a decade ago (Vista release). DXGI has had several major upgrades, too. It's at version 1.5 now, as best as I can figure. (source) Each 0.1 version bump after 1.0 came with a full windows release except 1.5, which was released with the Win10 Creator's Update and DirectX 12.1.
And "NT" stands for New Technology.
Re:I don't get it. by Rutulian · 2017-07-11 14:13 · Score: 1

+1 Funny
http://www.tothepc.com/pic/fak...
Re:I don't get it. by Anonymous Coward · 2017-07-11 14:14 · Score: 0

Wow. It's a testament to Windows that you would take any of that comment seriously. You got trolled.
Re:I don't get it. by Travelsonic · 2017-07-11 14:51 · Score: 0

It's like MS coders flunked a class on basic computer operating system design concepts. Jesus Christ, no wonder the OS is locking up so much/badly.

--
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
Re:I don't get it. by ElizabethGreene · 2017-07-11 15:01 · Score: 1

You've never had the UI go unresponsive in X11 under heavy load?
Re:I don't get it. by gumbi+west · 2017-07-11 15:02 · Score: 1

Let's be honest though, only the old commercial unix machines could do this in the 90s (IRIX, Solaris are two good examples). I don't use a GUI on my linux machines, so I don't know how well written the GUI is there. Now, neither Apple nor MS is capable of making a responsive GUI.
Re:I don't get it. by Anonymous Coward · 2017-07-11 15:12 · Score: 0

Yup - the Windows kernel is a really bad at scheduling. I have looked into this in the recent past to analyze real-time video display issues. The only workable solution was to use *any* other OS - BSD, Apple or Linux. The Linux scheduler is best BTW and BSD is worst - Apple is in the middle of the three - but they are all orders of magnitude better than Windows at maintaining real-time response times.
Re:I don't get it. by Anonymous Coward · 2017-07-11 15:13 · Score: 0

Should not happen with 24 cores unless you're really bogging the beast. MS runs a lot more of the graphics stack in kernel than they should. That's the real problem here.
Re:I don't get it. by dissy · 2017-07-11 15:15 · Score: 1

The slashdot summary originally said "200S" instead of "about 200 microseconds"
It was silently changed without an update message saying so.
I too was very confused when I first read it, both that a capitol S and no space isn't any standard notation I know of, and that the only interpretation was 200 seconds which made no sense at all.
Re:I don't get it. by Gr8Apes · 2017-07-11 15:19 · Score: 1

I don't think so, they didn't notice a supposed outlook word document download hogging the entire system resources for 10 minutes, why would they notice a mere 200s group hug?

--
The cesspool just got a check and balance.
Re:I don't get it. by Bing+Tsher+E · 2017-07-11 15:37 · Score: 2

The graphics subsystem was outside the NT kernel until NT 4.0. NT 3.51 was as close to a good true multiuser operating system as Microsoft is likely to ever come.
Re:I don't get it. by Bing+Tsher+E · 2017-07-11 15:38 · Score: 1

We are supposed to be using X Terminals to connect to our UNIX boxes. The X Terminal does all the graphics work and is connected to the UNIX box over the ethernet.
Re:I don't get it. by Anonymous Coward · 2017-07-11 15:51 · Score: 0

The Windows GUI interface actually uses a separate process to update the mouse on the screen. Due to various historical reasons (compatibility with old applications, mostly), it was required to recycle this process every time the mouse moved, as the process could get a memory leak
Can you provide a reference for this claim?
It sounds like complete bullshit, but I suppose anything is possible.
Re:I don't get it. by Rutulian · 2017-07-11 16:07 · Score: 5, Interesting

It's easy to criticize from the outside, but the Linux kernel has historically had kernel locks that created similar problems, such as the "big kernel lock", removed ca 2011 (ie: not ancient history).
https://kernelnewbies.org/BigK...
As noted in the article, this particular locking problem appeared in Windows 10 and wasn't present in Windows 7, so the balancing acts between the fine-grained locking mechanisms, thread performance, and backwards-compatibility are clearly challenging to maintain. Not excusing; just observing. Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it. But here you go, a pretty nice example to illustrate that backwards-compatibility has a cost.
Re:I don't get it. by goose-incarnated · 2017-07-11 16:46 · Score: 2

You've never had the UI go unresponsive in X11 under heavy load?
FTFA it appears to go unresponsive without a heavy load - the cores are unloaded. So, no, I've never had an unloaded Linux/BSD machine get unresponsive with X11 .

--
I'm a minority race. Save your vitriol for white people.
Re:I don't get it. by Dog-Cow · 2017-07-11 18:15 · Score: 1

The serialization happens in the kernel, which means that hardware events are not being processed and transmitted to the mouse driver, which in turn isn't informing the process responsible for drawing the cursor.
Re:I don't get it. by mvdwege · 2017-07-11 18:41 · Score: 5, Informative

Yes, you are making exuses, that's exactly what a tu quoque fallacy is
The big lock was removed in 2011, Microsoft produced a regression on an already bad design a lot closer in history. That's a sign of incompetence, period.
Also, the Linux kernel has bad backwards compatibility, which is why things like drivers and such should be upstreamed as much as possible and built in the main tree, but Linux userland still happily runs old Unix software, so you are overstating that case as well.

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:I don't get it. by Anonymous Coward · 2017-07-11 18:51 · Score: 0

Perhaps the hardware cursor were disabled for some obscure bug/reason. I certainly hope that wasn't intentional decision by some OS or driver developer (or HW designer).
Re:I don't get it. by Anonymous Coward · 2017-07-11 18:58 · Score: 0

Thanks for the meaningless marketroid drivel. GDI+ was yet another wrapper over GDI whichever way you look at it. DXGI requires Win 8.1 so no-one in their right mind will write apps that rely on it whilst Win7 is still so prevalent.
Wake me up when BeginPaint et al disapper from user32.
Re:I don't get it. by tlhIngan · 2017-07-11 19:17 · Score: 1

FTFA it appears to go unresponsive without a heavy load - the cores are unloaded. So, no, I've never had an unloaded Linux/BSD machine get unresponsive with X11 .
I've had Linux go unresponsive without a heavy load - back in the bad old days of a decade and a half ago, untarring the Linux kernel itself would stall out the machine. The CPU was busy, but not so much - it was pure I/O locking up the kernel. So for the 5 minutes or so it took for the kernel to untar back in those days (this was when you didn't git clone it, you downloaded tarballs) the entire GUI was unresponsive.
In a more recent case, I've had Linux get completely unresponsive during an Android build - I had inadvertently caused the machine to thrash and this caused the machine (which was sitting in the corner since we SSH into it) to not respond to the console - it looked like it had hung completely - the keyboard and mouse didn't move, the screen stayed black, your SSH terminals were hung, you couldn't ping it, the disk light was stuck on, etc. Of course, it was working, just slowly - if you left it alone for a couple of hours it worked again.
Re:I don't get it. by butzwonker · 2017-07-11 19:37 · Score: 2

No mainstream operating system has responsive GUIs under heavy load, especially not under heavy i/o load. GNU/Linux goes down very rapidly, Android is sluggish out of the box, and OSX have their spinning beachball of death. They are designed incorrectly.
As a test, you may surf to this page to see how your system handles an embedded zip bomb. (Warning: Don't click this link unless you're willing to kill your browser session or even hard-reset your machine.)
Re:I don't get it. by gnasher719 · 2017-07-11 20:51 · Score: 1

In summary, the delays in responsiveness and interactivity are being caused by context switches, which is the usual culprit. It has nothing to do with the speed and number of CPUs because it is not a CPU resource problem. It is purely a kernel scheduling issue.
It has a bit to do with the CPUs: The reporter had a machine with 24 cores that actually managed to create and destroy 5,000 processes per second. My 4 core machine would have only created and destroyed less than 1,000 processes per second, so no problem.
Re:I don't get it. by Anonymous Coward · 2017-07-11 21:57 · Score: 0

This seems extraordinarily bad even for legacy systems. Recycling the process on every mouse movement would be extremely expensive, especially on Windows. Do you have a reference?
Re:I don't get it. by behrooz0az · 2017-07-11 23:13 · Score: 1

It's been loading for some time now, how long does your bomb usually take until it explodes?

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Re:I don't get it. by behrooz0az · 2017-07-11 23:17 · Score: 1

scratch that last one, it loaded, i'm still here

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Re:I don't get it. by Anonymous Coward · 2017-07-11 23:33 · Score: 0

So new Linux builds have never introduced a problem that didn't exist before?
Interesting, captcha is "criers"
Re:I don't get it. by Anonymous Coward · 2017-07-11 23:34 · Score: 0

Actualy, 2011 was when the last usage of the BKL was removed.
Most usage of the big kernel lock had been removed about 1998. There was a push after that to remove ALL uses.
Re:I don't get it. by Megol · 2017-07-12 00:11 · Score: 1

Yes but I guess your mother and father did their best trying to make you a smart boy(?).
Re:I don't get it. by Megol · 2017-07-12 00:14 · Score: 1

A sane person doesn't comment on things they don't understand. Unfortunately, gweihir isn't.
Re:I don't get it. by Anonymous Coward · 2017-07-12 00:15 · Score: 0

Yes, you are making exuses
He clearly didn't intend it, and I didn't interpret it that way. If you really want to interpret it that way you can.

The big lock was removed in 2011
Yes, that's what he said.

Microsoft produced a regression on an already bad design a lot closer in history. That's a sign of incompetence, period.
Doubt anyone here would argue that Microsoft is competent.

Also, the Linux kernel has bad backwards compatibility, which is why things like drivers and such should be upstreamed as much as possible and built in the main tree
That's what he said. Again.

but Linux userland still happily runs old Unix software
Yes, it does. But not relevant.

so you are overstating that case as well
He stated no case regarding Linux userland.
I suppose you would want him to trumpet all of the positives regarding Linux, but that would be off-topic and confusing. He was talking about a particular problem Linux had and its similarities with the current topic, a Windows bug. If you would read unbiased comments as observations rather than attacks, you might not get so angry.
Re:I don't get it. by Megol · 2017-07-12 00:17 · Score: 1

Best in what metrics? Average latency? Worst-case latency? Fairness?
Re:I don't get it. by rholtzjr · 2017-07-12 00:47 · Score: 1

Uuuuh, we did. Unixware 2.X with an external 500MB framebuffer back in the early 90's. If you would initiate a rapid update to cursor position it would cause the XServer to crash as the current technology could not keep up with the physical interface of the day. Also realize back then, an 8MB SIMM was considered huge and somewhat expensive (400 USD/8MB SIMM). .
Re:I don't get it. by Anonymous Coward · 2017-07-12 00:52 · Score: 0

Then it should have the LEAST lag when everything else is blocking on one lock.
Re:I don't get it. by Anonymous Coward · 2017-07-12 01:10 · Score: 0

Actually, Microsoft did release a multiuser OS years prior...
https://fossbytes.com/xenix-history-microsoft-unix-operating-system/
Re:I don't get it. by luis_a_espinal · 2017-07-12 01:21 · Score: 1

GDI was replaced with GDI+ a couple of decades ago (Windows 9x->NT transition, IIRC, but don't quote me on that). GDI+ was replaced by DXGI over a decade ago (Vista release). DXGI has had several major upgrades, too. It's at version 1.5 now, as best as I can figure. (source) Each 0.1 version bump after 1.0 came with a full windows release except 1.5, which was released with the Win10 Creator's Update and DirectX 12.1.
And "NT" stands for New Technology.
A couple of decades ago. Yeah don't worry, I won't quote you on that.
Re:I don't get it. by Anonymous Coward · 2017-07-12 01:33 · Score: 0

Perhaps Win10 is just serializing the telemetry storage on that function. The Win10 seems to be pretty bad at multitasking anyway, on my workstation the mouse jams and Windows media player stutters on music playback many times a day, something which has not really happened ever since Windows 2000 arrived.
Re:I don't get it. by thegarbz · 2017-07-12 01:49 · Score: 1

You are not confused. A sane kernel does not have this issue. A sane GUI stays responsive even with this issue. Unfortunately, Win10 does not have either.
Neither does Linux, Unix, or pretty much every OS except for BeOS.
So insanity rules the crop.
Re:I don't get it. by thegarbz · 2017-07-12 01:52 · Score: 1

That's a sign of incompetence, period.
Come back when you are a perfect coder who can in a bug free way solve a problem in a part of the system where any change may fundamentally break applications.
If I follow your standards then every single IT coder who ever managed to escape from the uterus is showing signs of incompetence.
Re:I don't get it. by Anonymous Coward · 2017-07-12 02:06 · Score: 0

Windows has terrible latency and the scheduler is not designed to be fair at all. The one and only scheduling policy for everything is similar to SCHED_FIFO under Linux. It is absolutely horrible and has no place on a modern computer. Microsoft should be embarrassed to have an operating system so bad a multitasking in the day and age.
Re:I don't get it. by Anonymous Coward · 2017-07-12 02:18 · Score: 0

It would be, if it were true.
Re:I don't get it. by Anonymous Coward · 2017-07-12 03:09 · Score: 0

You're using Chrome? How long did you wait? For Chrome the guy who made the example states "memory rises, error shown" which seems like a reasonable response. Other browsers crash.
Out of curiosity, what are your machine specs?
Re:I don't get it. by tepples · 2017-07-12 03:10 · Score: 1

In a more recent case, I've had Linux get completely unresponsive during an Android build
Does this happen even if you nice the build?
Re:I don't get it. by mvdwege · 2017-07-12 03:45 · Score: 1

And you come back when you can actually make a non-fallacious argument.
Shorter version: fuck off, idiot.

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:I don't get it. by Bruce+Dawson · 2017-07-12 03:45 · Score: 1

I'm not sure if this answer was intended to be serious or not. Either way, just to clarify, it is entirely false. The process that updates the mouse position is not frequently recycled.
The real reason is that the same system-global lock is used for a lot of purposes. The same lock appears to protect GDI objects (destroyed when processes are destroyed, even those that never use GDI) and process message queues. Thus, mouse-movement and UI updates are fighting over the same lock which process destruction uses.
Re:I don't get it. by Anonymous Coward · 2017-07-12 03:50 · Score: 0

I've had the UI go unresponsive while the browser loads the ads on slashdot.
Re:I don't get it. by Bing+Tsher+E · 2017-07-12 04:10 · Score: 1

I have a Xenix box right here in this room. It's an Altos 586, which is a five user 8086 Xenix box. It has five serial ports, each of which is attached to a dumb terminal for a user to make use of. It supports five users on an 8086 processor and 512K of RAM. It's also Microsoft Xenix, from before they spun off their Xenix division into what became SCO.
Re:I don't get it. by Anonymous Coward · 2017-07-12 04:20 · Score: 0

It stopped happening once people learned to always compile desktop kernels as realtime kernels. This allows threads to be pre-empted in kernel.
Re:I don't get it. by Anonymous Coward · 2017-07-12 04:20 · Score: 0

One of the classic snags in Windows is how the Explorer shell interfaces with the disk and network hardware. A Windows Explorer window has a list of links down the left hand side to various useful places: Documents, Music, and whatever you like. If you have two of these windows open, and drag a selection of files from the right window to the left, and pass over the shortcut links, you can hang the entire GUI, because the shell tries to work out whether the user is performing a valid drag-drop action on the shortcut. If the link is to a network drive, or a HDD that is asleep, you may be stuck for 30s or more while it times out.
I'm not sure if technically there is any way to solve that, other than disabling certain GUI actions in certain situations, which I would accept as a valid solution and would trust interface experts who have decades of experience to make those decisions correctly - or, give me a GUI that can be completely customised to my preference.
A GUI/windowing system that is restricted, and designed by fuckwits, is the worst of all worlds...
Re: I don't get it. by Anonymous Coward · 2017-07-12 04:32 · Score: 0

"Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it."
People this, that, and the other, fact is that Linux has an excellent backwards compatibility with regards to applications.
Comments about lacking backwards compatibility with Linux are regarding closed source drivers.
aRTee
Re: I don't get it. by Anonymous Coward · 2017-07-12 04:43 · Score: 0

"No, it's a sign that Linux zealots like you will NEVER be appeased when it comes to Windows. Linux still doesn't have a stable driver ABI in 2017. That's not just incompetence, but pure stupidity."
It's a choice not to have a stable driver ABI, not a matter of incompetence.
Whether or not it's stupid depends on the goals that the kernel developers have set.
Checking for stupidity... :
I personally doubt their goals include getting as many closed source drivers to support hardware in a black box way, so they didn't fail there.
Losing time on bugs related to closed source drivers tracks right onto that one too, fine again.
World domination,...? Android has 90% market share, the supercomputer top 100 is ruled by Linux, etc.
Seems not so stupid to me.
So maybe it's you?
aRTee
Re:I don't get it. by Anonymous Coward · 2017-07-12 05:33 · Score: 0

We had a Linux application at my old job that forked off a processes that created a lot of files in a temporary directory, which was then deleted in another thread. This worked fine for, oh, a decade or more. Then one day we upgraded to a new version of (I think) RHEL (I don't remember the exact version). After a minute or two the application would start getting slower and slower and then grind to a halt. After a whole lot of debugging it turned out the reason was that the file deletion part was getting slower and slower as the program ran until it was taking 40 minutes just to delete a few files.
We had to revert to the previous OS for that particular delivery. Later we switched to whatever version followed the problematic version and everything ran fine again. Something changed in that OS release, whether is was in the kernel, or it was something with the priority of filesystem calls or whatever.
How does that fit into your "Microsoft-is-incompetent-because-they-produced-a-regression-but-Linux-is-great" model?
Re:I don't get it. by Anonymous Coward · 2017-07-12 05:37 · Score: 0

Only if that software is recompiled for your environment all the fucking time. And don't go blaming it on userland as thought the kernel is worth anything without userland.
Re:I don't get it. by thegarbz · 2017-07-12 05:57 · Score: 1

I didn't. Learn to read and pay attention who you're talking to on a public forum.
Shorter version: You're a useless dickhead. Get an education.
Re: I don't get it. by Rutulian · 2017-07-12 06:50 · Score: 1

If this were a discussion about the Linux userspace, you might have a point, although that can be debated as well.
With respect to the kernel, yes, third-party drivers (not necessarily closed source, but out of tree) are the relevant players impacted by ABI/API changes. If you have to recompile your driver after a kernel update, you don't have backwards-compatibility (ABI). If you have to make updates to your driver, however minor, before it will compile against a newer kernel, you don't have backwards-compatibility (API).
Just to be clear: that is not necessarily bad or wrong. Backwards-compatibility has both a benefit and a cost, as exemplified by the issue under discussion. Linus has repeatedly made it clear that he generally regards the cost of backwards-compatibility to be very high. If he needs to make a compatibility-breaking change to the kernel to improve security/increase efficiency/clean up interfaces/reduce cruft/add features/etc, he will. (You can claim, as Linus does, that this isn't really breaking backwards-compatibility because the Linux kernel has never advertised a stable interface for out-of-tree drivers, but it is a rather semantic argument as people generally expect the ability to use out-of-tree modules and may need them for varying reasons.)
Microsoft, on the other hand, has a distinct profit-motive to get as many people to upgrade to newer versions as possible. So they have a rather different POV. Namely, that backwards-compatibility must be maintained to facilitate smooth upgrade paths for potential customers.
Re:I don't get it. by Anonymous Coward · 2017-07-12 13:38 · Score: 0

Unless using bfs as the scheduler.
Re:I don't get it. by gweihir · 2017-07-12 14:45 · Score: 1

No, I have not. One exception, on emergency flush to disk and a GUI-action that accesses the file-system. Then that filesystem-access (not the GUI) will hang for a while.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by gweihir · 2017-07-12 14:50 · Score: 1

Yes, I/O locking and flushing-to-disk is still not quite perfect in Linux. It used to be you could tune the parameters yourself (and if you did it with some understanding of your workloads, things were fine), but then some big egos decided that users are not allowed to do that anymore. Resulted in me having to throttle some I/O to a slow MO drive myself manually. The stupidity of that decision really pissed me off. It has gotten better again, but not as good as my hand-tuned performance parameters were.
This does hover not lock the GUI.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by gweihir · 2017-07-12 14:52 · Score: 1

Funny. But a bit pathetic as well.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by gweihir · 2017-07-12 14:53 · Score: 1

Linux has a forking performance issue? You seem to be confused.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by mvdwege · 2017-07-12 18:59 · Score: 1

You did. Two actually: fallacy of the excluded middle and a strawman. They're right up there for all to see.

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:I don't get it. by Actually,+I+do+RTFA · 2017-07-13 03:17 · Score: 1

In the movie version of Dr. Strange, it's played for a joke that "the warnings come after the spells." I think you should put warnings before the link (or at least a warning that people should read the long warning), in the way people read text.
Not that I impulsively clicked on it without reading, but safety rules are designed to protect the most people. (See also, flammable vs. inflammable)

--
Your ad here. Ask me how!
Re:I don't get it. by Anonymous Coward · 2017-07-13 03:45 · Score: 0

So moving the mouse around when Windows appears stuck on something doesn't actually make it go faster? I'll have to explain this in detail to my 7-year old niece and my 70-year old mother.
Re:I don't get it. by thegarbz · 2017-07-13 06:13 · Score: 1

Oh wow I'm dealing with an actual idiot. Sorry I had no idea.
Re:I don't get it. by thegarbz · 2017-07-13 06:17 · Score: 1

No, Linux has an ability for the GUI to be screwed up in normal use issue. That's actually not Linux (the kernel's) fault as much as it is 20 years of X patchwork. But in terms of GUI responsiveness ... well let's say there's a lot of people very eager to see a new window system written despite Xorg's attempt to gut hundreds of thousands of lines of cruft out of the status quo.
Except those people who insist that network transparency is the only critical feature a GUI must have.
Re:I don't get it. by Anonymous Coward · 2017-07-13 08:41 · Score: 0

Shorter version: fuck off, idiot.
And now we know exactly what you are. Thanks for showing us your ass.
Re:I don't get it. by gweihir · 2017-07-13 09:09 · Score: 1

You must be referring to the recent failures like Weyland. If it is not broken, do not fix it. X.org, sysVinit, etc. all being "improved" by people that only manage to make it worse. No thanks.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:I don't get it. by behrooz0az · 2017-07-13 10:47 · Score: 1

firefox, x86_64, archlinux, latest kernel, gnome , I think it took about 10 to 15 minutes.
16GiB ram, almost all of it empty then
volatile /tmp
ZRam configured at 3GiB
i7 3610QM

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Re:I don't get it. by behrooz0az · 2017-07-13 10:56 · Score: 1

oh, i should have mentioned, I've changed almost everything in about:config. gigantic buffers.

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Re:I don't get it. by thegarbz · 2017-07-14 07:24 · Score: 1

Nope. I'm referring to recent successes such as Wayland. Successes in who's eyes you may ask? The technical communities that package distributions.
Frankly no one gives a shit what gweihir thinks and instead everyone of any kind of relevance has decreed that no... it hasn't made it worse at all.

Marketing's response by Sparowl · 2017-07-11 12:45 · Score: 1

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"

10 is bigger and better than.. by neoRUR · 2017-07-11 12:54 · Score: 1

7 right?

Re: 10 is bigger and better than.. by Anonymous Coward · 2017-07-11 13:33 · Score: 0

7 or 10? How many bloody horse heads would you like to wake up with?

any thing to make INTEL look good next the amd by Joe_Dragon · 2017-07-11 12:58 · Score: 0

any thing to make INTEL look good next the amd chips with more cores.

Intel is hitting rock bottom and is willing to pay off any one to keep AMD from being king this round.

Re:any thing to make INTEL look good next the amd by Bing+Tsher+E · 2017-07-11 15:40 · Score: 1

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.

I remember BeOS by rsilvergun · 2017-07-11 13:00 · Score: 4, Insightful

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/

Re:I remember BeOS by 50000BTU_barbecue · 2017-07-11 13:14 · Score: 1

Amiga.

--
Mostly random stuff.
Re:I remember BeOS by zennyboy · 2017-07-11 13:18 · Score: 1

Yeah. You should try an Amiga....
Re:I remember BeOS by Anonymous Coward · 2017-07-11 13:18 · Score: 0

Memory usage increases linearly with bitmap color depth and as the square of the resolution.
Re:I remember BeOS by viperidaenz · 2017-07-11 13:20 · Score: 1

I don't have window tearing issues on this laptop I'm using.
Windows 8.1. Even with two of the monitors connected via a docking station connected to a single USB 3 port.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 13:21 · Score: 0

512mb would have been a pretty tremendous amount of RAM in 1996.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 13:35 · Score: 0

...except screen tearing isn't related to core count or RAM amount.
The only reason screen tearing happens on present-day OSes, and the reason dragging windows etc. isn't smooth (see: AmigaOS, BeOS, etc.) is because of the ridiculous number of abstraction layers between the video card and the userland program (UI) itself. More specifically: the amount of time you have available in VBlank is a static amount, and therefore in turn, you know definitively how many CPU cycles you have available to do what you need (i.e. VRAM updates) during that period of time. Things like abstraction layers (between device driver and kernel, and from kernel to userland), combined with things like dynamic frequency scaling (i.e. Intel SpeedStep, AMD Cool'n'Quiet, etc. -- god knows what else they're called nowadays), means that the exact amount of time in VBlank becomes variable/unknown. This same problem plagues PC games for the exact same reasons.
I'm sure someone will bring up Nvidia G-Sync or AMD's FreeSync as a solution to this problem (especially for gamers), except they introduce a problem that I've inquired about since day one of their inception: surely this works great in full-screen DX applications (not "borderless windowed full-screen", I'm talking native full-screen), but how does this work reliably with games which are in windowed mode? Initially the response from Nvidia was "G-Sync won't work in windowed mode" (understandably), but in mid-2015 Nvidia released drivers which did it anyway (their solution: let the foreground application act as the definitive source of whether G-Sync is used or not, so probably whether or not the foreground application is a native DX application or not, or maybe it's just in the "known .exes" list within the video driver, I don't know).
Apologies for the length of my post, but this subject comes up often, and there seem to be a number of people that don't understand what VSync (thus VBlank) *actually is* and why on present-day PCs it's a pain in the ass. The short of it is: yes, it is 100% achievable, but all the bullshit technology gets in the way (between the application (game, UI, etc.) and the video card). Nobody seems to care about the GUI any more (as Microsoft has proven with Windows 10), which is pretty sad, considering that's the thing people are in ~90% of the time they're using Windows. The only thing I've seen that is minimising the amount of BS layers between everything is Vulkan.
P.S. -- For a fun time, try using Windows 7 to drag-select (rectangle select) a bunch of icons on your desktop (the translucency feature is hardware offloaded). Do this with both an Nvidia GPU, then an Intel (on-die) GPU. Note how ridiculously choppy the rectangle becomes as it grows in size on Nvidia, while on Intel it's smooth as butter. I always thought this was a problem with Windows' DWM, particularly desktop composition, but that test rules it out (though, that Wiki article is a great example of just one of several layers of BS going on under the hood).
Re:I remember BeOS by Anonymous Coward · 2017-07-11 13:43 · Score: 0

That would have been an awesome hard drive in 1996.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 13:45 · Score: 0

I am guessing you haven't used many OS's in your life then nor do you understand the resolution/screen information/colour depth that has changed since then.
Re:I remember BeOS by Rutulian · 2017-07-11 13:46 · Score: 1

And the K6 wasn't released until 1997 with an initial clock speed of 166 MHz. It wasn't until 1998 that it could achieve clock speeds of 300 MHz. It was late 1998/early 1999 before the 400 MHz K6-2 was released, which was also around the time you could max out the FSB with 512 Mb PC100 SDRAM (the pre-DDR era). So yeah, I think that while the GPs point is valid, his dates are a bit off.
Re:I remember BeOS by spire3661 · 2017-07-11 13:51 · Score: 1

How do i get my Xubuntu/Intel NUC to stop screen tearing (Intel GPU)? I have updated everything i can think of.

--
Good-bye
Re:I remember BeOS by adolf · 2017-07-11 14:08 · Score: 4, Interesting

I was accomplishing this on 486DX2 hardware using OS/2 in ~1994, and by 1995 on a P120.
Several years ago I stopped by a buddy's retail establishment. He was transitioning network to Ubuntu on more modern hardware (with OS/2 in a VM), but still had an old and crusty OS/2 machine (probably a K6-2, but maybe a DX4) on the bench by the back door.
This was the last time I ever saw such a thing in the wild.
It was remarkably snappy doing normal, productive things -- scanning documents, browsing web pages, writing and viewing proposals -- just like it was when it was built. (And what window tearing?)
Sometimes I think that the more abstraction layers we add, the slower things get. I think this coupled with programmer laziness (and/or pay based on lines of code), makes human-interactive things continue to behave just as slow as they have been for ~20 years.
Do we even use accelerated 2D desktop graphics anymore, or are we completely back to the bad old days of every application drawing into a dumb framebuffer?

--
Kid-proof tablet..
Re:I remember BeOS by Anonymous Coward · 2017-07-11 14:13 · Score: 0

It would have been an OK sized hard disk.
Re: I remember BeOS by Miamicanes · 2017-07-11 14:37 · Score: 3, Interesting

The Amiga could scroll a "screen" vertically with zero tearing (and very little effort), because it was just updating a memory pointer during a horizontal retrace interval. Ditto, for updating the mouse pointer (it was just a sprite). Both worked even when the app (or OS) died because it was serviced semi-independently of the OS as a whole during the vertical retrace interrupt.
Intuition-rendered windows were another matter entirely... I think window gadgets & outlines were rendered in the vertical retrace interrupt, but contents & outside-erasures depended on the app and/or os running properly.
Likewise, the mouse pointer was only robust when it was a 320x200/400 sprite... apps like DeluxePaint & WordPerfect (which needed more precision on a 640x200/400 screen than sprites could provide) that used XOR'ed software-rendered overlays could still crash (though if you clicked outside of the crashed app's window, the sprite-rendered pointer returned)
AmigaDOS was groundbreaking, but it still had some serious issues of its own. Like an event queue that used single-bit flags, allowing users to click BOTH 'ok' AND 'cancel' if the app stalled/crashed with a dialog on-screen.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 14:57 · Score: 0

Same AC here. On Linux, this is how you'd do that is below -- preface: I do not use X/X.org (last time was in 1995!), so please take some of what I say with a grain of salt. The version of Ubuntu you're using matters greatly too. Someone more familiar with Ubuntu as a workstation/desktop, please comment!
1. Try digging around for resources relating to X.org, as that's effectively what's driving all the GUI bits and interacting with the video driver. I think this is xorg.conf or xorg.conf.d/ and there may be a config file setting (warning: that file/directory will probably scare you). I don't think your WM (window manager) is relevant,
2. Research options described in Ubuntu's Community Support; pick one or several and post there,
3. Try to track down the authors (committers) of the associated video driver and ask them. I did the work for you as best as I could: the X.org driver is called xserver-xorg-video-intel (assuming that's the chip you're using). There's supposedly an alternate driver from Intel themselves here but I have no idea if using it would solve anything (I wouldn't recommend doing the latter on a whim; I prefer to use Ubuntu packages natively if at all possible),
4. Use Launchpad to file a ticket with Ubuntu directly. Also advise searching their system to see if someone else has asked the same thing (try looking for separate terms "tearing", "vsync", "v-sync", or "vblank").
I also own an Intel NUC, but it's a headless server box for building third-party MIPS and ARM router firmwares, so I don't use the GUI (I don't even have a monitor hooked up to it). Plus we might have different NUCs (their on-die GPUs certainly differ between models), and I'm running a fairly old Ubuntu (intentionally).
Sorry I couldn't be of more help, but the above steps is the road I would take if I had to deal with said issue.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 14:57 · Score: 0

Depends on how fast it was.
Re:I remember BeOS by gumbi+west · 2017-07-11 15:06 · Score: 1

s/1996/1993/
and you're right. By 1996 it was a bit small.
Re:I remember BeOS by sonamchauhan · 2017-07-11 15:18 · Score: 1

??? What do you mean?
Re:I remember BeOS by Anonymous Coward · 2017-07-11 15:19 · Score: 0

Use the latest testing driver. :)
Re:I remember BeOS by Gr8Apes · 2017-07-11 15:22 · Score: 1

64MB of RAM and 2 1GB hard disks in 1992. Of course IIRC the 512MB RAM GPUs were $25K.... That was an SGI GPU though.

--
The cesspool just got a check and balance.
Re:I remember BeOS by DNS-and-BIND · 2017-07-11 15:29 · Score: 2

"I once preached peaceful coexistence with Windows. You may laugh at my expense - I deserve it."
-- Jean-Louis Gassee, CEO Be, Inc.

--
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Re:I remember BeOS by gumbi+west · 2017-07-11 15:33 · Score: 1

Yeah, I'm going to bet it was regarded as an awesome HDD in 1992. I remember thinking the SGIs were computers from about 5 years in the future. It was more like 2-3.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 15:36 · Score: 0

Screen tearing is probably caused by you having vsync disabled to crank every last FPS out of your video card for gaming, or just plain crap 2d support in your video cards. Even back in the late 90s I never saw screen tearing using quality 2d hardware like Matrox cards. Unfortunately they all but barely exist in the general consumer market today because OMG I need to push the maximum number of polygons possible!!!!
Re: I remember BeOS by Anonymous Coward · 2017-07-11 15:40 · Score: 0

You might be interested in this guy https://mobile.twitter.com/pcwalton/status/883450047521632257 ... Already made the fastest font renderer, working on GPU based rendering techniques for Mozilla
Re:I remember BeOS by Anonymous Coward · 2017-07-11 15:44 · Score: 0

The G400 cards back in the day were capable of 1080p or 1600x1200 analog output with damn near perfect clarity. Try the same with an Nvidia card of the day any anything above 1024x768 was a smeary noisy mess. Probably their only saving grace for high res desktop use was the move to DVI and now HDMI. They couldn't design a good analog output if their life depended on it.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 15:51 · Score: 0

Probably due to the crap state of video drivers in open source stuff. Most of it is probably all running in basically compatibility mode drivers using the CPU to do all the 2d rendering work. Your expensive graphics card is probably not being used for much more than its framebuffer ram and ramdac or equivalent for the digital interconnects.
Re: I remember BeOS by BESTouff · 2017-07-11 19:33 · Score: 1

The Amiga could scroll a "screen" vertically with zero tearing (and very little effort), because it was just updating a memory pointer during a horizontal retrace interval.
Yes but no. If you had used CygnusEd (a text editor), you'd knew what's it like to have frame-perfect "kinetic" smooth scrolling even under CPU load. And scrolling text in a window is a little bit more complex than just updating a pointer.
Re:I remember BeOS by Anonymous Coward · 2017-07-11 19:56 · Score: 0

That sounds like my Windows 7 experience with old-style integrated graphics and desktop compositor disabled (basic theme, without acceleration). It was horrible.
Re:I remember BeOS by blind+biker · 2017-07-11 20:16 · Score: 1

Furthermore, in BeOS user input was king: no matter what shit the OS was doing, mouseclicks and keypresses trumped all else. Boy did BeOS run smooth (from my perspective). Sure, some files got copied 100 milliseconds later - nobody gives a fuck!

--
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Re: I remember BeOS by AmiMoJo · 2017-07-11 20:30 · Score: 1

Until Windows Vista sprites were used for the mouse pointer on PCs too, including in Windows. VGA cards of the day supported hardware acceleration in the form of a single sprite used for the mouse pointer. Most Amiga graphics cards, which used the same chips, also supported that single sprite for the mouse but the Picasso96 driver did also support a "soft pointer".
Having recently booted up my old Amiga system, one thing that struck me was that everything freezes when you open the drop-down menus. I had a file copy going in DOpus, pressed the right mouse button and it froze while I browsed the menus. I remember it being a useful feature back in the day for pausing scrolling CLI windows and the like.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:I remember BeOS by Megol · 2017-07-12 00:21 · Score: 1

So it used double buffering or you were lucky. Those are the two things that enables tear free rendering. Double buffering adds overheads (but being lucky doesn't).
Re:I remember BeOS by Megol · 2017-07-12 00:23 · Score: 1

Only if you were lucky. There's nothing that makes tearing impossible in Amiga OS, put some load on the system and the blitter can't copy things fast enough.
Re:I remember BeOS by Carewolf · 2017-07-12 00:44 · Score: 1

2D acceleration is now done using OpenGL framebuffers without a perspective transform or equivalent in Direct3D
Re:I remember BeOS by Anonymous Coward · 2017-07-12 02:34 · Score: 0

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.
What OS are you using now? Windows has had a GPU accelarated, dubbled buffered, tear-free desktop since Vista.
Re:I remember BeOS by Gr8Apes · 2017-07-12 03:46 · Score: 1

The SGIs as we had them configured were fine for at least 8 years, and ahead of anything desktop wise. They ran MIPS 4400s, and had more than 1GB RAM, IIRC.
The HDDs were Seagate 1GB SCSI-2 7200s enterprise drives dropped into 486 desktops with 64MB of RAM, and were not exceeded in performance for quite a few years by anything in the desktop arena. In 2000, I was still using similar 10-50 GB drives for my system drives, and only later adding ATA drives as mass store when they finally started exceeding 100GB on a cost competitive basis. At the time, there was just no comparison in performance between SCSI2+ and anything else available. The memory RAM size wasn't commonly exceeded until 97, IIRC, although I got a Pentium Pro for my personal system with what eventually was 512 MB of RAM by 96. That lasted until about 2001.

--
The cesspool just got a check and balance.
Re: I remember BeOS by Anonymous Coward · 2017-07-12 04:21 · Score: 0

Interestingly, CygnusEd was also written by Bruce Dawson, subject of this submission.
Re:I remember BeOS by Anonymous Coward · 2017-07-12 06:15 · Score: 0

This is something that I've pondered over the years - we get all these abstractions that do neat things for us, but at some point, people lose site of what the abstractions actually are. They don't take them into consideration when designing software, and just use libraryXYZ because it provides featureA that they need to complete the project. We end up with Leaning Towers of Pizza everywhere, and people wonder why things fall down and crash...
Re:I remember BeOS by Anonymous Coward · 2017-07-12 06:20 · Score: 0

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.
What version of 1996 did You live in? In the 1996 I remember, you might have been lucky to have 64MB of ram with a K5 or Pentium 166.
Re: I remember BeOS by Miamicanes · 2017-07-12 14:56 · Score: 1

AFAIK, the S3 86c911 was the first PC video chip that had a single hardware sprite.
I originally thought the Tseng ET4000 had sprites, but if it did, I've never seen it documented anywhere (the ET4000/w32 DID have a single sprite, but that came much later).
The sad thing is, VGA actually DID allow software-defined fonts you could modify on the fly, but the only two apps of that era known to have actually USED that feature were the file manager in MS/DOS 6 and Protracker (*). From what I recall, there was a *huge* cultural taboo back then against manipulating VGA registers directly (vs using BIOS calls). As in, on a scale from 0 (ok) to 9 (forbidden & taboo), it was "10" ;-)
(*) They used 9 of the 16-available custom characters in a 3x3 grid centered on the mouse pointer, defined them to look like the 'actual' characters they replaced, then Xor'ed the mouse pointer into them.
Re: I remember BeOS by Miamicanes · 2017-07-12 16:21 · Score: 1

^^^ oops, typo. The second app was Impulse Tracker, not Protracker.
reference: https://en.wikipedia.org/wiki/...
Re:I remember BeOS by houghi · 2017-07-13 02:47 · Score: 1

or are we completely back to the bad old days of every application drawing into a dumb framebuffer?
We have an initd, that tries to do everything that starts a wibdowmanager, that tries to do everything running a desktop, that tries to do everything so I can run a browser that tries to do everything to visit a website that tries to do everything running ads that try to do everything.

--
Don't fight for your country, if your country does not fight for you.
Re: I remember BeOS by Miamicanes · 2017-07-14 04:08 · Score: 1

I might be mistaken, but I'm pretty sure that CygnusEd (circa 1990) ran in its own Screen, not an Intuition-managed window.
With a Screen, you could use Copper lists to change the screen pointer during horizontal retrace after a specific scanline, so you could treat screen ram as a ring buffer. Instead of physically rewriting the pixels, you'd just point at whatever offset corresponded to your current top row, then change it to wrap around to the buffer's start for the remaining scanlines. That way, you only had to physically redraw the newly-exposed rows of text, and maybe redraw the scroll bar. This was a big deal, because the blitter was actually quite slow (it could shovel around about a million pixels/second, MAX... usually less..), so the best strategy for good performance was to avoid redrawing as much as possible & just change pointers on the fly instead.
Re:I remember BeOS by toddestan · 2017-07-14 14:05 · Score: 1

In my closet I have what must be one of the first Pentium II boards, a Tyan S1680 from 1997, with a 300 Mhz PII processor, and is populated with eight 32MB 72-pin SIMMs for a total of 512MB. Last I tried, it did work, though it's little more than a curiosity now. But that had to have cost someone a small fortune back in 1997, only to be eclipsed by commonly available hardware in about 2 years.

That design & implementation is so bad by presidenteloco · 2017-07-11 13:07 · Score: 2

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?

Re:That design & implementation is so bad by Bruce+Dawson · 2017-07-12 03:53 · Score: 1

Reserving one core for the GUI and mouse would be pretty wasteful. And it doesn't really address the problem. The problem is that shared resources need to be protected from corruption when multiple processes/threads access them. This is usually done with locks. If you are'nt careful then these locks can limit serialization.
In this case the likely fix is to reduce contention for the lock, perhaps by not creating/destroying GDI objects for processes that don't need them.

Re:Not just when closing a program by viperidaenz · 2017-07-11 13:10 · Score: 4, Insightful

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

It figures. by Anonymous Coward · 2017-07-11 13:23 · Score: 0

See? Shows how much of a clusterfuck Windows 10 is.

Windows 7 keeps proving that it is superior to its newer versions.

Re:Not just when closing a program by Narcocide · 2017-07-11 13:24 · Score: 2

Made it slow both ways

And more expensive. Oh, the irony!

Only 24 Cores? by Anonymous Coward · 2017-07-11 13:25 · Score: 5, Funny

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

Re:Only 24 Cores? by Anonymous Coward · 2017-07-11 14:43 · Score: 0

Funny, almost spilled my cup of coffee on my laptop.
Also,
2 Cores for Windows Defender
2 Cores for Defender Protection.
2 Cores for EMET
1 Core for Windows Firewall
2 Cores to run Edge
2 Cores to run Edge plug-ins
While my Pentium 4 is still smoothly running XP consuming only 65MB of RAM out of 256, complete with Sound drivers, Graphics Drivers and Network Drivers/Adapters.
While my quad core i7 running Win8.1 requires 1.6 GiB of RAM upon boot-up. See that difference 1,600MB(Win8) versus 65MB(XP) of RAM usage.
Re:Only 24 Cores? by Anonymous Coward · 2017-07-12 03:30 · Score: 0

You forgot to mention the 2 cores required for Cortana Protection
Re:Only 24 Cores? by Anonymous Coward · 2017-07-13 00:35 · Score: 0

I think that's usually called a condom, not a core...

Re: Windows has always been unresponsive to user i by Anonymous Coward · 2017-07-11 13:29 · Score: 0

98 was the best in terms of taking input. It would take input even while the GUI was frozen. Then when you filled the buffer the PC speaker made this neat chirping noise.

Re: The lock cycles were avg 200 Âs each by Anonymous Coward · 2017-07-11 13:33 · Score: 0

Use Unicode for micro, yoÂ insensitive clod!

Re:Not just when closing a program by Anonymous Coward · 2017-07-11 13:37 · Score: 0

No, full screen gaming mode in windows is designed to provide resources and priority to the game as the last thing someone wants is, indexing, search, defraging etc etc chewing up cycles. so that is NOT the same issue at all and if anything is somewhat a feature, just one of the consequences of such prioritisation is that when you want to quickly switch back their is significant (noticeable) time and delays as resources are paged back in.

Not just 24 cores by Anonymous Coward · 2017-07-11 13:51 · Score: 0

I've been working on various high load tests on my 6-cores deskptop Win10 machine and noticed the exact same thing. I even changed to a wired mouse thinking the wireless mouse may have a radio issue!

Windows isn't done ... by Anonymous Coward · 2017-07-11 13:52 · Score: 0

Remember "DOS isn't done until Lotus won't run"?

So it's not just me by blindseer · 2017-07-11 13:54 · Score: 1, Interesting

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.

Re:So it's not just me by fatboy · 2017-07-11 14:05 · Score: 1

So Windows 10 is the only one that is actually patched? <Ducks> :)

--
--fatboy
Re:So it's not just me by blindseer · 2017-07-11 14:38 · Score: 1

You have something of a point there about updates. I'll update the computers when it is convenient for me, like I'm forced to reboot due to a power outage. I just checked and it looks like an update is waiting for a reboot on one of my Macs. It seems only Windows 10 has "critical" monthly updates that require a reboot.
Sure, XP probably has security problems where it should not be on the internet but due to their age I don't go web surfing with them a lot, and they are behind a firewall, so risks are minimal. What would anyone gain from compromising them? My high scores? They have internet access mostly just to keep their clocks accurate.
Serious question, is there something I should be doing different to keep these XP machines from becoming a security problem?

--
I am armed because I am free. I am free because I am armed.
Re:So it's not just me by ElizabethGreene · 2017-07-11 14:58 · Score: 1

> Serious question, is there something I should be doing different to keep these XP machines from becoming a security problem?
Don't have them be a member of your domain, Have unique passwords on them, don't access the internet from them, don't check email on them, and don't allow internet access on them.
There is still the possibility that they'll be compromised in a lateral traversal attack, but this minimizes the probability that they'll be the initial attack vector.
Re:So it's not just me by coolsnowmen · 2017-07-11 15:29 · Score: 1

Hah, you sound like you work in security. I swear, my security team would rather have me just sit and stare at a powered off machine than get any work done,
Re:So it's not just me by Anonymous Coward · 2017-07-11 16:10 · Score: 0

Maybe run your own NTP server on your LAN and have your XP boxes update their time from there rather than reaching out over the internet to do it?
Then again if these XP boxes aren't being used for anything time critical does it even matter if the time drifts a couple minutes a month?
Re:So it's not just me by Anonymous Coward · 2017-07-11 17:48 · Score: 0

Your parent's basement is not an 'office'.
Re:So it's not just me by superwiz · 2017-07-11 18:34 · Score: 3, Informative

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.

It's why people virtualize old PCs now. You run your old PC in a window.

One of the Windows XP computers claims to have been on for over 15 years.
32 bits of milliseconds is 49 days. Windows XP is a 32 bit system and a common way to measure how long it's been up is by issuing a system call which returns the number of milliseconds since the system startup.

--
Any guest worker system is indistinguishable from indentured servitude.
Re:So it's not just me by Anonymous Coward · 2017-07-11 18:38 · Score: 0

I beg to disagree.
The main office of Apple, where Macs were first built, is just a house garage.
Not sure, but it's either garage of Wozniaks family or Jobs'.
Re:So it's not just me by Anonymous Coward · 2017-07-11 21:31 · Score: 0

But if the number of ms since startup is overflowing and presumably wrapping, then the uptime would cycle between 0 and 0+49 days, and if signed, 0+/-24 days.
Not that I have any additional insight to offer, sorry...
Re:So it's not just me by Anonymous Coward · 2017-07-11 23:53 · Score: 0

They would prefer you to get a secure by design machine.
That is something Microsoft can't provide.
Re:So it's not just me by Megol · 2017-07-12 00:25 · Score: 1

I hope you are trolling. Macs weren't designed nor built in a house garage.
Re:So it's not just me by Anonymous Coward · 2017-07-12 06:18 · Score: 0

or he could just segment his network and disallow inbound originated traffic to them.
Re:So it's not just me by Agripa · 2017-07-13 07:50 · Score: 1

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.
It's why people virtualize old PCs now. You run your old PC in a window.
Great! Which driver do I install to virtualize old expansion ports so I can use the old hardware?
Re:So it's not just me by david_thornley · 2017-07-13 07:54 · Score: 1

It's not really secure if it can be powered on.

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Re:So it's not just me by Anonymous Coward · 2017-07-13 11:29 · Score: 0

I remember this function that my software would use called "GetTickCount". It would tell you the number of clock ticks from when the computer was first booted up. This was on Windows XP. GetTickCount would wrap every 14 days or so. And I think it had about a 12 to 14us granularity. Correct technical word is escaping me, but I mean that with repeated calls, it would only change value after 12 to 14us had passed.
Not sure how that equates to your Windows XP box thinking it had been up continuously for 15 years! Wow. But does have me curious on how Windows XP tracks up-time.
Lately it feels like the Windows Updates are flying fast and furious, with some insanely important update being required once a month, and usually requiring a computer reboot. I think we are lucky now if we get to keep a computer up w/o reboot for 7 days... Sigh.

Mark my words.... by Anonymous Coward · 2017-07-11 13:57 · Score: 0

Ticket marked as closed...
solution: Use MS Edge instead of chrome send to customer.

Re: The lock cycles were avg 200 Âs each by KiloByte · 2017-07-11 13:59 · Score: 1

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.

Happens on Win7 w/Chome startup by lpq · 2017-07-11 14:13 · Score: 1

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.

Re:Happens on Win7 w/Chome startup by bongey · 2017-07-12 07:56 · Score: 1

Umm building chrome from source, not using chrome.
Re:Happens on Win7 w/Chome startup by lpq · 2017-07-12 08:25 · Score: 1

Doi! Good point. My desktop (6 cores; 96GB; RAID0 of SSD's) becomes unresponsive every time I start Chrome, lasting about 5-7 seconds. It's annoying enough that I don't use Chrome. Never happens if I leave it up all the time, just on startup. I'm guessing maybe a graphics contention issue as each chrome window allocates its own graphics resources, but that's just a guess (have GTX1080 but it's limited by an older PCIe bus.
As for OP prob... haven't done enough builds on Win to notice any probs in that area.
I have noticed that Windows still seems to poll processes for various activities such that suspending a process in Windows can cause LONG delays in normal desktop functions.
Windows also has a fundamental block in that processes are started in 1 place, versus on *nix where processes spawn from any other process (i.e. distributed process spawning). It's likely there are several "choke points" that would become worse as more cores contend for single-threaded resource allocators.
Thanks for the clue-stick! ;-)

Re: Not just when closing a program by Miamicanes · 2017-07-11 14:13 · Score: 3, Interesting

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)

I would by Anonymous Coward · 2017-07-11 14:27 · Score: 0

Advanced power settings turn of hard disk never.
I found this fixed my ssd problems.

Re: SUCK A CHOAD, BEAUHD! by Anonymous Coward · 2017-07-11 14:28 · Score: 1

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!

I guess he doesn't use Excel.... by Anonymous Coward · 2017-07-11 14:33 · Score: 0

I guess he doesn't use Excel.... because with windows 10 if i hit Ctrl+c to copy a cell and i try and move the mouse... nada for about one second as well... i'm actually looking to downgrade to windows 7 at this point. I know it's not a big deal but just knowing i dished out for an i7 laptop and it sputters on simple things drives me nuts. At what point and how many bugs/security issues will it take for microsoft to do a ground up new OS? with everything it's learned up to now there should be a room somewhere doing this.

Re:I guess he doesn't use Excel.... by Anonymous Coward · 2017-07-14 03:07 · Score: 0

I guess he doesn't use Excel.... because with windows 10 if i hit Ctrl+c to copy a cell and i try and move the mouse... nada for about one second as well...
Cool anecdote, bro, but your problems are not universally shared.

Your mouse has moved by Anonymous Coward · 2017-07-11 14:35 · Score: 0

Your mouse has moved.
Windows must be restated for the change to take affect.
Restart Windows ? [Yn]

Re:Your mouse has moved by Anonymous Coward · 2017-07-11 18:45 · Score: 0

These things called "Menu" should only be found in restaurants, not an OS.
Real OS should just be usable by its command prompt or CLI not Menus.

Re:Windows has always been unresponsive to user in by gumbi+west · 2017-07-11 14:56 · Score: 1

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.

Process Lasso by bobbutts · 2017-07-11 15:03 · Score: 1

I wonder if Process Lasso would fix the problem. It solved a weird issue with Xplane11 for me.

A bug that scales exponentially with # of cores by Anonymous Coward · 2017-07-11 15:10 · Score: 0

I'm waiting for Microsoft to tell customers to use less cores.
Not sure if this is worse that Jobs and the "Hold Different" meme for Antennagate.

Re: SUCK A CHOAD, BEAUHD! by Anonymous Coward · 2017-07-11 15:12 · Score: 0

Take the strawman and SPRINT with it!!!

Spying by Anonymous Coward · 2017-07-11 15:13 · Score: 0

This is normal with Windows 10 - its busy spying on the user!

What is the context of CreateProcess? by Anonymous Coward · 2017-07-11 15:21 · Score: 0

If you create a process and have it inherit the parent console then this may happen when you have a long running parent that spawns a lot of child processes.

Re: What is the context of CreateProcess? by Anonymous Coward · 2017-07-11 15:23 · Score: 0

In this scenario, specify not to wire up the IO in the CreateProcess call. I wonder if they are running scripts or Lauren nching console applications to processs items.

Re: Not just when closing a program by viperidaenz · 2017-07-11 15:36 · Score: 4, Informative

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.

Re:Not just when closing a program by Billly+Gates · 2017-07-11 16:12 · Score: 1

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/

Meh... by Anonymous Coward · 2017-07-11 16:46 · Score: 0

Just as a side note, Fedora uses about 1.8GB of RAM after boot/login.

The Gnome desktop frequently crashes, killing all open desktop applications with it, it's very easy to get mouse pointer freezes, and don't even get me started about the state of the video driver stack in Linux - especially NVidia.

But yeah, I switched away from Windows as well.

All operating systems are going to have pathological edge cases, but jumping on a niche problem and running around like sky is falling is pretty childish.

Sounds like they are already fixing it as we speak. Try getting a Linux kernel patch for this turned around so quick.

In the meantime, before kicking off your build, turn down the process priority on the shell that you are using to kick off your build and see if that helps.

Re: SUCK A CHOAD, BEAUHD! by OrangeTide · 2017-07-11 16:56 · Score: 2

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

Why a toy OS on that system? by dbIII · 2017-07-11 17:08 · Score: 2

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.

Re:Why a toy OS on that system? by thegarbz · 2017-07-12 01:55 · Score: 1

Maybe he likes to actually use the platform that he's coding for.
Maybe there's no real difference* in end user performance for software that is doing work between Windows 7 and Windows 10.
*There is a difference: Windows 10 is marginally faster.
Re:Why a toy OS on that system? by tepples · 2017-07-12 04:51 · Score: 1

If you need to run MS compatible stuff MS Win7 and various MS server systems are available.
New copies of Windows 7 are no longer available from Microsoft, and Windows 7 will soon (within 3 years) lose security updates. Who has run this test on Windows Server 2016?
Re:Why a toy OS on that system? by dbIII · 2017-07-12 16:26 · Score: 1

*There is a difference: Windows 10 is marginally faster.
So the people advertising for it say, yet slowdown seems to be a common complaint among users. I don't have enough people using it to have more than anecdotes from the annoyed, but I strongly suspect that the advertising doesn't quite match reality.
Re:Why a toy OS on that system? by thegarbz · 2017-07-13 06:14 · Score: 1

So the people advertising for it say, yet slowdown seems to be a common complaint among users.
Not sure what advertising you're talking about. But I guess benchmarking of actual workloads and OS memory use do count as some form of "advertising".
Re:Why a toy OS on that system? by dbIII · 2017-07-13 11:20 · Score: 1

There's a difference between independent benchmarks and rigged demos referred to by salesfolk and there seems to be a lot of the latter.
That's just my opinion anyway from a small number of machines that seems to perform extremely poorly compared with MS Win7 machines.

It's not just the mouse. by Anonymous Coward · 2017-07-11 17:50 · Score: 0

My experiences with Windows 10 are that unlike it's predecessors, sound glitches occur in the OS at various points when there is resource contention.
Windows 10 seems to have a much greater latency serving interrupts than previous versions of Windows. In my case I was able to improve things by judiciously exchanging hardware components for a mix that causes the problem less. But at the core - I think Windows 10 is doing some things less well then previous Windows versions.

My conjecture is that it is the same thing.

what is he doing... by Anonymous Coward · 2017-07-11 18:33 · Score: 0

...compiling chrome on a windows box, when he could have compiled it on a linux box ?
then he could test it with WINE or a virtual windows computer afterwards!

Ok, I actually do develop software on a windows server, but that is not a choice made by me and I have yet to experience the desktop to be choppy. I do not believe the program I work on as nearly as large as the chrome project though

Probably out of resources by Lost+Penguin · 2017-07-11 18:58 · Score: 1

Windows is rather hoggish on hardware resources.

--
I am the unwilling control for my Origin.

Windows versus Linux implementation of DE by Anonymous Coward · 2017-07-11 19:03 · Score: 0

We came from the BSD / Linux or Unix land where kernel space is different from X server and all types of GUI (Graphical User Interface) / DE(Desktop Environment) in Linux world.
In the world of Windows, even GUI and painting of windows and its background (including the scroll bar) were all transferred (switched only in some old versions of NT4.0 or NT3.5 forgot the exact version) to kernel space for speed reasons. Modern Windows still has that feature, where GUI stuff were ALL DUMPED into kernel space.

The mouse freezing and mouse latency felt by this programmer in TFA is probably caused by something else like M$ Telemetry and a couple of deep IRQ's being done by OS.

captcha: bloating

Re: The lock cycles were avg 200 Âs each by tlhIngan · 2017-07-11 19:22 · Score: 1

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?

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.

Fork Bomb ! by BESTouff · 2017-07-11 19:35 · Score: 3, Insightful

Soo, that means that a simple DoS is possible via old-school fork bombs ? In 2017 ? Well done Microsoft !

Re:Fork Bomb ! by Anonymous Coward · 2017-07-12 16:21 · Score: 0

Is you computer named ACME?

Re: The lock cycles were avg 200 Âs each by Anonymous Coward · 2017-07-11 20:45 · Score: 0

Right, so the whitelist can be expanded to include a few hundred **useful** code points to improve the usefulness of the site.

WTF can't that be done?

And anyway, we have abusive posts using just the ANSI codepoints. Here's one: overly restrictive Unicode limits on Slashdot are a pain in the fucking arse and the dickheads in charge lined up against the wall...

BeauHD seems to be stealing stories by Anonymous Coward · 2017-07-11 21:16 · Score: 0

Original submission : Submitted by ewhac on Tuesday July 11, 2017 @08:44AM
https://slashdot.org/submissio...

Current article : Posted by BeauHD on Wednesday July 12, 2017 @02:10AM

When reading this article you can even see that he attributes ewhac

Longtime Slashdot reader ewhac writes:

title:

24 Cores and The Mouse Won't Move: Engineer Diagnoses Win10 Bug

article-text:

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 200S 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.

Is there some downvoting of stories going on to allow just certain people to be able to get their articles to the frontpage??

Re:BeauHD seems to be stealing stories by Anonymous Coward · 2017-07-11 22:24 · Score: 0

Well, the story is from Hackernews anyway, so you could just as well complain that /. is stealing stories.

Obligatory by TeknoHog · 2017-07-11 21:47 · Score: 1

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.

Since when.... by rew · 2017-07-11 22:33 · Score: 1

Since when does moving the mouse involve closing a process? Oh wait! Microsoft Windows.

Re:Since when.... by Megol · 2017-07-12 00:26 · Score: 1

Since when should one expect a technical forum to be full of know-nothings? Oh wait! /.

Re: Not just when closing a program by Zero__Kelvin · 2017-07-11 23:18 · Score: 1

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

Re:Obligatory: Windows Source Code leaked by coofercat · 2017-07-11 23:56 · Score: 1

I was going to say something like this: https://www.neowin.net/forum/t...

Re: The lock cycles were avg 200 Âs each by omnichad · 2017-07-11 23:56 · Score: 1

Yes. A whitelist that barely let's most of ASCII through. That hardly counts as support.

But not as big as.. by Anonymous Coward · 2017-07-12 00:29 · Score: 0

95.

Process in Windows by DrYak · 2017-07-12 00:34 · Score: 0

Not a program, a process.

Yup.
Windows sucks at multi-processing. News at eleven.

REMINDER:
- That's why on windows multi-threading is much more popular (there's a lot less to teardown when the context is shared).
- That's part of reasons why microsoft developed the concept of pico-threads (way much more lightweight) so that Windows Service for Linux (WSL. aka Bash in Windows. aka Ubuntu in a terminal) could actually implement some decent multi-processing.

That's why most serious computer has since long shifted away to other OSes (see popularity of Linux among TOP500)

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Re: Process in Windows by Anonymous Coward · 2017-07-12 04:10 · Score: 0

Among companies that can afford to hire 8 people to do the work of 1, Linux is super popular.
Among small businesses, where I recently watched one of our Linux users spend two weeks trying to dock his laptop, Windows still wins.
Re: Process in Windows by PoopJuggler · 2017-07-12 06:25 · Score: 1

What does docking have to do with the OS?

Firewalling a GPU by DrYak · 2017-07-12 00:48 · Score: 2

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 ]

OS and process scheduling by DrYak · 2017-07-12 01:06 · Score: 4, Insightful

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 ]

Re: The lock cycles were avg 200 Âs each by KiloByte · 2017-07-12 01:44 · Score: 1

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.

Wait 10 years.... by Anonymous Coward · 2017-07-12 01:51 · Score: 0

...you will have a quantum computer and the mouse will still get stuck.

Re:Wait 10 years.... by wafflemonger · 2017-07-12 02:48 · Score: 1

...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.
Re:Wait 10 years.... by Anonymous Coward · 2017-07-12 04:33 · Score: 0

I don't have a quantum computer but I am sure my physical mouse hardware performs this thing called entanglement on my mouse pointer.

Re:Not just when closing a program by Anonymous Coward · 2017-07-12 02:31 · Score: 0

No. If you have adequate RAM (system AND GPU) and using the same resolution as the desktop, switching to and from a full-screen app is instantaneous. 100 bucks says he's using an Intel GPU with shared RAM. *facepalm*

I bet.. by sycodon · 2017-07-12 02:44 · Score: 1

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.

Disney! by Zorro · 2017-07-12 02:53 · Score: 1

I read the title and thought it was about the Disney corporation.

Server 2012 / 2016 has same issue by AKCoder · 2017-07-12 02:54 · Score: 1

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)

NT was a stop-gap ... by Anonymous Coward · 2017-07-12 02:55 · Score: 0

Few now recall, but Microsoft built NT as a quick-n-dirty stop-gap OS while they 'completed' their new 'semantic' OS. Win10 is but the latest version of NT. The race to 'semantic' OS/File System designs crashed and burnt for mainstream computers- and ended up as a 'mobile' computing concept instead.

The consequence is that NT is a mess - a mass of bodges that have moved the OS onto multi-core and massive memory designs, with a GUI design that never moved from a single-core concept. Multi-tasking on NT still 'thinks' in terms of time-slicing on a single core. Bodges move the threads onto mutliple cores today, of course- but the 'logic' of the OS still 'thinks' in terms of one core.

This makes drivers particularly awful. The GUI prone to catastophic refresh failure. Individual programs on Windows can code to multi-cores much more effectively- although they are still at the mercy of an OS designed for one core when talking to resources beyond the CPU (like HDD, input devices etc).

Intel is largely to blame for when multi-core x86 designs first appeared from AMD, Intel's response was to pay tech sites to trash AMD and pay Microsoft millions to keep Windows Intel 'friendly'. Many of Windows horrible issues with driver latency and memory paging are down to Intel insisting that MS used poor coding methodology that made Intel parts SEEM faster than AMD.

Windows is the best GP OS we have by far, but it is still godawful compared to what it should be like after all these years. And the focus of Win10 doesn't help things.

2D tech is now way beyond the old 'blitter' by Anonymous Coward · 2017-07-12 03:09 · Score: 0

Screen refresh tech makes use of modern GPU functionality. But the CPU is so fast, it can do the 2D rendering at lightening speed as well. Modern browsers can switch between software and hardware render output with little difference save for video.

Modern Windows has a state-of-the-art screen composition engine again using the power of modern GPUs. How well this works depends on the application. Windows offers coding methods dating back to the stone age of the first versions of the OS- so apps need to use modern APIs to get the best from the OS.

Screen tearing is a VERY complex issue (ask any experienced gamer about 'vsync'). Methods to avoid tearing have pros and cons, and often the cons ain't worth it.

The GUI issue can be best explained by looking at the godawful Firefox as a metaphor. Firefox was designed around ONE THREAD - and current versions of Firefox are an NT like bodge attempting to move a horrible codebase to a multi-core situation. Firefox thusly scales like crap to more RAM or more cores. NT likewise was designed for one CPU core. Across the years it too has been bodged to a multi-core situation with loads more RAM.

Of course, MS uses the excuse of the insanely poor Intel designed driver model as why fixing things hardly matters. As soon as your program needs to talk to drivers on a regular basis, things grind to a halt anyway.

Re: The lock cycles were avg 200 Âs each by Anonymous Coward · 2017-07-12 03:10 · Score: 0

Perhaps they should block apostrophes?

FFS, it wasn't even a plural.

Re: SUCK A CHOAD, BEAUHD! by Anonymous Coward · 2017-07-12 03:13 · Score: 0

No, you were kicked off because you masturbate in gym class. I remember.

Re: SUCK A CHOAD, BEAUHD! by Anonymous Coward · 2017-07-12 03:15 · Score: 0

Actually it's more of a red herring than a strawman, as I was fully aware of when I posted it.

Use a PS/2 mouse by Anonymous Coward · 2017-07-12 04:08 · Score: 0

Perhaps in this situation the PS/2 mouse would be smooth, since it uses interrupts whereas USB mice use polling. PS/2 mouse tends to operate in bad conditions.

Obviously, good luck clicking on stuff and having it take effect then.

This looks very complex. What if say, explorer.exe is the misbehaving process, or the window manager/graphics subsystem trying to deal with hundreds of megabytes of dung is having a leak?
If you have 16,000 files and an application is spawning 16,000 threads to generate thumbnails or extract and present metadata, is that a GUI issue?

I agree some task killer would be good. In linux you have the alt-SysrRq thing but I haven't look how to enable/disable it and what's the key to kill a big task, but what I'd really want is just enough "reserved memory" to log in on the ctrl-alt-f1 consoles and have a few megs to run things like top, ps and kill. In Windows there's the task manager for that but as the desktop is a "3D" desktop you'll need some reserved GPU resources/memory as well.
There's also tasklist / taskkill commands in cmd.exe but I suppose less than 1% users know about them (and likewise, the command prompt is "3D accelerated" whether you care or not)

My old Loki version of HoMM3 says you lie! by Anonymous Coward · 2017-07-12 04:18 · Score: 0

Backwards compatibility in userland is definitely not always easy in Linux.

inverse moore's law by Anonymous Coward · 2017-07-12 04:23 · Score: 0

i have observed (ateast since 1989), that every year cpus get faster or denser but boot time remains the same.

Re: The lock cycles were avg 200 Âs each by omnichad · 2017-07-12 05:17 · Score: 1

This is why I never like to comment by phone. Autocorrect decided I didn't want to use a verb in my sentence.

Ash kor durbatulÃk by Pseudonymus+Bosch · 2017-07-12 05:32 · Score: 1

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

Comment removed by account_deleted · 2017-07-12 06:06 · Score: 1

Comment removed based on user account deletion

24 cores & 48 threads by Anonymous Coward · 2017-07-12 08:33 · Score: 0

RICH PEOPLE'S PROBLEMS

Mouse != pointer by StikyPad · 2017-07-12 09:25 · Score: 1

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

Re:kernels & technical progress... by lpq · 2017-07-12 11:23 · Score: 1

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?

Serialization of GDI disconnect not surprising by Anonymous Coward · 2017-07-12 16:28 · Score: 0

NtGdiCloseProcess() is the function that cleans up the given process' association with the system graphics context. This being serialized is not that surprising. It is possible that a prior implementation was faster but involved more locks and had a possible deadlock scenario.

What's with all the rabid Microsoft hate on this? Linux still has a single-threaded kernel file stat. This is WAY more damaging to overall performance than having a 200 microsecond lock on process exit which in the normal Windows system usage case is a fairly rare event. After all Microsoft threads are heavier than Unix processes. People who design software to run on Microsoft systems avoid creating and destroying threads, process creation and destruction is an even bigger no--no. The real problem here is a build tool chain that uses an archaic approach to task management. Microsoft's C# build compiles and links millions of lines of code in thousands of files in seconds using a single process.

Re:Serialization of GDI disconnect not surprising by Anonymous Coward · 2017-07-13 01:39 · Score: 0

Microsoft's C# build compiles and links millions of lines of code in thousands of files in seconds using a single process.
Is this post serious? Because my VS IDE can compile C# code 3 files in 5 minutes.
Maybe 2 requirements for "compiling in seconds". Either you must have a quantum computer, or your C# source files contains 2 lines of code each.

Microsoft is Investigating... With Their Lawyers by HannethCom · 2017-07-12 18:52 · Score: 1

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.

Re: Boners by Anonymous Coward · 2017-07-13 01:54 · Score: 0

Anti-malwarebytes makes my computer freeze!

like building a large application such as Chrome by Anonymous Coward · 2017-07-13 05:56 · Score: 0

that sounds more like a shitty build system tbh though ...

Re: The lock cycles were avg 200 Âs each by RockDoctor · 2017-07-15 00:50 · Score: 1

Hmm, having been complaining about Slashdot not supporting the sterling sign (Â£) for probably 20 years now, I still haven't noticed any improvement.

they decided to whitelist instead, by using a simple UTF-8 breaking filter of fixing the MSB to 0.

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"

School example of MT misunderstanding by Johan+Welin · 2017-07-16 03:53 · Score: 1

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.

:facepalm: by Anonymous Coward · 2017-07-17 14:57 · Score: 0

Still sticking with Windows 7.

Slashdot Mirror

24 Cores and the Mouse Won't Move: Engineer Diagnoses Windows 10 Bug (wordpress.com)

352 comments