There's far more to multi-threading than just loading stuff in the background, like using a thread to perform physics calculations while the other core is rendering, which of course gives you a lot more power. There are certain synchronization issues when using multiple threads, so the entire program itself would have already had to been set up for it in the beginning.
Quote: "PhysX is also multi-threaded, as is DarkAI, I believe."
I doubt it does it in a way that takes advantage of multiple cores/processors.
In order to properly implement multi-threading in a way that it takes advantage of multiple cores, you have to make sure the separate operations they perform can be performed asynchronously - because if one operation has to wait for the other to finish, you are gaining nothing but context switching overhead. In terms of a game, the most performance costly thing is the rendering itself, so one needs to try to asynchronously perform the second most costly operation while this is happening.
For example if you want to calculate physics during rendering, the physics thread needs to keep a local copy of the object data that it can modify without messing up the render thread's data. When the physics thread has performed its operation, it can set a signal to tell the main thread (render thread) that it can copy the new data into the main copy of the object data. Thus, when the rendering is finished, the main thread copies this data, and then performs the next loop.
