Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

401–410 of 932 posts

Re: “Clean” code, horrible performance

#401

Post by bcrosby95 »

magicalhippo wrote: post #299
p1necone wrote: post #293

Earlier quoted context omitted.

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

Then again, thing's aren't in the critical path until suddenly they are. Regardless of scenario I will never willingly do a O(n^2) sort when writing new code. Just in case those 10 items suddenly turn to 10000 one day.

The moon doesn't fall into the ocean until it does.

Re: “Clean” code, horrible performance

#402

Post by saagarjha »

Taniwha wrote: post #333
stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

Occasional CPU architect here .... probably the worst thing you can do in your code is to load something from memory (the core of method dispatch) and then jump to it, it sort of breaks many of the things we do to optimise our hardware - it causes CPU stalls, branch prediction failures, etc etc There is one thing worse you can do (and I caught a C++ compiler doing it when we were profiling code while building an x86…

Most people do neither, but call into something that may do these things.

Re: “Clean” code, horrible performance

#403

Post by hinkley »

andai wrote: post #169
krapp wrote: post #92

Earlier quoted context omitted.

If you're talking about Handmade Hero, the real answer to programmer happiness is not using a language you despise and refusing to leverage the features of, not refusing to use libraries in that language or frameworks, not re-implementing everything from first principles, and to actually have your game designed first (not designing while you code.)

Doing things without libraries (except the stuff built into Windows XP?) is the whole point of the project.

But the results of living in a contrived environment is that there are no guarantees that at the end you will understand 'normal' environments better or just be over-trained on your fictitious one.

Re: “Clean” code, horrible performance

#404

Post by loup-vaillant »

GrumpySloth wrote: post #364

This thread is, predictably, another demonstration of conflating optimisation with being aware of performance. The presented transformation of code away from “clean” code had nothing to do with optimisation. In fact, it made the code more readable IMO. Then it demonstrated that most of those “clean” code commandments are detrimental to performance. So obviously when people saw the word “performance”, they immediately…

Agreed, but most people here haven't paid for the rest of the course, and Casey sometimes forgot that here he's addressing a wider audience.

For instance he fails to explain why he didn't bother addressing the tail of his unrolled loop. He does in the course, but here he's just assuming it's irrelevant, and doesn't address again potential criticism like "he doesn't even bother to write correct code, look at that lazy unrolling!".

Thankfully there's a free lecture that explains the broad concept with an example. It's this lecture that convinced me to try out his course, where I hope he'll go into more details: https://www.youtube.com/watch?v=pgoetgxecw8&list=PLEMXAbCVnm...

Re: “Clean” code, horrible performance

#406

Post by hinkley »

dgb23 wrote: post #237
pocket_cheese wrote: post #189

Earlier quoted context omitted.

Could you elaborate what you mean by "naive indexes"?

Not GP. But you can often anticipate where indexes have to go for common queries. There might be some important colums like say a “status” or a “date”, which are fundamental to a lot of queries. Or you have colums X and Y being used frequently or importantly in where clauses together, then that’s a candidate for composite indexes. Stuff like that.

I think historically people had a lot of bad intuitions about how effective non-composite indexes are in databases. That if I have an index for A and an index for B I should be able to do A & B and get a quick answer.

There's been a lot more educational material on composite indexes and in particular partial indexes and so I'm not sure if someone with 3 years' experience today can accurately judge a conversation talking about ten years ago.

Re: “Clean” code, horrible performance

#407

Post by ajmurmann »

FridgeSeal wrote: post #270
ajmurmann wrote: post #190

Earlier quoted context omitted.

Don't forget the 90% of the processing time that it's waiting for a DB response

I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.

Just work with some folks who don't know basic query optimization

Re: “Clean” code, horrible performance

#408

Post by tonymet »

I worked at a company where the client devs had a gaming background and the server devs had a web background.

The gaming devs were obsessed with framerates and efficiency while server devs wanted to decouple modularize everything.

There's no solutions only tradeoffs

Re: “Clean” code, horrible performance

#409

Post by TeMPOraL »

flavius29663 wrote: post #240

One of the the points of "clean code" is to make it easy to find the hotspots and optimize those. Write the codebase at a very high level, plenty of abstractions etc. and then optimize the 1% that really needs it. Optimizing a small piece of software is not going again clean code, on the contrary, it re-enforces it: you can spend the time to optimize only what is necessary.

One of the main points of Casey's videos is that following the "clean code" mantras will make your code unoptimizable. You may delay performance considerations until the end, then fire your profiler, find that 1% that really needs it[0], ... and realize that you can't get more than 1.5x - 2x speedup without ripping out the core 10% of the codebase and rethinking it properly. Were you, however, to consider performance from the start, that 10% would've been designed around completely different abstractions, and already 10x faster in the unoptimized version.

"Clean Code" should be called pessimistic coding - a big part of it is to enable OK flexibility in any imaginable direction. But real-life code will not change in all possible direction - in fact, you can predict quite well roughly what can and cannot change. Writing for performance means, among other things, making things easier both for human and the CPU by reducing flexibility in the unlikely directions.

In the toy example from the video: Casey's proposed alternatives baked in the assumption that the program is working with shapes which, for a given computation, all can fit a specific family of equations. Clean code will make it just as easy to add a square as to add a parametric spline surface. Casey's code will make the former trivial, the latter hard without redoing the entire shape-related code. It's a good tradeoff if you're making a program that mostly works with non-parametric simple polygons, because nobody will need parametric splines in it. On the off chance they will, they can pay for the extra effort - and in the meantime, your software is 20x faster than the equivalent "clean code" version.

--

[0] - This thinking alone is a problem. It's not the 1% that needs some optimization work. The entire user-interacting surface and everything downstream of it need it, which means effectively the entire program. You're free to set a cut-off point beyond which you don't care about "less important" features - but 1% seems quite too early.

Re: “Clean” code, horrible performance

#410

Post by krapp »

andai wrote: post #169
krapp wrote: post #92

Earlier quoted context omitted.

If you're talking about Handmade Hero, the real answer to programmer happiness is not using a language you despise and refusing to leverage the features of, not refusing to use libraries in that language or frameworks, not re-implementing everything from first principles, and to actually have your game designed first (not designing while you code.)

Doing things without libraries (except the stuff built into Windows XP?) is the whole point of the project.

The problem is people get hooked into Casey's misanthropic philosophies and take his rants as gospel, and wind up believing Handmade Hero represents the way game development should be done, that libraries and frameworks can't be trusted, that C++ shouldn't be used at all, and you should implement as much from scratch as possible, when none of that is true.
Post reply on HN