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

Performance optimization is hard because it's fundamentally a brute-force task

purplesyringa.moe

Post reply on HN
Print view View original

111–120 of 153 posts

Re: Performance optimization is hard because it's fundamentally a brute-force task

#111

Post by YZF »

cogman10 wrote: post #97
dmurray wrote: post #29

Earlier quoted context omitted.

> it won't show up in profiles except for ones that capture stacks I don't think I've ever used a profiler that couldn't report you were in F() here. One that only captures your innermost functions really doesn't seem that useful, for exactly the reasons you give.

The default usage of perf does this. There's also a few profilers I know of that will show the functions taking the most time. IMO, those are (generally) nowhere near as useful as a flame/icicle graph. Not saying they are never useful; Sometimes people do really dumb things in 1 function. However, the actual performance bottleneck often lives at least a few levels up the stack.

Which is why the defaults for perf always drive me crazy. You want to see the entire call tree with the cumulative and exclusive time spent in all the functions.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#112

Post by YZF »

cogman10 wrote: post #98
mystified5016 wrote: post #38

Earlier quoted context omitted.

Do you want to claim you've never written quick and ugly code to get something working to come back and fix it up later? Pretty much everyone I know will throw down an O(n^2) algorithm or whatever in their first pass and replace it with something more thought out once they have the time to think deeply about it. If you're fretting about optimization at every stage of development, you're really doing it wrong. This is…

> Pretty much everyone I know will throw down an O(n^2) algorithm or whatever in their first pass and replace it with something more thought out once they have the time to think deeply about it. Most of the times I've seen this, the faster algorithm is literally just a dictionary with a well-defined key. I honestly do not understand why that's not the first solution most devs think of and why n^2 seems to dominate. A…

For many people performance optimization really starts with your second version. I'm not even sure what this is supposed to do exactly but the O(N^2) is just bad/sloppy code. Optimization is usually more about getting the right algorithms to execute faster. At least that's how I think about it.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#113

Post by YZF »

jmward01 wrote: post #22

I have almost always found that simple code runs faster than complex code. I think this is because optimization is likely an NP problem and like all NP problems, the best algorithm we have for solving it is divide and conquer. The core thing about D&C is that you divide until you reach a level that you can actually find the optimum answer within the resources given but accept that by dividing the problem you will lik…

If you look at some SIMD accelerated algorithms they're anything but simple. They involve clever ways of breaking up the work into streams and clever ways of computing those streams including conditionals without breaking the data flow.

They are very much not the simplest possible implementation of the algorithm and they run an order of magnitude faster for some algorithms.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#114

Post by Ygg2 »

> Any developer can see that the following two snippets are (supposed to be) equivalent

Being how I fall under any developer, I'm going to bite the bullet and ask:

How are they supposed to be equivalent? One is a HashSet, other is boolean? And what is `c`.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#115

Post by singhrac »

tikotus wrote: post #34

I once had this kind of body recovery/stress level measuring thingy on me for a few days, and a doctor would then analyze my health and such. I was under some stress those days and (according to the measurements) I wasn't recovering properly even during the nights. But then there was this one, long, flat, deep green curve in the middle of my work day. I checked from my VCS what I was doing during that period: I was o…

There’s nothing quite like writing the final squashed commit message and saying “results should be bit-level identical, +25% speedup on average” or the equivalent. Even better if it’s a hot path that matters to the bottom line of the company.

I try to keep a few of these tasks lying around marked “unblocked” in case I need to unwind. It keeps me from doing it right after noticing, which is an extra bonus.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#116

Post by devnull3 »

tikotus wrote: post #34

I once had this kind of body recovery/stress level measuring thingy on me for a few days, and a doctor would then analyze my health and such. I was under some stress those days and (according to the measurements) I wasn't recovering properly even during the nights. But then there was this one, long, flat, deep green curve in the middle of my work day. I checked from my VCS what I was doing during that period: I was o…

I think optimization triggers fundamental instincts in humans:

1. Tracking i.e. navigating through jungles for hunting or find where the bottleneck is.

2. The thrill of the hunt. The joy after finding the hotspot or the bottleneck. It makes your day.

3. The actual hunt i.e. shooting an arrow/spear or using clever way of fixing.

4. Brag about the hunt or writing a blog post or tech talk on how difficult and awesome the hunt was.

Also optimizing a critical path has multiple takers in the org:

1. Product Managers are happy due to improved user experience.

2. Management is happy as in some cases it actually saves a lot of money.

3. Your boss is happy because he/she gets to score points as "team achievement" when evaluation is around the corner.

4. Engineers get to do nerdy things which otherwise would not find traction in the org.

All in all its a win-win-win-* situation.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#117

Post by saagarjha »

YZF wrote: post #111
cogman10 wrote: post #97

Earlier quoted context omitted.

The default usage of perf does this. There's also a few profilers I know of that will show the functions taking the most time. IMO, those are (generally) nowhere near as useful as a flame/icicle graph. Not saying they are never useful; Sometimes people do really dumb things in 1 function. However, the actual performance bottleneck often lives at least a few levels up the stack.

Which is why the defaults for perf always drive me crazy. You want to see the entire call tree with the cumulative and exclusive time spent in all the functions.

I’m honestly curious why the defaults are the way they are. I have basically never found them to be what I want. Surely the perf people aren’t doing something completely different than I am?

Re: Performance optimization is hard because it's fundamentally a brute-force task

#118

Post by saagarjha »

pavelstoev wrote: post #107

Optimizing AI performance is like peeling an onion — every time you remove one bottleneck, another layer appears underneath. What looks like a compute problem turns out to be a memory bottleneck, which then turns out to be a scheduling issue, which reveals a parallelism mismatch… and so on. It’s a process of continuous uncovering, and unless you have visibility across the whole stack — from kernel to cluster — you’ll…

They’re not very good, unfortunately.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#119

Post by saagarjha »

Misdicorl wrote: post #33

I'll throw my hat in the ring for "disagree". Few kinds of work have such clear and unambiguous results as optimization work (its now X% faster!). Few kinds of work have such incredible and detailed tools to guide your hand in finding where to invest your effort (look at this hot loop!). The fact that sometimes optimization work is tricky or requires some pre-thinking, or is even gasp counter-intuitive is such a hila…

Performance optimizations are usually tradeoffs. Which ones you make affect the outcome.

Re: Performance optimization is hard because it's fundamentally a brute-force task

#120

Post by saagarjha »

Ygg2 wrote: post #114

> Any developer can see that the following two snippets are (supposed to be) equivalent Being how I fall under any developer, I'm going to bite the bullet and ask: How are they supposed to be equivalent? One is a HashSet, other is boolean? And what is `c`.

c is an arbitrary object. The first puts two numbers and checks if c is present, which is only true if c is equal to one of the two numbers.
Post reply on HN