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

391–400 of 932 posts

Re: “Clean” code, horrible performance

#391

Post by saagarjha »

heisenbit wrote: post #281
simplotek wrote: post #250

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software o…

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

In any organization it generally pays off to have most people have a basic knowledge of a subject and then hire domain experts to drive most of the impact. For security, for example, this typically manifests as having very general "best practices" for most developers to follow and then a small team that handles anything that requires advanced understanding of the area.

How this typically works with performance is very similar, with a small team working to identify problematic areas where optimization would drive the highest impact, and the rest of the organization keeping performance in mind but not otherwise concerned with it in their day-to-day work.

Re: “Clean” code, horrible performance

#392

Post by badsectoracula »

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…

> instead of loading the address and jumping to it push the address then return to it

I remember doing that in a code generator ages ago because it was easier than calculating the jump offset :-P

Re: “Clean” code, horrible performance

#393

Post by loup-vaillant »

Octokiddie wrote: post #375

> So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape, impling that code following that rule number is 1.5x slower than code that doesn’t. To put that in in hardware terms, it would be like taking an iPhone 14 Pro Max and reducing it to an iPhone 11 Pro Max. It's three or four years of hardware evolution erased becaus…

> The benchmark is a tight loop where the vtable lookup is a big chunk of the total computation. I don't think one can extrapolate this 1.5x improvement to real code.

No you can't. But other things get worse at a bigger scale. Not all programs make those virtual calls absolutely everywhere so the overhead scales with the program, but many don't pay attention to memory access pattern, and cause their instruction pointer to jump all over the place and trash their instruction cache. Mike Acton have once shown that merely reordering objects by types, while keeping those virtual calls, can help the instruction cache quite a bit just by making sure the same code was called several times in a raw.

Re: “Clean” code, horrible performance

#394

Post by anitil »

yashap wrote: post #263
mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

How did you get in to that work? I love this sort of optimization but not sure how to get people to pay me to do it full time.

Re: “Clean” code, horrible performance

#395

Post by int_19h »

zelos wrote: post #40
vore wrote: post #19

Earlier quoted context omitted.

The shapes example is pretty contrived so I don't really have an opinion on it either way. But imagine you have something like a File interface and you have implementations of it e.g. DiskFile, NetworkFile, etc., and you anticipate other implementors. Why would you do anything other than have a polymorphic interface?

That does depend on how the abstraction is defined, of course. I once worked on optimising a 2D Canvas C++ class which had a nice top level virtual interface so you could replace it with a different implementation. It was also crazily slow because it defined: virtual void setPixel(int x, int y, int color) = 0; and then implemented flood fill etc in terms of that.

This isn't necessarily bad if all the other operations are also virtual. The idea is that you can quickly get something working (e.g. when porting) just by implementing setPixel(), and then gradually fill in other primitives with properly hardware-optimized versions. And you do need a virtual setPixel() in any case because some API client might need that one call.

Re: “Clean” code, horrible performance

#396

Post by saagarjha »

TeMPOraL wrote: post #348
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

Except when it isn't. I remember an article making rounds the other day, that claimed the whole "most software spend most time waiting on I/O" common wisdom is no longer true, as most software these days is CPU-bound, and a good chunk of that is parsing JSON.

For pure compute most software is memory bandwidth bound and for large applications I/O is generally still a problem given the costs of flash.

Re: “Clean” code, horrible performance

#397

Post by joaonmatos »

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.

Are you even manually implementing sorts frequently?

Even languages that are notorious for having tiny libraries, like C and JS, have built-in sorts.

Re: “Clean” code, horrible performance

#398

Post by timeon »

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…

> a virtual method is called only a few hundred times

The particular example with shapes could be CAD or BIM app where it is usually more then "few hundred times".

Re: “Clean” code, horrible performance

#399

Post by ZephyrBlu »

Cthulhu_ wrote: post #220
mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with. I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop wit…

> That is, performance bottlenecks are easier to find and fix if your code is clean to begin with

That is not at all what "make it work, make it pretty, make it fast" is about. That saying is about prioritization. Making it fast doesn't mean anything if it doesn't work.

However, if you are doing performance-sensitive work then this is a very bad strategy. You need to design a performant architecture up front otherwise you'll likely have orders of magnitude worse performance, even after optimizing your code.

Ex: if your "make it work" design has shared mutable state, you're going to have a bad time when you want to scale that horizontally and unlock 100x better throughput/performance.

Re: “Clean” code, horrible performance

#400

Post by GrumpySloth »

Aeolun wrote: post #351
jiggawatts wrote: post #322

Earlier quoted context omitted.

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code . It's easier to write, easier to read, and runs faster too! If there's something wrong with that advice, I can't imagine what it is...

> If there's something wrong with that advice, I can't imagine what it is... It will start getting really annoying when you try to add shape ‘hexagon’ and need to figure out all the places where a shape can potentially be used, just so you can update the switch statements.

Even in C compiler will emit warnings for unhandled cases in switch statements as long as you don’t provide a default case (as you shouldn’t).
Post reply on HN