Check this:
The author of Corn has written an excellent explanation of why Corn is so fast. He has also sent me some trouble shooting tips.
Various reasons for Corn's speed:
1. Static Recompilation Static rec is the main technique that Corn experiment wants to test. In theory, static rec should be faster than dynamic rec since the branch/call overhead is much lower. And, with static rec, we can afford to do sophisticated optimizations like a real compiler does. Although the actual implementations can greatly affect the real performance.
On the other hand, static rec becomes the major deficiency of Corn. It makes corn need individual configuration to run each rom. So, in terms of compatibility, it is not a good approach. Probably this is the main reason why other emulator authors did not try it before(in my knowledge). Between compatibility and speed, most authors will choose the former. If Corn was not started as an experiment, I would have chosen dynamic rec also.
Right now, the optimization done in Corn is still simple. So, probably not much speed (10%-25%?) really come from this part at this time. Later, I will try to apply more advanced optimization techniques to study the power of static rec, which is the main goal of this experiment.
2. 32bit vs 64bit As first mentioned by UltraHLE, practically N64 games are 32bits programs. However, there do exist 64bit instructions in some (though very rare) OS functions. Since UltraHLE emulates OS functions, this is not a problem. Corn uses low-level emulation (for CPU part), so it must single them out and patch them. This is another place where compatibility is greatly lowered. I guess 20%-40% speed come from this part.
3. Incomplete emulation The RDP emulation in Corn is still very incomplete. Many effects, features have not been implemented. Some very time-consuming things are ignored. There is almost no support for combine modes, just some sort of hack. Honestly, Corn still needs lots of work to reach the stage that Nemu and TRWin achieved. I expect at least 30% speed drop of RDP emulation in the furture. Also, Audio task is short-circuited. As Corn implements more and more features, speed come from this part will disappear. I guess currently 30%-60% speed come from this part.
4. Implementation issues I has a relatively low-end pc. So, I have to push the speed in every corner. Once I suspect that a C compiler cannot optimize some part very well, and that part is important, I use inline assembly codes. For example, C cannot handle bit operations very efficiently, so in Corn, most of this job is done by inline assembly codes. There are many such things. Each of them is not significant, but when they add up, I guess the contribution is about 20%-50%.
5. Some bad things A good program should have codes to handle errors, extreme cases etc. They are not existent in current version of Corn. Corn always assumes a good run-time environment. It may be practically acceptable, but definitely not a good programming style. I guess 5%-10% speed come from this part.
The above percentages are just my feelings. They may be wrong.
