noob2222 :
Game devs for the most part don't want to. they want to fight the power, use legacy code so they don't have to re-write their data. the problem is that other software companies are making use of multiple cores, photoshop, encoding, 3d graphics, ect.
I note photoshop, encoding, and Rendering are all easy to make parallel.
-Fran- :
You can have smart ways of using more than 1 heavy thread, but you'll depend on the OS scheduler to do it's job decently.
Gamerk has a valid point in regards to the "lock/threading" curve, since one of the main points behind it is "inter-dependencies". If you can design and make good arch calls of your program (in particular to this talk, the game engine), you can probably get rid of most of that "locking" or "messaging" overhead and have a fairly good threaded program that makes great use of the available processors (virtual or real) via the scheduler.
Now... I think you're going to the other extreme of this, gamerk. We're just in the neighborhood of 8 CPUs (and 4 becoming mainstream) and with that many, there isn't a big penalty for every split/extra process to handle stuff around.
There are key threads to every program design that has to be alone for the most part (hopefully, in one CPU), but you're always on the scheduler's hands on this one. Unless you want to hard code, which is not such a good idea for the long term like you said.
The main concern is all the under the hood stuff the OS does. Every time a thread (any thread, not even for your program) needs to access RAM, you get a lock in place while data is read/written. Have enough guys doing memory access, and you can easily start to leak performance. Same logic applies within an application when threads need to share data: One thread has to put some form of lock in place while it does its work, and if another thread needs to get in there, to bad, it has to wait. Have enough threads doing heavy work on the same data set, and you very quickly run into the problem where you spend just as much time making sure the right thread has access to the right data then you do doing any actual processing. [Hence why you will never see a linear increase in performance as you add more cores. Diminishing returns is the rule here.]
In theory, you could get around this by coping all the relevant data, but with most apps still compiled as 32-bit, the old 4GB memory barrier quickly comes into play. Nevermind how much extra RAM this would eat up...
Then you get into my main point: If two separate threads need access to the same data, and the processing will be happening in some pre-determined order, then why are you even making a separate thread in the first place?
Ags1 :
As a developer I would like to point out that threading is often the only practical solution to a computing problem. Even a simple case like a progress bar typically involves parallel processing - one thread for the user interface and another thread for the task itself. You need the separate threads to keep the UI responsive regardless of the heavy processing going on in the task.
First thing ANY program that does any amount of processing should do: Make a separate thread so the UI thread always will be able to run, regardless of workload. Its inexcusable the UI should lock up under any circumstances.
Think about how this would be implemented in a single fat core processor: a single thread of code would have to simulate separate threads for the UI and the task. This is more complex and harder to do than simply having real separate threads. In the old days, some languages simulated hardware threads with virtual threads because parallel processing was not available: pretending to have parallel processing was an easier programming paradigm than the then reality of a single fat core.
Totally wrong (at least as of Windows 95). Even when you had a single core, you still had multiple threads. The OS simply juggles threads to give the illusion of everything running in realtime (or close enough where you don't notice). Windows uses a Round-Robin Priority Scheme: The highest feasible (ready to run, not I/O blocked) thread always runs, with priority for feasible threads getting boosted over time to ensure they eventually run, with a bias to foreground processes (as of Vista/7).
Prior to Windows 95, we had to manually give up our timeslice once we were done processing, or risk other threads not getting a chance to run. All modern OS's ditched this approach, and its now the responsibility of the OS scheduler to handle thread management (thank god).
Again, the number of processor cores has no correlation to the number of threads an application can use. The ONLY thing increasing the number of cores does is allow more threads to run at a single time.
Facebook
Twitter
Instagram