3 ms·

I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfa

I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfairness. These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I've never seen anyone seriously try to write computer graphics while "keeping functions small" and "not mixing levels of abstraction". We can go further: you won't be going anywhere in computer graphics by trying to "write pure functions" or "avoiding side effects". These "clean code principles" are, however, rather useful for large, corporate systems, with loads of business process rules maintained by different teams of people, working for multiple third parties with poor job retaining. You don't need to think about vector performance for processing credit card payments. You don't need to think about input latency for batch processing data warehouse jobs, but you need this types of applications to work reliably. Way more reliably than a videogame or a streaming service. Right tools for the right jobs, people need to stop trying to hammer everything into the same tools. This is not only a bad practice in software, it's a bad practice in life, the search for an ever elusive silver bullet, a panacea, a miracle. Just drop it and get real.

gjulianm 4y ago
Exactly! I work with a lot of high-performance code and also a lot of non-high-performance code (think all the plumbing around the core computation) and I definitely use a lot of "clean code patterns" in the non-performance-critical parts. They're the ones that tend to change more, that more people touch, that get done faster... It's just about knowing what to use and when.
tomn 4y ago
> you won't be going anywhere in computer graphics by trying to "write pure functions" or "avoiding side effects" Not sure about this; in my experience (in a different domain, audio processing) you totally can get away with both of these a lot of the time. Function inclining works well, so you can write small pure functions in a lot of cases (especially if you accept a function that reads from one buffer and writes to another as pure). As for avoiding side effects, this is normally more about keeping your state updates small and localised (allowing more parts to be pure), which is often not a problem performance-wise. IME it's much easier to improve the performance of a piece of code which is easy to reason about and change with some level of confidence that your optimisation will not break things. I know there's some unavoidable global state in computer graphics, but presumably there is lots of code that doesn't directly touch that.
scotty79 4y ago
Yeah, but why is good and fast opposite rather than orthogonal? Why languages and compilers are not built so at least we can do both. Or even better, why is good and fast not the same thing in computer languages?
- whstl 4y ago
  Good point. But I'd point that languages and compilers are built so we can have both. The problem is some definitions of good really aren't, and it isn't just because they're slow, it's because they make some things "good" at the detriment of others. Uncle Bob's Clean Code is really good at making some portions of the code "good" and "simple", but when put together they are interconnected in ways that are more difficult to understand.
overgard 4y ago
Yes and no, I think that what can happen if you only focus on "performance critical code" is the rest of your code is slow and incredibly unfriendly to cache, but there's absolutely nothing you can really do about it past a point. Like, if all your code is 5x slower than it possibly could be, then even after you fix the performance critical bits you have this ugly tax everywhere else that you can't do anything about other than a rewrite. And I do think that matters, look at various projects written in a language like python where bits have been written in C, but you still have all this slow interpreted stuff. (I like Python btw, I'm just making a point that if performance matters it doesn't just matter in loops)
zackoverflow 4y ago
> These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I agree that this is mostly true, but maybe not for beginners in the field When I was reading "Raytracing in One Weekend" (known as _the_ introductory literature on the topic), I was very surprised to see that the author designed the code so objects extend a `Hittable` class and the critical ray-intersection function `hit` is dynamically dispatched through the `virtual` keyword and thus suffers a huge performance penalty This is the hottest code path in the program, and a ray-tracer is certainly performance critical, but the author is instructing students/readers to use this "clean code" principle and it drastically slows down the program. So I agree most computer graphics programmers aren't writing "clean code", but I think a lot of new programmers are being taught them because of introductory literature

gjulianm 4y ago

Exactly! I work with a lot of high-performance code and also a lot of non-high-performance code (think all the plumbing around the core computation) and I definitely use a lot of "clean code patterns" in the non-performance-critical parts. They're the ones that tend to change more, that more people touch, that get done faster... It's just about knowing what to use and when.

tomn 4y ago

> you won't be going anywhere in computer graphics by trying to "write pure functions" or "avoiding side effects" Not sure about this; in my experience (in a different domain, audio processing) you totally can get away with both of these a lot of the time. Function inclining works well, so you can write small pure functions in a lot of cases (especially if you accept a function that reads from one buffer and writes to another as pure). As for avoiding side effects, this is normally more about keeping your state updates small and localised (allowing more parts to be pure), which is often not a problem performance-wise. IME it's much easier to improve the performance of a piece of code which is easy to reason about and change with some level of confidence that your optimisation will not break things. I know there's some unavoidable global state in computer graphics, but presumably there is lots of code that doesn't directly touch that.

scotty79 4y ago

Yeah, but why is good and fast opposite rather than orthogonal? Why languages and compilers are not built so at least we can do both. Or even better, why is good and fast not the same thing in computer languages?

whstl 4y ago
Good point. But I'd point that languages and compilers are built so we can have both. The problem is some definitions of good really aren't, and it isn't just because they're slow, it's because they make some things "good" at the detriment of others. Uncle Bob's Clean Code is really good at making some portions of the code "good" and "simple", but when put together they are interconnected in ways that are more difficult to understand.

overgard 4y ago

Yes and no, I think that what can happen if you only focus on "performance critical code" is the rest of your code is slow and incredibly unfriendly to cache, but there's absolutely nothing you can really do about it past a point. Like, if all your code is 5x slower than it possibly could be, then even after you fix the performance critical bits you have this ugly tax everywhere else that you can't do anything about other than a rewrite. And I do think that matters, look at various projects written in a language like python where bits have been written in C, but you still have all this slow interpreted stuff. (I like Python btw, I'm just making a point that if performance matters it doesn't just matter in loops)

zackoverflow 4y ago

> These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I agree that this is mostly true, but maybe not for beginners in the field When I was reading "Raytracing in One Weekend" (known as _the_ introductory literature on the topic), I was very surprised to see that the author designed the code so objects extend a `Hittable` class and the critical ray-intersection function `hit` is dynamically dispatched through the `virtual` keyword and thus suffers a huge performance penalty This is the hottest code path in the program, and a ray-tracer is certainly performance critical, but the author is instructing students/readers to use this "clean code" principle and it drastically slows down the program. So I agree most computer graphics programmers aren't writing "clean code", but I think a lot of new programmers are being taught them because of introductory literature