(11-13-2012, 03:07 PM)Runo Wrote: But then you're saying someone with the right skills could multithread a single chip emulation without losing performance over cores? Cause I never heard of someone that did this (A dev from Dolphin emulator team tried a while back, he wanted to write a multithreaded JIT that split the emulated CPU thread into two logical threads, but he gave up, and he told us over the IRC channel he wasn't gaining much speed even if it was using all of his CPU cores, because of the need for tight thread syncing)I'm planning to add real multi-threading for the PSP threads in Jpcsp. Jpcsp is already using multiple cores for the emulation of the PSP hardware, but the PSP threads are currently always running one at a time (like on a real PSP). Most of the applications coded for the PSP do however already use thread synchronization (Mutex/Sema/EventFlag/...) internally. But they were never tested on a real hardware multi-threading, as the PSP has a single MIPS CPU
The emulated CPU is single cored, so it works in serialized manner. Even if you parallelize the emulation one thread will need to wait for the other, I don't see how that could be optimized.
. This feature would be available as an option, for PSP applications programmed in a thread-safe way 
.The most difficult part for this approach will be to make the Jpcsp HLE calls thread-safe (or they could be sequentialized automatically). The implementation of sceKernelCpuSuspendIntr/sceKernelCpuResumeIntr which are often used by PSP applications to protect a critical section is also a challenge. On a PSP, these 2 calls are lightweight and do not involve much overhead. On a truly multi-threaded system, they would imply to stop all the other running threads, which is not obvious without adding too much overhead.
The point is, when going beyond the capabilities of the emulated system, a solution doesn't have to be 100% perfect. It can be offered as an option or can work only under some conditions.