From what i have read, dolphin uses 2 cores for working.
Since a lot of new CPUs has 3 or more cores, is not possible to make dolphin use all of them? or is it difficult to implement?
It is possible but would require massive amounts of code restructuring and would have little benefit. Dolphin actually has the ability to run dsplle (low level audio emulation) on a third thread but work on this was abandoned after the devs realized that it only resulted in a 5% speedup on average and created desyncing problems (it's difficult to keep the graphics and audio threads in sync with each other when they are on different cores). It is unlikely that dolphin will ever use more than 2 cores since it is nearly impossible to make any efficient use of more than 2.
Thanks for the clarification, i know nothing of programming so i hope this was not a stupid question.
99% of programmers would not be able to understand this in depth. Most programmers write simple applications in simple languages using programs that then compile them into executables. They do not need to know anything about hardware to do this and do not need to have a clue how multithreading can be used. What the dolphin devs are doing is far beyond simple programming. They are trying to fake hardware in software, which requires understanding the hardware on a very in-depth level. Multithreading is rarely used because for most simple applications it isn't needed and the amount of effort and learning needed to properly implement it is insane. I mean you are basically taking a program that performs a task and trying to figure out how to turn that into several programs that perform different tasks that are involved in performing the main task. It gets even more complicated when the tasks are dependent on each other or need to stay in sync with each other.
i am a programmer and somewhat understand the complexity of multithreading. however, i have only written several multi-threaded java programs which were quite basic. i will say that, although maybe too big of an undertaking for an opensource project, making the dolphin emu run in more than 2 threads should be possible. for example: bad company 2 utilizes all 4 of my cores and evenly distributes the load so that each core will have nearly the same usage (~60%). i know dolphin is emulating hardware, and syncing is an issue but, with bc2 is utilizing 4 of my cores and 2 of my gpus simultaneously while evenly distributing the load. i know this is a forever old argument but its hard not to think of the possibilities when dolphin is sometimes using 100% of one've my cores when i have 2 3.8ghz cores sitting there doing nothing and a 4th one with a lot of overhead left.
Dolphin could use 4 cores since their are 4 things that need to be emulated. One core to emulate the cpu, one to emulate the gpu, one to emulate the dsp, and one to emulate the input. However since dsp and input emulation reuire so little throughput this would result in maybe a 5% speedup if you're lucky at the expense of being massively more complicated and creating terrible desyncing problems that would take a long time to sort out. That is the only way for dolphin to use more than 2 cores since all of the stages of a recompiler have to be on the same core for obvious reasons. Their is simply no other way to multithread it. And their is certainly no way to magically get the load to balance itself across the threads. Right now dolphin uses 2 cores, one for cpu emulation and the other for dsp/gpu emulation (they are on the same thread in order to make it easier to keep them in sync with each other). If you know anything about multithreading than you know that every application can only be multithreaded so much depending on the type of application it is. Dolphin is the wrong type of application for multithreading, an application that uses a lot of dependent operations that need to be executed in an ordered and sequential manner. Comparing it to something like bc2 and saying that just because they can do it means we can to is stupid since that is a completely different type of application.
What NaturalViolence is saying is very
LOGICAL !!! , CPU's mainly Do Things in a Serial Way, i.e "Sequentially". as the original PowerPC is just One Core which can only do "serial-processing"....CPU emulation thread wont benefit that much from being split !! i no nothing about coding and little about hardware but i guess that splitting the CPU thread will just let it be slower !! same about
GPU ....
we just have to wait for the code to improve in performance and accuracy , also Dlist Cache-though doesnt seem very promising- might speed things up in the future
or just buy a better CPU or wait for a new Powerful architecture ..
I'm not a programmer, but I think they could be easily offended by saying that 99% of this people do not understand the complexity of multithreading.
Multithreading is widely used now, specially on the graphic applications field, where it yields the best results, since graphics by nature are prone to parallel processing.
Even in simple applications, serious programmers must take in account multithreading when deploying, since virtually all OS'es are "multithread ready".
Quote:What NaturalViolence is saying is very LOGICAL !!! , CPU's mainly Do Things in a Serial Way, i.e "Sequentially". as the original PowerPC is just One Core which can only do "serial-processing"....CPU emulation thread wont benefit that much from being split !! i no nothing about coding and little about hardware but i guess that splitting the CPU thread will just let it be slower !! same about GPU ....
That's not what I meant at all. I was referring to tasks which need to complete all of the operations in a specific order one at a time in order to work.
Quote:I'm not a programmer, but I think they could be easily offended by saying that 99% of this people do not understand the complexity of multithreading.
Multithreading is widely used now, specially on the graphic applications field, where it yields the best results, since graphics by nature are prone to parallel processing.
Even in simple applications, serious programmers must take in account multithreading when deploying, since virtually all OS'es are "multithread ready".
Well 99% of PEOPLE are not programmers. So I stand by my argument. And multithreading is not as widely used as you might think, over 80% of applications are simple applications that are not multithreaded and have no need for multithreading. Do you honestly think a word processor is going to run any faster if it's multithreaded? Not to mention for many applications multi-threading is flat out impossible due to way the application works. For most applications multithreading is just plain stupid. You're right about visual applications though. Multithreading is usually a good idea with visual applications. But you have to realize just how simple most applications are. If you go around asking C++ programmers if they have ever made a multithreaded application you might get 1 out of 50 saying yes. Even intel admits that less than 1% todays programs can be efficiently multithreaded beyong 4 threads. Which is why it concerns me that they are employing the the "just increase the number of cores" strategy so much. I think it's going to backfire on them eventually the same way their "just increase the die size" strategy bit them in the ass back in 2004-2006.
Well, in many cases there is just no use for multithreading, for many people this concept can be hard to understand. But still, any decent programmer should know how to take advantage of this when needed. We are in the multicore crazyness which I also think it's kinda out of control. More cores doesn't mean better performance, as Dolphin itself proved. Two or three cores at most, but that's just it.
It's really interesting to see how computing has been switching from parallel to serial computing and vice-versa over this years. I've never imagined that serial communications could achieve those amazing transfer rates, when everybody was thinking that parallel was the way to go.
And about Dolphin, we are really lucky to have a multithreaded emu. It's really hard to optimize this kind of programs.