PCSX2 said for 5 years it would never use more than two cores, as it would cause the same problems discussed here. Sync issues, and not a big performance difference.
Fast forward to 2011, and we have MTVU, a speed hack to use a 3rd core...which sped up alot of games up to 40% in some CPU limited instances. Dolphin may have something like that someday. I mean the developers themselves said there would never be and would be no benefit...but it did happen, and there was.
So never say never.
(01-30-2012, 01:17 AM)Mkilbride Wrote: [ -> ]PCSX2 said for 5 years it would never use more than two cores, as it would cause the same problems discussed here. Sync issues, and not a big performance difference.
Fast forward to 2011, and we have MTVU, a speed hack to use a 3rd core...which sped up alot of games up to 40% in some CPU limited instances. Dolphin may have something like that someday. I mean the developers themselves said there would never be and would be no benefit...but it did happen, and there was.
So never say never.
That's already been explained in this thread if you bothered to read. For PCSX2 it is possible due to the hardware in the PS2 which is multi-core by design to begin with, but for Dolphin there is nothing that can be split further without creating serious issues and would offer no benefit to performance. In the Wii/GC there is the CPU (Broadway), GPU (Hollywood) and the DSP which already have their own threads. Other things like input have their own thread but these use very little CPU power to begin with so no performance is gained. In the past skid tried to multi-core the fifo but quit as there was no benefits gained in terms of performance and would have most likely created additional issues.
Trying to make code designed to run on a single core environment (That's ALL Wii and GC Games for that matter) run on a multi-core environment is asking for crashes, memory corruption, etc. That's why we are given the option to "Lock threads to Cores", to increase stability and performance on 3+ core environments, in case the game (or Dolphin) can't handle being thrown around random cores or (hyper)threads.
Sure, you can make code thread-safe by implementing synchronization (and many other checks: it's a real hassle, as I myself like to code, albeit in a somewhat more simplistic matter), but that would negate the performance increase given by separating processes over multiple cores: The faster process would have to wait for a slower one to finish in order to be able to continue anyway.
A very simple example would be:
You want to build a new rig, and have 4 companies to order from. The CPU you need takes 5 days to deliver at all companies. All other parts vary between 1 and 3 days across all companies. Even if you were able to place your orders as to where every part would be delivered the next day, you'd still need to wait another 4 for the CPU. You would have no benefit at all from ordering at different companies, so you might as well order everything at one company, and save yourself any delivery fees.
Now replace the following words:
build = start
new rig = calculation
company/companies = core/cores
CPU = Main Value
days = milliseconds
deliver/delivered = calculate/calculated
part/parts = value/values
orders/ordering = threads/threading
delivery fees = Synchronization checks
We ought to be grateful the devs made so many speed hacks available for us to use, or else we wouldn't even be able to make any game run at a playable speed.
As a basic rule of thumb: "you need about 10x the speed of the original hardware to properly (read accurately) emulate it"
So for the Wii, which has a 729MHz CPU, you would need a CPU @ ~7.3GHz. And that's just for the CPU thread. We'd still need at least a GPU thread to be actually able to do anything. THAT process can be threaded to another core or another physical processor, since the Code (game) is designed to be able to handle that separately. That is exactly what Dolphin does already when "enable dual-core" is checked.
Also, take in account all the enhancements Dolphin offers over the Wii Hardware, like raising internal resolution (up to 4x, as of the moment writing this reply), Anti-Aliasing, Per-pixel-lighting calculations, etc., which the Wii itself isn't able to handle, because it lacks the processing power to do so.
Theoretically speaking, we should be able to emulate GC games at full-speed with the current CPU's (485MHz * 10 = ~4.9GHz). If we would turn off all enhancements, that is...
Quote:"Lock threads to Cores", to increase stability and performance on 3+ core environments, in case the game (or Dolphin) can't handle being thrown around random cores or (hyper)threads.
....um.....no.....it has absolutely nothing to do with that. The developers wanted to get rid of that option because it was pointless until it was revealed that locking the thread affinity helped laptops with turbo boost reach higher frequencies and could improve performance. This option does not affect stability at all.
Quote:As a basic rule of thumb: "you need about 10x the speed of the original hardware to properly (read accurately) emulate it"
.....not sure where on earth you got that from but that's completely wrong. There is no magic number for this. It depends on the hardware used in both platforms and what kind of software logic would be needed to emulate the other platform with your hardware. The processing power requirements could be 2, or 10, or 100, or 1,000, or 10,000. It varies A LOT based on the design of the two platforms rather than the processing power.
All emulators must also make some sort of tradeoff between accuracy and performance. The design of the emulator and how much accuracy it aims to achieve also has a huge impact on how demanding it is (as evidenced by the fact that some SNES emulators need 20 times the processing power of others).
And then there is the software to consider. Some games may only need a factor of 2 in processing power while others need a factor of 100. This is dependent on how the software uses the hardware and what type of software logic is needed to emulate that behavior. Some games may also require more accurate emulation than others so if you change the options the different in performance requirements can be even higher.
So no, I think that you'll find that there is no general rule of thumb for this.
Quote:So for the Wii, which has a 729MHz CPU, you would need a CPU @ ~7.3GHz.
Clock rate != performance.
Quote:THAT process can be threaded to another core or another physical processor, since the Code (game) is designed to be able to handle that separately. That is exactly what Dolphin does already when "enable dual-core" is checked.
Actually the software (game) is not designed to handle that separately. But the hardware does.
Quote:Theoretically speaking, we should be able to emulate GC games at full-speed with the current CPU's (485MHz * 10 = ~4.9GHz). If we would turn off all enhancements, that is...
No we shouldn't. The enhancements you speak of only increase GPU load.
Quote:Sure, you can make code thread-safe by implementing synchronization (and many other checks: it's a real hassle, as I myself like to code, albeit in a somewhat more simplistic matter), but that would negate the performance increase given by separating processes over multiple cores: The faster process would have to wait for a slower one to finish in order to be able to continue anyway.
Now this is a good point to make, something people rarely understand. I just wanted to say that so that my post didn't seem totally negative.
(01-30-2012, 03:28 AM)arthur117 Wrote: [ -> ]up to 4x, as of the moment writing this reply
I don't think this is an actual restiction, afaik you can rescale it to arbitrary resolutions by changing a single line of code. It just doesn't make very much sense.
(01-30-2012, 07:20 AM)NaturalViolence Wrote: [ -> ]Quote:"Lock threads to Cores", to increase stability and performance on 3+ core environments, in case the game (or Dolphin) can't handle being thrown around random cores or (hyper)threads.
....um.....no.....it has absolutely nothing to do with that. The developers wanted to get rid of that option because it was pointless until it was revealed that locking the thread affinity helped laptops with turbo boost reach higher frequencies and could improve performance. This option does not affect stability at all.
Actually it causes some games not to boot
Can you prove it was the lock threads to cores option that caused it? It seems like you changed a lot of options.
oh man your system is wrecked
nice you got 100% cpu on a amd x2
you graduated to pikachu
sneaky oil
http://forums.dolphin-emu.org/showthread.php?tid=14853
(01-16-2012, 10:16 PM)dannzen Wrote: [ -> ]Twilligt (New Save, in Town, 4x IR, Texture to Ram, rev 371)
1. Enabled Lock Threads to Core + LLE on THREAD + OPEN MP
36-38% CPU Usage
40-43FPS
3. Disabled Lock Threads to Core + LLE on THREAD + OPEN MP
36-38% CPU Usage
40-43FPS
2. Enabled Lock Threads to Core + LLE + OPEN MP
24-25% CPU Usage
37-38FPS
4. Disabled Lock Threads to Core + LLE + OPEN MP
24-25% CPU Usage
37-38FPS
![[Image: 10603259.png]](http://imageshack.us/photo/my-images/854/10603259.png/)