   JIT compiling for C++
  Modern day game engines are extremely large. Abstraction is used to control the complexity of the code.In the case of C++ this is done through class hierarchies with virtual functions. However, virtual functions cause a performance hit since a function pointer table needs to be accessed to find out the function to execute and then to subsequently execute that function.I was wondering if its possible to implement a JITish system to remove the overhead of virtual function calls.My understanding of virtual functions is as follows:(1) Access the vtable using the index of the function to be called.(2) Call the function.Uses of JIT compiling for C++:In the case of game programming JIT compiling could be used at the beginning of the program. For example, when the gamer selects the rendering API to use (DX or OpenGL) maybe the JIT could kick in and specialize the code path for the selected API only. Likewise the techniques used for rendering (soft shadow, shadow volume, shadow mapping, etc.) could be specialized based on what the gamer wants.This is similar in idea to JIT compiling used in Java. Instead of byte code being converted to native code, native code is optimized to run faster based on user preferences.So what do you people think. Will such a system work?all best.   
  It would be easier to do without the virtual function calls and instead do something along the lines of the relocation table to patch up the pointers.;  Calling a virtual function has nearly no overhead over calling a normal function. For example, VC++ adds only 2 asm instructions: an indexed mov and a jump:...  ...  call vfunc  ...vfunc:  mov eax, [ecx+8]  jmp [eax]real_func_code:  ...instead of ...  ...  call real_func_code  ...real_func_code:  ...As you see, the penalty is rather small, and a JIT compiler is a big tool to reduce such penalty.   ;  Plus, if I am reading this right, it would only work for classes that had virtual interfaces but were fixed at the start-up stage and would not work for polymorphic hierachies where the type can vary during run time.As Troll has already said, it is perfectly plausible to implement something in existing C++ with function pointers yourself, avoiding breaking or altering the existing system.   ;  Any solution involving function call indirection is identical to using virtual functions, so anything involving relocation tables or function pointers is just reinventing the C++ runtime (I'll guarantee yu it will be buggier and less efficient than letting the C++ runtime handle it).The only way you could eliminate the tiny speck of a performance hit would be to have some sort of dynamic loader reimplements what the dynamic loader already does when it loads a DLL at startup, except rather than backpatching addresses on DLL load, it would backpatch addresses in the existing loaded executable image.Given the nightmare of backpatching a running image (especially with modern CPUs that don't allow writes into code space at runtime from a non-privileged execution level), I wouldn't think this is worth it for an immeasurably small performance gain.If you're concerned about the cost of virtual function calls, make sure you don't use virtual functions inside tight loops. Any other place you should take a powder and not worry about their cost.  The solution is in your design, not creating some monster of a tool to wipe a bad programmer's bottom.Remember, premature optimization is the hallmark of inexperience.   ;Quote:The solution is in your design, not creating some monster of a tool to wipe a bad programmer's bottom.That's the funniest thing I've heard all day. :D   ;  Thank you for your replies!Emmanuel Deloget: I'll go read up more on ASM and hardware architecture. My impression had been that although it is only 2 instructions there must be quite a bit of cost involved since the location of the virtual table must be found, loaded into cache etc. Multiplying this cost for all functions as part of overhead gave me the impression it was little expensive. Again, thanks for correcting my notion.EasilyConfused: Yes, you are right. It works for cases where the user will set it at the beginning of the game. For example, as a difficulty setting too (to select the type of AI maybe).Bregma: I was not really seeing this as a premature optimization. Its more like a tool that could run through the code at the initialization stage. Again, its for the special case of choosing the code that has to be run at the beginning of the game. Hence I do not see any special design coding for this to work.thanks!anis   ;  What you seem to be suggesting is for a process to happen when a game is run that is similar to the link-phase of compilation.Firstly, this would have to be performed as a seperate process to the main program, before it is run.Secondly, it would require a final exe to contain the same information as a .obj file in terms of locations of function calls and so on, which may not be desirable from the point of view of preventing reverse engineering of your code or exposing propriatory information. I mean, you can run implib on a dll to link to the functions it EXPORTS, but it doesn't preserve information about all the functions it calls internally, at least not in a form that can be easily extracted.Lastly, I don't really understand the arguement about caching. The majority of graphics APIs would be implemented as dlls anyway so whether you statically link to them or link dynamically via vtables (which are likely to be in the same page as your exe) I do not see a difference in the likelyhood of page faults. I appreciate this is not normally what is meant by static and dynamic linking but you know what I mean.Not a bad idea in principle (sort of) but complexities seem to far outweigh benefits in a real example.