Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualsamoth

Posted 19 December 2012 - 09:34 AM

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.

Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss. Multiplied by a million.


EDIT: Found what I was looking for, there is a good summary on the pitfalls of OO: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

I remember there being another one (if I could find it now... I think it was on Gamasutra or something from GDC) which was much more radical, entirely condemning OO for performance reasons. That's a bit too harsh in my opinion. OO Performance can become a problem, but not if you are a bit savy.

#4samoth

Posted 19 December 2012 - 09:28 AM

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.

Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss. Multiplied by a million.

#3samoth

Posted 19 December 2012 - 09:27 AM

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.

Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss.

#2samoth

Posted 19 December 2012 - 09:27 AM

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of such a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.

Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss.

#1samoth

Posted 19 December 2012 - 09:25 AM

In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.

Virtual function calls are an example of such a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles.
Now, in the worst case, you do a million calls and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss.

PARTNERS