Hacker Newsnew | comments | show | ask | jobs | submitlogin
Programming as if Performance Mattered (2004) (dadgum.com)
30 points by RiderOfGiraffes 1465 days ago | 19 comments



There is something I find interesting about online discussions around performance issues (I am looking at you SO). The moment the question is asked, people try to gang up and out-compete each other in providing the cookie-cutter, patronizing, zero-information responses. Along the lines of (i) check whether it is actually the bottleneck, (ii) use a better algorithm, (iii) dont do it etc etc. Usually accompanied by (mis-attributed) quotes. Such advice would typically be the highest voted.

What galls me is that they assume, without any basis, that the person has not (a) benchmarked the code, (b) is obviously running an inferior algorithm and (c) just because they have not worked on an applications were speed mattered, the poster could not possibly be working on something where speed matters. If I were the one who asked the question I would be mighty pissed, given that just reading such comments as a third party irritates me enough.

The advice about premature optimization is valid. But it is a well assimilated folklore by now and I dont see how repeating that adds value. I think Hoare and Knuth's message was intended for a specific audience and the majority of the online crowd is not that audience.This message is often interpreted by enlightened newbies as an encouragement to be sloppy.

People would be better served if the discussion shifted to a different landscape, where people pointed out that particular construct that was typically more efficient among constructs of comparable clarity. Pointed out possible bottlenecks ahead of time, so that it is on the developers mind and he/she does not have to go through the process of coding a poor solution and discovering that it sucks.

Also regardless of the fact whether the code construct is actually a bottleneck in the application or not, it is always good to know what the more efficient alternatives are. It might not be the bottleneck in the current application, but it might well be in some other. Besides, there is something called intellectual curiosity.

-----


I would complement this by noting that some people online, particularly at SO, cannot ask questions properly. Optimization problems are often about context, but context is seldom properly presented, if presented at all.

One can always ask for more information, so this is no excuse, of course. Perhaps the patronizing answers are the stupid mode of requesting clarifications.

-----


The worst part is you can't tell them to fuck off because that would just be 'ungrateful.' They're only being patronising for your own good!

-----


Well, on SO you can always downvote the answer. It would be more effective if it were the community norm to downvote the condescending answers, of course. It's not the case, unfortunately.

-----


Condescending, presumptive no-info answers are often the top voted in my experience.

-----


Well of course. If you say nothing, you can hardly be wrong :D

-----


Performance surely doensnt matter in the main stream - my grandma's computer has comparable processing power to supercomputers 20 years ago( and she has a Pentium 4, that has been obsoleted many times over already) [1]. But I think google would pay attention to software performance on their Terabyte-eating map-reduce clusters. Or someone who doesn't want their iphone app flagged as "battery hog" for that matter.

"Pay attention", not as in squeeze out every extra cpu cycle they can, but as in do the 10 % extra thinking that would get the reasonable 2-10 fold improvement over the naive implementation. At least that's my experience - maybe i'm just really bad with my naive implementations, YMMV.

[1]http://en.wikipedia.org/wiki/Orders_of_magnitude_%28computin...

-----


Ever wonder why your laptop fan turns on and you lose a half hour of battery life when you load up a tiny, blocky online video? It can't be because the video decoder is written in a language like Actionscript because everyone says performance doesn't matter...

-----


Flash's video decoders are written in native code and pretty heavily assembly-optimized. They're not as fast as they could be, but they're nothing compared to something truly slow (e.g. reference decoders).

The high CPU usage is typically because of two things:

1) Flash has to do extra compositing to add ads and such onto video.

2) Flash typically doesn't use hardware acceleration for the actual blitting -- their excuse is that on a significant % of computers, bad drivers will result in crashes, and they'd rather be somewhat slow on 100% of computers than crash 1% of them.

If you want something to complain about, go after the sites using Cortado to decode video. Yet even that is still JIT'd, though completely lacking SIMD asm due to being Java.

Disclaimer: I am not a developer of Flash, I just know one.

-----


Thanks for the info -- but my point stands, performance is important when you care about energy usage (mobile, laptop, server).

Really the only place its not important is GUI programming and high-level application logic.

-----


Even GUI programmers need to be aware of performance. Painting can be expensive, especially on mobile devices, and event handling must be swift or else the app will feel unresponsive.

-----


That or your laptop is sitting on a fluffy mattress and is having a hard time dissipating heat.

Just kidding, of course. If you're pointing at the poor performance of Flash Video on a Mac, I think the video decoder is written in C or C++, it was just... not really optimized: http://blogs.adobe.com/conversations/2010/02/open_access_to_...

-----


I find it rather queer that, for the author, two data points are enough to "put performance into proper perspective". Now that performance is gained from scaling, it matters like never before.

-----


Well, you have to see this article from a pre-2004 perspective. Back then, clock speeds were still increasing like crazy, like it'd never stop. This luxury made people think things like "performance doesn't matter, processors will get faster than we can optimize the code". The mindset that eventually led to Vista.

We're wiser now. These days, performance can only be increased by adding more cores, not by clocking up. Scaling up actually costs development effort. This makes optimization very important.

See also this 2005 article from Dr Dobbs: http://www.gotw.ca/publications/concurrency-ddj.htm . That's when the big change of perspective began.

-----


You are right. I kept that in mind all along while reading the post, though I perhaps showed less sympathy in my remark. I really regret if I sounded like a smart-arse.

The link you posted is great; the chart alone speaks volumes! Already at that point in time one could notice how the trend with power and CPU frequency was changing, while transistor count kept on growing. James Hague would have had second thoughts, I believe, if he had seen that chart. Moore's Law suffered quite a plot twist the last decade.

(Curiously, Herb Sutter is the secretary of the C++ standards committee. They finally finished the standardization of basic threading — among other stuff — 5 years after the Dr. Dobbs article!)

-----


Nah, I had the same reaction while reading the article. Then I realized that it was from 2004.

The slow push for standardization is indeed curious. Standardizing threading would only be the beginning, as threading is (for most things) a much too low-level abstraction. It is very hard to scale threading, with the locking and other synchronization it usually entails, to large number of cores (soon, >16 won't be that strange). And it's very bug-prone.

I think it's disappointing that more high-level primitives such as co-routines, work queues, task-based parallelism, map/reduce and such are finding such slow adaption in mainstream languages. You'd say that making the writing of parallelized code faster and more robust is an important goal.

-----


At the same time I would point out that the author has probably made the right choice learning and using Erlang. He _might_ be in a better position to take advantage of multiple cores, in some cases by just adding more cores to his system.

-----


This could explain the supposed disregard for the new trend. Concurrency was just not an issue for him.

-----


I with the comparison with an efficient compiler was made. Not much to conclude from the data given.

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: