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

851–860 of 932 posts

Re: “Clean” code, horrible performance

#851

Post by sakras »

xupybd wrote: post #460
alfalfasprout wrote: post #446

Earlier quoted context omitted.

The problem is I think you're also disagreeing with yourself in a way. > That is not our job! Our job is to solve business problems within the constraints we are given. No one cares how well it runs on the hardware we're given. They care if it solves the business problem. Look at Bitcoin, it burns hardware time as a proof of work. That solves a business problem. Cost is a business problem. It is a constraint. The pro…

> Cost is a business problem. It is a constraint I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it. What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending mon…

> To me the article read as if our job was to make every bit of code as fast as possible.

My interpretation was that he thinks the baseline for performance is too low. There are kind of two parts to performance: non-pessimization and optimization. He’s mostly harping on the former point, that you don’t have to go tuning anything. Just by writing code without following the clean code rules you can get a huge speed up for free, without any tuning at all. It’ll be free of obvious overheads, even if it doesn’t do anything special to fully utilize the hardware.

Re: “Clean” code, horrible performance

#852

Post by Taniwha »

badsectoracula wrote: post #392
Taniwha wrote: post #333

Earlier quoted context omitted.

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

every subroutine return after that would be miss-predicted

Re: “Clean” code, horrible performance

#853

Post by themulticaster »

rerdavies wrote: post #561
heisenbit wrote: post #281

Earlier quoted context omitted.

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

Profiling. If you're not profiling, you're completely wasting your time. The 1% is almost never where you think it is. And when you do identify the 1%, you need to be testing optimizations with a profiler constantly while optimizing. Profile. Do some optimization. Profile again. Roll back if not successful. Repeat until done. It's impossible to optimize well if you're not doing profiling. The ultimate tools would be…

I'm not familiar with how it compares to ARM/Intel's profiling tools, but I found the Linux perf suite to be very capable (though limited to Linux obviously). And Hotspot [1] allows effortless profile visualization using flame graphs, including some very interesting features such as off-CPU time profiling [2]. "perf record" coupled with Hotspot forms a very smooth edit-compile-profile cycle.

[1] https://github.com/KDAB/hotspot

[2] https://github.com/KDAB/hotspot#off-cpu-profiling

Re: “Clean” code, horrible performance

#855

Post by cranium »

_dain_ wrote: post #799
cranium wrote: post #667

You can optimize even further by creating a custom chip to compute the area of shapes in the order of billions per second. But what's the point? Where is the value? Can't say it better than Knuth: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Clean code has never been about performa…

A 20x performance improvement is not a "small" efficiency.

A 10000x performance gain could still be insignificant, see Amdahl's law.

That's why you need to understand bottlenecks in your system before going around and start optimizing things, as it could be pointless or even counter productive.

Re: “Clean” code, horrible performance

#856

Post by adamrezich »

muricula wrote: post #186
Tomis02 wrote: post #130

Earlier quoted context omitted.

Correct me if I'm wrong. Even if the compiler devirtualizes the classes, you still have the memory cost of storing the vtable pointer in each of the object instances (8 bytes for each instance), which means you need to do more fetches from memory. Does CPU prefetching negate the cost of these additional memory lookups?

The enum to tell what shape an object is costs something, probably 4 bytes. Storing the 8 byte vtable constant isn't so bad considering.

looking at a value is faster than dereferencing a pointer—why is this controversial?

Re: “Clean” code, horrible performance

#857

Post by nijave »

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…

In a business context, it usually happens that hardware is cheaper than software (licensing) which is cheaper than engineering labor. Tack on the opportunity cost of delaying business advances/features and it's usually cheaper to just throw hardware at it.

There's a tipping point where you have so much hardware there's big savings with optimization. Things like Postgres and the Linux kernel have a lot of optimization put into them and there's an insane amount of hardware out running that code.

That said, slow software sucks.

Re: “Clean” code, horrible performance

#858

Post by adamrezich »

axilmar wrote: post #386

In C++, you can have clean code and performance, by utilizing templates. In the example given, all polymorphism can be removed, and the shapes can be stored in std::tuple structure. And then the operations would be faster than C, since no switch statement would be needed.

then your compile times balloon even larger than they already are in C++

Re: “Clean” code, horrible performance

#859

Post by cranium »

gnuvince wrote: post #761
cranium wrote: post #667

You can optimize even further by creating a custom chip to compute the area of shapes in the order of billions per second. But what's the point? Where is the value? Can't say it better than Knuth: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Clean code has never been about performa…

Another quote from Knuth, from that same paper: > The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise-and-pound-foolish programmers, who…

Good point, and also why the topic of performance is so prone to heated discussions. To paraphrase Knuth "97% of the time, don't optimize except if it's an easy 12% improvement". I don't think there exists a good heuristic that works each time or for all languages. The right decision is left (pun intended) to the programmer that has to live with it. For me the ideal decision took into account the performance tradeoffs of each level of abstraction and chose the "appropriate" one. Obviously, the "appropriate one" depends on an uncountable number of variables including future scaling issues, probability of refactoring/irrelevance, cost/reward of spending the time to optimize the function, ...

Re: “Clean” code, horrible performance

#860

Post by jbverschoor »

mxmbrb wrote: post #788
jbverschoor wrote: post #444

Earlier quoted context omitted.

Yep.. I much prefer 2000 lines of code in one function with very little calls. Easier to reason about, less bugs, easier to maintain. It's very easy to indicate when a new part is coming, just enter a big comment block of what you're doing.

This is the perfect example. You start out like that and all is fine, but two years, a few changes and some bugfixes later your now 2700 line method is a total zombie. The comments blocks are lying and you have incromprehensible dependencies. More over you have to read it all every time you make a change in the method, its inputs or understanding its output. That just screams 'refactor me!'. The exceptions of course…

Still better than nested classes and 50 different places where the code is. There are plenty of places where it makes more sense. Also in 'normal' code. It's about readability and maintainability. Classes mean -> extensibility, and is by definition more complex. Factoring out some functions make sense yes, but not the general mantra "if it's 5 lined it should be a function".

As Uncle Bob says (paraphrasing): Dependency injection (java) is just programming XML where you turned compiler errors into runtime errors

Post reply on HN