FordGT90Concept
"I go fast!1!11!1!"
- Joined
- Oct 13, 2008
- Messages
- 26,259 (4.44/day)
- Location
- IA, USA
System Name | BY-2021 |
---|---|
Processor | AMD Ryzen 7 5800X (65w eco profile) |
Motherboard | MSI B550 Gaming Plus |
Cooling | Scythe Mugen (rev 5) |
Memory | 2 x Kingston HyperX DDR4-3200 32 GiB |
Video Card(s) | AMD Radeon RX 7900 XT |
Storage | Samsung 980 Pro, Seagate Exos X20 TB 7200 RPM |
Display(s) | Nixeus NX-EDG274K (3840x2160@144 DP) + Samsung SyncMaster 906BW (1440x900@60 HDMI-DVI) |
Case | Coolermaster HAF 932 w/ USB 3.0 5.25" bay + USB 3.2 (A+C) 3.5" bay |
Audio Device(s) | Realtek ALC1150, Micca OriGen+ |
Power Supply | Enermax Platimax 850w |
Mouse | Nixeus REVEL-X |
Keyboard | Tesoro Excalibur |
Software | Windows 10 Home 64-bit |
Benchmark Scores | Faster than the tortoise; slower than the hare. |
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).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.
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).