• 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

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.
If you're talking about DLLs, the main process loads them and keeps them in memory. Links and stuff, you have a linker pool that all threads query or update. If there's instances where cross-thread references can't be allowed, you write the code so only one thread can do it at a time (not a lock, invoke the owning thread).

Spawning lots of processes is just developer laziness relying on the operating system for locks and catching appcrashes instead of doing it yourself (at a huge performance boost).
 
i googled gomacc.exe and nothing really comes up for it.

Goma is a distributed compiler infrastructure used by buildbots, and gomacc.exe is GOMA C Compiler executable
 
Spawning lots of processes is just developer laziness relying on the operating system for locks and catching appcrashes instead of doing it yourself (at a huge performance boost).

I strongly disagree.
As a distributed compiler that can run a build on hundreds of networked machine the GOMA compiler team had to chose the same old viable solution between Time/cost/performance.
you can spawn build task on networked machines, you can spawn tasks on you local machine, all with the lowest possible effort and cost.
I don't call it lazyness, I call it software engeneering.
 
ever since i got windows 10, my mouse ramdomly stutters :( Havent played war thunder in ages :'(
 
I strongly disagree.
As a distributed compiler that can run a build on hundreds of networked machine the GOMA compiler team had to chose the same old viable solution between Time/cost/performance.
you can spawn build task on networked machines, you can spawn tasks on you local machine, all with the lowest possible effort and cost.
I don't call it lazyness, I call it software engeneering.
And there's absolutely no reason why a single process per machine can't accomplish the same thing at substantially less memory load.
 
Because you have an already working open source compiler, you develop a build manager, add a layer to the compiler to respond to commands and you have your distributed build manager in a year instead of 5?
 
As I said, lazy developers.

It's 50/50 on Microsoft changing anything because there is definitely a design flaw in the software this guy is using.
 
Back
Top