• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Windows 10 Process-Termination Bug Slows Down Mighty 24-Core System to a Crawl

Who the hell builds a workstation with one 24 core processor? These processors are meant to be used in multi-socket boards....you would never see just one of these in a system as it would be cheaper to just get 2P 20 core chips.
 
Another reason that Windows 10 just pees me off, even though I am not running a workstation. All I wanted is to have no driver issues and have a better gaming experience without slowdowns, what do I get? More spying and whatnot.

I am an early adopter, Win 10 was fine for the first few years. Now MS just c**ked the OS with stupid updates to add more tumors to their crap kernel which is decades old.

They said there would be no new Windows numbered versions. Which means things are just going to get worse rather than better.

And developers are also taking only baby steps because the OS is just a mess now.

F*** the consumer, right? Nobody cares anymore.
 
Last edited:
EntropyZ said:
Another reason that Windows 10 just pees me off, even though I am not running a workstation. All I wanted is to have no driver issues and have a better gaming experience without slowdowns, what do I get? More spying and whatnot.

I am an early adopter, Win 10 was fine for the first few years. Now MS just c**ked the OS with stupid updates to add more tumors to their crap kernel which is decades old.

They said there would be no new Windows numbered versions. Which means things are just going to get worse rather than better.

And developers are also taking only baby steps because the OS is just a mess now.

F*** the consumer, right? Nobody cares anymore.
Click to expand...

Naah, 10 is improving. They have cocked up updates in the past but they've been stable for a while now.
 
With that said....

Google should of been using their Chrome OS
 
notb said:
That was really smart.
And now maybe some sufficient condition rather than a necessary one? :)
Click to expand...


Run a marathon?

What sort of 'sufficient condition' are you looking for?
 
notb said:
I'll put it differently. Do you think Chrome OS covers all OS needs of a Google employee?
Click to expand...

They built it so I assume they can make it work for them. Its based off unbuntu or linux
 
The Chrome OS part. Read this, there's no mention at all about Ubuntu in the article.
 
trparky said:
The Chrome OS part. Read this, there's no mention at all about Ubuntu in the article.
Click to expand...

Hence why i said "unbuntu or linux" in my post

Either/Or etc
 
you have to be a troll or a dimwit to even think that they should use chrome OS on a fucking development workstation.

chrome OS is a lightweight end user OS which is mainly web only for shit hardware devices. Where in that is a proper development environment for a super high end desktop?.

ffs people talking because oxigen is free
 
L'Eliminateur said:
you have to be a troll or a dimwit to even think that they should use chrome OS on a fucking development workstation.

chrome OS is a lightweight end user OS which is mainly web only for shit hardware devices. Where in that is a proper development environment for a super high end desktop?.

ffs people talking because oxigen is free
Click to expand...

They could have other dev versions of Chrome OS you know.

the absence of evidence is not the evidence of absence
 
and why would they even consider using such a end user os for development when you already have windows, once you have windopws you don't need anything else
 
L'Eliminateur said:
and why would they even consider using such a end user os for development when you already have windows, once you have windopws you don't need anything else
Click to expand...

Because development is in house and it wont grind to a stop like microsoft.
 
jaggerwild said:
Why is this on "HeadLines"? Look like a bunch of bozos, but hey......
Click to expand...

He works for google and probably (actaully, nearly certainly) makes more than you and me combined.

That said, I probably am not much of a factor and am the biggest bozo here, lol.

FordGT90Concept said:
My guess is he had 48 processes (one per logical core) running that were killed at once. He noticed the 125 ms hitch and investigated by trying 1000. 48 is a lot; 1000 is crazy. Visual Studio only uses 4 or 5 processes usually.
Click to expand...

Ah, I see now. Threads vs processes elluded me for a bit (been a while since I programmed). This is indeed a crappy build method if it's all processes, though not uncommon inside unix-land.
 
Anything a process can do a thread can also do with far fewer resources. Processes are really only useful for compartmentalization but when the threads are all carrying out a related task, there's really no need for that either. Having everything in one processes also greatly accelerates communication internally (all can stay in the RAM). Cross-process memory accessing is frowned upon unless it's absolutely necessary (e.g. interfacing directly with the operating system).

I think there is only two scenarios where multiple processes makes sense:
1) Experimental, distributed applications like BOINC. You want them separate for stability, security, and control reasons. They usually never finish at the same time even if you have 1000 projects running so even that is very unlikely to expose this bug.
2) Application updaters because you can't modify a running application. Usually only main application + updater and they never really ever run at the same time so no problem here either.

A process is effectively a collection of related threads.


I'm curious how *nix behaves in the same situation (closing 1000 processes in rapid succession).
 
Last edited:
I think we are missing the point here...
A thread has a shared resouce pool with its parent process and its thread relatives. if you load a file in a thread that file is concurrently accessible by every relative thread and by the main process app.
When you are building an application and you have a shared library all the threads that are trying to read code from that library will try to access that file at different times or the same time. While compiling, you rely on different temporary resources to write to and read from; 10 thread doing this work have to have a mechanism to do not write and read from the same shared resource. So if you think about memory footprint and resource destruction, the point of having threads in spite of processes makes little to no difference. You will have to load in memory a different version of you application for every thread you spawn and you have to have a lot of control code. It will be slower, unsafer and probably as slower to unload.

Now take the process spawning approach.
You develop a simple working application, you spawn that 10 times in 10 different processes and you are done.
 
Now I know you're not serious.
 
You must log in or register to reply here.
Back
Top