5 ms·

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared t

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

bombolo 4y ago
I think it could be ok to have a link every once in a while that doesn't talk about rust.
- zaphodias 4y ago
  We're talking about C++ and performance, no way nobody would mention rust :P
abyesilyurt 4y ago
My key learning is the importance of balancing performance and code cleanliness instead of blindly adhering to clean code principles.
- Ygg2 4y ago
  If you optimize for readability performance would suffer. If you optimize for performance readability will suffer. Casey prizes performance over everything else.
  - pkolaczk 4y ago
    In this particular case I find the code optimized for speed (the one using switch) to be also more readable and simpler than the code using virtual dispatch. The problem with virtual calls in a big project is that there is no good way of knowing what is the target of the call, without some additional tooling like IDE. But in case of a switch/if, it is pretty obvious what the cases are.
    - karma_fountain 4y ago
      I do agree. I've looked at code bases where the switch was replaced with virtuals and the like. It's kind of hard to navigate around the code when that happens. I think I'd usually rather have a completely separate path through the code rather than switch or virtual, making the decision at the highest level possible, usually the top-level caller.
    - Ygg2 4y ago
      Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. Then you get people writing their own horrible hacks. Both clean code and performance oriented design have their extremes. Clean Code has Spring with Proxy/Method/Factory monster... and hyper performance has the extreme in the story of Mel (i.e. read-and-weep only code).
      - TeMPOraL 4y ago
        > Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. You get to push back and ask, is it worth the developer time and predicted 1.5 - 5x perf drop across the board (depending on shape specifics)? In some cases, it might not be. In others, it might. But you get to ask the question. And more importantly, whatever the outcome, you're still left with software that's an order of magnitude faster than the "clean code" one. Clean code "assumes code will be changed/maintained" in a maximally generic, unconstrained way. In a sense, it's the embodiment of "YAGNI" violation: it tries to make any possible change equally easy. At a huge cost to performance, and often readability. More performant code, written with the approach like Casey demonstrated, also assumes code will be changed/maintained - but constraints the directions of changes that are easy. In the example from video, as long as you can fit your new shape to the same math as the other ones, the change is trivial and free. A more complex shape may force you to tweak the equation, taking little more time and incurring a performance penalty on all shapes. Even more complex shape may require you to rewrite the module, costing you a lot of time and possibly performance. But you can probably guess how likely the latter is going to be - you're not making an "abstract shape study tool", but rather a poly mesh renderer, or non-parametric CAD, or something else that's specific.
oleg_antonyan 4y ago
Indeed. If anything this demo shows how badly C++ polymorphism performs. It doesn't necessarly means that all OOP languages created equal. Although I have no data to prove anything, and frankly don't care b/c all these arguments about clean vs dirty code are meaningless in an absence of formally defined rules and metrics universally enforced by some authority that can revoke your sw dev license or something like that
- TeMPOraL 4y ago
  > It doesn't necessarly means that all OOP languages created equal. Exactly - unless you're trying very hard, you're unlikely to beat C++ polymorphism with your OOP code in a different language. Which makes Casey's argument that much stronger. C++ with its relatively unsophisticated OOP and minimal overhead on everything, is as fast as you're going to get, so it's good for showing just how slow that still is if you follow the Uncle Bob et al. Clean Code tradition.
  - hayley-patton 4y ago
    > C++ with its relatively unsophisticated OOP and minimal overhead on everything, is as fast as you're going to get No it isn't. If your C++ compiler isn't devirtualising at all (implied by the article) it'll get stomped on by anything doing inline caching [0] which will generate the switch-case code. The JVM does that for example. [0] https://bibliography.selflanguage.org/_static/pics.pdf https://bibliography.selflanguage.org/_static/pics.pdf
bakugo 4y ago
I'm surprised I had to scroll down this far to find the obligatory Rust evangelist comment.

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

bombolo 4y ago

I think it could be ok to have a link every once in a while that doesn't talk about rust.

zaphodias 4y ago
We're talking about C++ and performance, no way nobody would mention rust :P

abyesilyurt 4y ago

My key learning is the importance of balancing performance and code cleanliness instead of blindly adhering to clean code principles.

Ygg2 4y ago
If you optimize for readability performance would suffer. If you optimize for performance readability will suffer. Casey prizes performance over everything else.
- pkolaczk 4y ago
  In this particular case I find the code optimized for speed (the one using switch) to be also more readable and simpler than the code using virtual dispatch. The problem with virtual calls in a big project is that there is no good way of knowing what is the target of the call, without some additional tooling like IDE. But in case of a switch/if, it is pretty obvious what the cases are.
  - karma_fountain 4y ago
    I do agree. I've looked at code bases where the switch was replaced with virtuals and the like. It's kind of hard to navigate around the code when that happens. I think I'd usually rather have a completely separate path through the code rather than switch or virtual, making the decision at the highest level possible, usually the top-level caller.
  - Ygg2 4y ago
    Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. Then you get people writing their own horrible hacks. Both clean code and performance oriented design have their extremes. Clean Code has Spring with Proxy/Method/Factory monster... and hyper performance has the extreme in the story of Mel (i.e. read-and-weep only code).
    - TeMPOraL 4y ago
      > Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. You get to push back and ask, is it worth the developer time and predicted 1.5 - 5x perf drop across the board (depending on shape specifics)? In some cases, it might not be. In others, it might. But you get to ask the question. And more importantly, whatever the outcome, you're still left with software that's an order of magnitude faster than the "clean code" one. Clean code "assumes code will be changed/maintained" in a maximally generic, unconstrained way. In a sense, it's the embodiment of "YAGNI" violation: it tries to make any possible change equally easy. At a huge cost to performance, and often readability. More performant code, written with the approach like Casey demonstrated, also assumes code will be changed/maintained - but constraints the directions of changes that are easy. In the example from video, as long as you can fit your new shape to the same math as the other ones, the change is trivial and free. A more complex shape may force you to tweak the equation, taking little more time and incurring a performance penalty on all shapes. Even more complex shape may require you to rewrite the module, costing you a lot of time and possibly performance. But you can probably guess how likely the latter is going to be - you're not making an "abstract shape study tool", but rather a poly mesh renderer, or non-parametric CAD, or something else that's specific.

oleg_antonyan 4y ago

Indeed. If anything this demo shows how badly C++ polymorphism performs. It doesn't necessarly means that all OOP languages created equal. Although I have no data to prove anything, and frankly don't care b/c all these arguments about clean vs dirty code are meaningless in an absence of formally defined rules and metrics universally enforced by some authority that can revoke your sw dev license or something like that

TeMPOraL 4y ago
> It doesn't necessarly means that all OOP languages created equal. Exactly - unless you're trying very hard, you're unlikely to beat C++ polymorphism with your OOP code in a different language. Which makes Casey's argument that much stronger. C++ with its relatively unsophisticated OOP and minimal overhead on everything, is as fast as you're going to get, so it's good for showing just how slow that still is if you follow the Uncle Bob et al. Clean Code tradition.
- hayley-patton 4y ago
  > C++ with its relatively unsophisticated OOP and minimal overhead on everything, is as fast as you're going to get No it isn't. If your C++ compiler isn't devirtualising at all (implied by the article) it'll get stomped on by anything doing inline caching [0] which will generate the switch-case code. The JVM does that for example. [0] https://bibliography.selflanguage.org/_static/pics.pdf https://bibliography.selflanguage.org/_static/pics.pdf

bakugo 4y ago

I'm surprised I had to scroll down this far to find the obligatory Rust evangelist comment.