"Clean" Code, Horrible Performance

If you want something real, look at Clean Code Horrible Performance youtube video if you haven't. I also found Bob Martin entertaining, but after trying to follow his suggestions I just got into the trap that Casey Muratori shows: even if I don't care about the performance of the code at the start, the amount of abstractions Uncle Bob advises makes it just too easy to make the code extremely hard to optimize later. ▶ this video

You may enjoy “"Clean" Code, Horrible Performance”, from Casey Muratori. ▶ this video Casey specialises in game engine research and development link And has an ongoing course on computer performance for programmers. link

Look at Casey Murrey's Clean Code horrible performance youtube video: ▶ this video I also watched clean code videos and used it in practice, and why it _felt_ right my code size blew up and actually it got harder to understand by other people instead of easier. Nowdays my main guidelines are getting a balance between less lines of code (while still readable), readable variable names and better performance. Also I may get hate here for it, but I learned a lot from watching George Hotz programming tinygrad (available on YouTube).

The issue with those books is that they don't have any concrete data that affirms that they are worth following. And, in fact, that style of code is largely to blame for why modern software feels so sluggish. They often reduce performance by 10x if not 100x or worse. I like this video on the topic for reasons not to follow SOLID principles[0]. Muratori also has an excellent talk on writing APIs that are flexible and performant[1]. As for books on understanding the hardware performance, Computer Systems: a Programmer's Perspective, is the best example (not the international edition though, according to the author's recommendation). I'm not aware of any architecture books recommended by anyone that cares about performance unfortunately. Most high performance software is written iteratively, meaning they aren't assuming a code structure from the start. Andreas Fredriksson, a lead engine programmer at Insomniac Games, has an excellent quote on how he writes high performance software[2]: > Work backwards from hard constraints and requirements to guide your design. Don’t fall into the trap of designing from a fluffy API frontend before you’ve worked out how the thing will handle a worst case. Don’t be afraid to sketch stuff in while you’re proving out the approach. > The value is what you learn, never the code. Hack it and then delete the code and implement “clean” or whatever you need. But never start there, it gets in the way of real engineering. > As an industry we spend million

> What resources do you recommend folks at my level look into? I'd argue that your best bet for learning is starting a project that drives you, then throwing that project away and starting it over again but try to make the code simpler. This way you can hone into what abstraction is actually necessary to solve your problem. I strongly recommend ignoring design patterns and instead honing in on what the essential data flow is in your problem space. Most design patterns will bloat your code base and, thus, slow both your program and your programming velocity down. As far as programming design and architecture goes, the best talks I have found come out of data orientated design talks. Casey Muratori has a number of talks well worth listening to[0][1][2]. I also enjoy Andrew Kelley's talk on Data Orientated Design specifically as it demonstrates DOD's power with actual numbers to back it up[3]. Tangent: I did my time with OOP design + trying to make my code 'clean' according to popular recommendations you'll see online. All of that time, I consider wasted because I focused too much on what the 'right' abstraction to use was, instead of solving my problem in the simplest way possible. I find now that often the best solution is the one that uses the least amount of abstraction and indirection. (E.g. One big function can be a lot easier to maintain than multiple little functions, you just have to develop a taste for when a function should be split up and why). (If you must have a pa

Another commentor succinctly pointed out one argument against RAII+friends is that it encourages thinking about single objects, as opposed to bulk processing. In many contexts, the common case is in fact bulk processing, and programming things with the assumption that everything is a single, discrete element creates several problems, mostly wrt. performance, but also maintainability. [1][2] > The whole point of an arena allocator is the exact opposite of RAII Yes, agreed. And the internet is rife with people yelling about just how great RAII is, but comparatively few people have written specifically about it's failings, and alternatives, which is what I'm asking about today. [1] ▶ this video [2] link

bugs* ironic It depends on whether you approach programming from a perspective of writing piles of obviously correct abstraction layers (the total effect of which is to leak so much the solution ends up being wrong anyway), or from the direct unabstracted perspective of actually making the computer do what you want it to do (which does not preclude the solution from using abstractions). I call them the Uncle Bob vs Casey Muratori school, after Casey's lectures such as "Clean Code, Horrible Performance": ▶ this video

See for example this playlist of videos of his with some videos from 2021 where he implements a terminal emulator. As he says himself, this project is not so much about terminals as it is about software development practices in general. link See also this video of his: “Clean” Code, Horrible Performance ▶ this video

Not GP but: Personally, I find that book's advice is highly subjective and rooted on aesthetics rather than pragmatism or experimentation. It encourages an excessive number of very small methods and very small classes, and brushes off problems that it causes. Not about the book, but: Its influence is malignant. Even Uncle Bob mentioned in a recent interview that he will break the "10 lines per method" rule if need be. But practitioners influenced by the book lack his experience, and are often very strict. I even remember a specific Ruby linter that capped methods at 5 or 6 lines max IIRC. Working in such a fragmented codebase is pure madness. This comment from another user made me remind some of those codebases: link EDIT: After living in the "Clean Code world" for half a decade I can categorically say that it produces code that is not only slow to run (as argued by Casey Muratori [1]), but also slower to understand, due to the jumping around. The amount of coupling between incestuous classes and methods born out of "breaking up the code" makes it incredibly difficult to refactor. [1] ▶ this video

Thanks for the thoughtful reply. > Well it's hard to argue about that tradeoff in general, but I think the existence of languages like Python, Ruby and PHP is compelling. Though I'd accept the argument that they help optimise for neither performance nor changeability! I see the point you're making, and I don't disagree with it. But I should be a bit more clear in what I really meant in my parent comment: Given whatever language a developer is working in, whether it is fast like C++ or a slow language like Python (or perhaps even Minecraft Redstone), I think the programmer that takes a data oriented approach (meaning they write their code thinking about the kinds of data the program can receive and the kind it will likely receive, along with what operations will be the most expensive) will have better code than a programmer that makes a nice object model following all the SOLID principles. The majority of the OOP code I've worked with spends too much time caring about abstractions and encapsulation that performance is lost and the code is no better to work with. > Regarding the DOD/OOP wars, I really love this article, which argues that OOP doesn't have to be bad[1]. I also think that when performance is a requirement, you just have to get more particular about your use of OOP. For example, the difference between Mesh and InstancedMesh[2] in THREE.js. Both are OOP, but have very different performance implications. Absolutely agree here. Classic gamedev.net article. ECS != DOD

1. Single-thread performance This is hardly related to HPC. The closest thing maybe code optimization and competitive programming. First learn how to do anything fast in single process, then think about scale it up later. 2. Parallel programming Learn MPI. Specifically mpi4py. Once you go MPI, you never use python's multiprocessing module (it sucks). But stuffs are mostly about solving linear algebra problems, which I am not that interested in. 4. Distributed Computing Related to MPI. But nowaday distributed GPU computing become a thing, thing that I can think of is Dask. Don't know how to use that. link 5. Quantum Computing Completely unrelated to HPC, at least in the near future (10 to 30 years). Areas that is the most active in this field is molecular computation. If you don't have a phy/chem PHD, you are not able to read anything beyond college level stuff in this field. And those are only basics stuff like elementary schools' arithmetics. But write your own program to solve those quantum problems in classical computers is interesting, because people there only think about problems that cause scaling issue, not the others. That's why some may think that quantum computer is a replacement of supercomputers. If you can find ways and invent techniques that can reduce timecomplexity in terms of classical algorithm, you are welcome. And literally there is a lot of room for anyone because every quantum computer emulator is unoptimized and slow as hell. Google, Microsoft, IBM,