5 ms·
This is not that uncommon when optimizing code. Your program is slow so you profile it, and find out that f() takes 99% of the time. So you work a lot to optim
by ot 11y ago
This is not that uncommon when optimizing code.
Your program is slow so you profile it, and find out that f() takes 99% of the time. So you work a lot to optimize f(), and re-profiling shows that now f() takes 98% of the time.
Doesn't seem that impressive after all the work you've put into optimizing f(), but your program is actually twice as fast :)
- deleted 11y ago[deleted]
- nightcracker 11y agoLet's say your program takes 100 seconds, of which 99% is spent in f(). Then if you optimize f() such that only 98% of the total time spent in f, then: orig_time = 100 orig_not_f = 0.01 * orig_time = 1 new_f = 0.98 * new_total new_total = new_f + orig_not_f new_total = 0.98 * new_total + orig_not_f new_total - 0.98 * new_total = orig_not_f 0.02 * new_total = 1 new_total = 1 / 0.02 = 50
- logicallee 11y agobeautiful
- em3rgent0rdr 11y agoIf you understand Amdahl's law, it's not suprising at all!
- trsohmers 11y agoBut Gustafson's law has a lot more meaning. Who cares if it takes some fixed time to do something if you can parallelize and get 2x, 4x, 8x, 1000x, etc. as much done in the same time?
- jakobegger 11y agoThis is an interesting observation, and confirms the way I optimise code: 1) Create a benchmark (some code that performs the task that I want to optimise), and measure the absolute time it needs. 2) Use a profiler to see where most of the time is spent. Optimise that code. 3) Run benchmark to see if your optimisation are effective. Or, in other words: the percentage tells you where to focus your effort. The absolute time tells you how successful your optimisation is.
- ot 11y agoThis is the obvious strategy, but it's not always applicable. For example when profiling a long-running service, or a kernel, there's no "absolute time it needs", you need other proxies of running time such as the CPU usage percentage, but even that is not noise-free. So if you just run "perf" on it, you need to be aware of this fallacy.
- blueblob 11y agoI am pretty much a novice in program optimization, but doesn't `perf` sample clock cycles? So in effect CPU usage percentage doesn't matter as much since it's not using wall clock time?
- wobbleblob 11y agoWithout knowing your code, I can think of a performance hack to get the running time of f() down to less than 10% of the time.
- JupiterMoon 11y agoWhat is this?
- andrelaszlo 11y agoSlowing down the rest of the program? :)
- wobbleblob 11y agoWell yeah, just add a wait loop somewhere else
- eCa 11y agoI thought they were speed-up loops... http://thedailywtf.com/articles/The-Speedup-Loop http://thedailywtf.com/articles/The-Speedup-Loop
- h_o 11y agoThat is pure genius. Some very forward thinking there.
- ryangittins 11y agoHah, this is great! It reminds me of the classic static char buffer[1024*1024*2]; story from a few years back. http://www.dodgycoder.net/2012/02/coding-tricks-of-game-developers.html http://www.dodgycoder.net/2012/02/coding-tricks-of-game-deve...
- stcredzero 11y agoFrom CToGD: In other words, when a project gets handed down from above to launch in, say, 3 months, there's no way in hell you can get the servers requisitioned, approved, and installed in that time. It became standard practice for each team to slightly over-request server capacity with each project and throwing the excess hosts into a rainy day pool, immediately available and repurposeable as required. I know of a Social Security Administration acquisition back in the days of 100 MHz processors. The bureaucracy took so long with this, by the time the order could be put out to suppliers, 100 MHz processors were no longer available, so SSA ended up with a bunch of workstations that were 166 MHz processors down-clocked to 100 MHz. (Otherwise, they would have had to start the whole process over again.)
- amelius 11y agoThis just shows that the percentage of total time a function takes is really not the thing you should be looking at when optimizing code and you want to know how much faster your code really is. For example, say your function f() takes 100% of the time. You then make it twice as fast. You look at the percentage, and, surprise, it still is taking 100% of the time!
- netcan 11y agoNaturally, if you can look at a program which is now twice as fast and be unimpressed you are looking at the wrong metric. It's understandable though in the context of the sequence of actions you might be going through as a tinkerer (as opposed to a scientist). You start with a list of functions and the % of time they take. Improving the top one will have the biggest effect, so this is a good thing to look at when deciding what to to. Then you go back to the same list afterwards. I can see this (and lots of variations of this) happening
- calinet6 11y ago> Naturally, if you can look at a program which is now twice as fast and be unimpressed you are looking at the wrong metric. Or, a computer scientist would say, the right one. The actual speed doesn't matter as much as the complexity. In reality, it does, in the end; but it's also important to consider the type of optimization you're doing, and not just stop at being impressed with twice as fast. For example, a primitively optimized function that's twice as fast for input size 100 would still be twice as fast for input size 100,000, but a function optimized to be an order less complex could be twice as fast for size 100, and a thousand or so times as fast for size 100,000. The latter optimization would be significantly better, objectively, and thus, it would make a lot of sense to look at the first program and be unimpressed with a mere linear doubling in speed.
- vixsomnis 11y agoIt's like grocery shopping and coupons, however. If you shouldn't be calling the function, then even a 99% reduction is not useful in that context. Would you rather call a slow function, a fast function, or skip it altogether? (A coupon only saves you money if you would buy the item in the first place.)