We already have a thread for each vehicle, why not take it to the limit? A thread for every part would create a performance boost on many systems. If it's possible to do, doing it should be a high priority.
That wouldn't make any sense. There are too many parts to allow them to each have their own thread. Plus what happens when you start adding vehicles? This would just create more problems than it's worth.
While I agree it would create problems (syncing that many threads on some vehicles will be a PITA), it wouldnt particularly impact the number of vehicles that can be simulated. Windows is already managing a massive amount of threads at one time already, just open task manager to the processes tab, each of those is a thread. There is a little timer in the CPU which triggers windows to manage threads periodically. Windows just decides which thread(or threads if you have multiple cores) is running at one time and which core to run it on, it can even decide that if the current threads are low priority enough that you don't need core 3 and because there is a load on core 2 it may be easier to shut down the also unneeded core 1 leaving 0 and 2 running, 1 and 3 shut down to save power. All windows will do is spread the various threads out as it sees fit. Shouldnt be a problem besides syncing them all. Considering the homepage mentions OpenCL support, I think just waiting for that is a better idea than majorly restructuring the physics core right now.
Totally agree. This could also help AMD users fully utilize 8 core CPUs But single-core performance would still be an issue
not as much as 1 vehicle would be spread across all 8 cores AMD's low BeamNG performance I think comes from shared floating point units, that is 1 major difference architecturally between Intel and AMD, in an AMD Module (2 cores) there is only 1 floating point unit, an intel CPU has 1 floating point unit per core.
Cars on different threads aren't attached to each other. What happens when the thread for the wheel executes just fine but a system level interrupt gains CPU access at a higher level than the axle causing the axle thread to lag behind momentarily.
From your standpoint just adding threads maybe sounds like a good idea but from a technical standpoint things are way more complicated. The main problem with threads is their overhead and mainly syncronization between them. More threads mean more RAM usage because 1 thread cannot use easily the resources of another thread. With resources i don't mean resources like a texture or a model but just the basic physic data, movement and position, velocity, etc. This stuff still has to be collected in a mainthread per part per vehicle, making this the ultimative bottleneck of your 100s of threads per vehicle. You can't just make a new thread for a fender and one for a shock and one for a door etc. Without a mainthread syncronizing each part they wouldn't even know that the car is moving. So instead of having the overhead of 100s of threads and 1 mainthread syncronizing them we now got what probably is the best approach. A single thread per vehicle that already does the job the mainthread-job, without the overhead of syncronizing 100s of threads. With this you're having a single thread that already has all the data it needs, it iterates over each part of the vehicle, syncronized their movement, shape,... and done. Not even speaking of the limits of the Operating System, you can't just throw 100 threads on a CPU and hope the software will go faster.
The physicsengine knows nothing about parts. After you select parts and spawn the car, beamNG generates a big jbeam out of all the selected parts and throws it at the physics.
