The virtual function is often used as one of solutions to accept the same source code to different environment. This way makes surface of source code beautiful, but it is not good performance because virtual functions are heavy process. Programers who work on real time application think that’s beautiful way but feel that isn’t ideal performance.
Because compilers generate indirect-jump with a function pointer table from virtual function, CPU’s branch prediction feature is not useful for a such situation. It surely triggers pipeline-stole. If a perfect JIT will be completed in the future, the perfect JIT will be useful for this situation. But, there is not a such JIT now.
Virtual functions are very good approach. But we hope to fix as many as possible of the function address. If there are some functions that we don’t need to handle as abstract functions at runtime, address of those functions should be fixed to let CPU use direct-jump. Let’s say you have to develop the middleware that can be used for both of PS3 and Xbox360. Firstly, you may plan to use virtual functions to abstract different between two platforms. But, imagine use of game software. Users never able to change platform while they are playing the game.
In other words, developers decide which libraries to link when compiling. The middleware you’re developing makes it possible that developer compile each application for multi-platform from the same source code, so you may supply the plural include files and libraries for each platform. Developers will write each makefile. Because this approach doesn’t use virtual functions, most function address will be fixed. And, some of them will be compiled as inline-functions.
A such approach is one of standard approaches of multi-platform programming. We take the approach for the following purpose.
- Writes inline-assembly code on multi-platform that has different CPU.
- Changes JIT of game script for multi-platform that has different CPU.
- Solves the different compilers and different compiler versions.
- Changes link libraries to their debug edition or others.
Maybe the approach is also useful for script programming. We often focus on the “runtime-compile” feature of the script program environment. But, the environment has also the “runtime-link” feature.
Let’s say you have to write functions that remove platform difference between PHP4 and PHP5. The platform condition is not changed at runtime. Therefore, when program tries to include a file declaring the functions, you may prepare two files for each platform. That’s like the approach of C/C++. C/C++ can change include-path and link-library by platform conditions. And, that’s better performance than the approach that each function checks platform and changes execution.
That’s one of standard approaches if our language is C/C++. However, the script programming world has the different common sense from C/C++. Therefore developers who work on PHP may not agree the approach that change include-file by platform condition.
Like this:
Be the first to like this post.
. Because the discussion was streaming broadcasted in the net. Unlike other members of the panel, I don’t involve the web business, so I hoped to protect my privacy.
