Comments on: Virtual Functions Considered Not Harmful, Part I http://phresnel.org/blog/2009/02/virtual-functions-considered-not-harmful-part-i/ D'Oh! (feel free to leave me a mail at "phresnel.gmail@com , swap @ with . for proper mail) Mon, 29 Mar 2010 07:27:12 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: phresnel http://phresnel.org/blog/2009/02/virtual-functions-considered-not-harmful-part-i/comment-page-1/#comment-11 phresnel Mon, 29 Mar 2010 07:27:12 +0000 http://phresnel.org/blog/?p=51#comment-11 Maciej: That's of course true. In very complex cases, the CPU will get into trouble. What I really wanted to show is that, if your code can signifcantly benefit from virtual functions, and if it is not too nested/complex, then you should consider using virtual functions. Maciej: That’s of course true. In very complex cases, the CPU will get into trouble. What I really wanted to show is that, if your code can signifcantly benefit from virtual functions, and if it is not too nested/complex, then you should consider using virtual functions.

]]> By: Maciej http://phresnel.org/blog/2009/02/virtual-functions-considered-not-harmful-part-i/comment-page-1/#comment-10 Maciej Mon, 29 Mar 2010 05:08:59 +0000 http://phresnel.org/blog/?p=51#comment-10 Interesting read but in my opinion your virtual function profiling is a bit incomplete. The real performance trouble with virtual functions shows up when you have more complex code than just simple vector operations and you're trashing your CPU caches (L1, L2) a lot. Imagine your CPU cache being completely invalidated - in that case before calling virtual function you must load virtual table to your cache first, then check address of the code to jump to, then load function to your cache. Non-virtual function call needs just an address. If your application has hundreds of classes with thousands of virtual functions being called in random order all over the time, then you're likely to be experiencing lots of cache misses for your virtual tables. Interesting read but in my opinion your virtual function profiling is a bit incomplete. The real performance trouble with virtual functions shows up when you have more complex code than just simple vector operations and you’re trashing your CPU caches (L1, L2) a lot.

Imagine your CPU cache being completely invalidated – in that case before calling virtual function you must load virtual table to your cache first, then check address of the code to jump to, then load function to your cache. Non-virtual function call needs just an address.

If your application has hundreds of classes with thousands of virtual functions being called in random order all over the time, then you’re likely to be experiencing lots of cache misses for your virtual tables.

]]>