|
Re^6: CPU cycles DO NOT MATTER!
by Joost (Canon) on Apr 19, 2008 at 22:33 UTC
|
It's the blanket statement I object to most.
Yes the title is a bit confrontational. And wrong :-) But I assume that was deliberate.
The gist of it is right, though: people spend way too much time optimizing stuff for hours that doesn't make even a minute of difference a year.
Followed by the idea that the short term hardware fix is economic in the long term.
That depends. But the OP might consider that once hardware is bought, it's not generally upgraded every year and a half to take advantage of Moor's law (even if that would be economical by itself), and that many servers these days are placed in rented spaces, which means you pay for the size of your server farm and its power consumption each month, not just once.
| [reply] |
|
|
| [reply] |
|
|
Seems reasonably fair. But to compare:
On this (hypothetical - but close enough to the truth) project we've got about $100,000 in hardware and about $20,000 a year in hosting. This is one fairly large rack of machines. Assuming we'd have to double the amount of raw CPU power, that would probably go add at least another $40,000 hardware and something like $10,000 - $20,000 / year in hosting costs depending on how large the racks are. One man/month
would cost roughly $15,000, probably a bit less. You can see there's some room here. :-)
| [reply] |
Re^6: CPU cycles DO NOT MATTER!
by dragonchild (Archbishop) on Apr 19, 2008 at 22:29 UTC
|
The blanket statement was meant to start a conversation, hopefully amongst many monks. To that end, my OP has been, by and large, successful. I also hope it has gotten some people to reconsider their priorities from a purely coding perspective to taking the larger picture of the business into account.
And, hopefully, to realize that optimizing for CPU cycles in a language running in a 10-year old VM is rather silly.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
And, hopefully, to realize that optimizing for CPU cycles in a language running in a 10-year old VM is rather silly.
And yet, every time someone comes around asking how do I search my array for a given value, the standard answer is "use a hash". I'm pretty sure that we could dig up a post of yours offering the same advice. Of course, we could also suggest grep, but mostly we don't unless duplicate values must be maintained, because the hash solution is quicker. It can lead to duplication of memory usage, and some additional complexity, but for most purposes, it's a more optimal solution.
And then there's the case of the small business running a web site on a rented server. For 95% of what he needs, his current installation works perfectly, but there's that one dratted cgi that just takes too darn long and he's getting complaints. Options:
- Rent a better server.
Means making a wholesale move to a different hoster because he's already using their most powerful offering.
Maybe moving to a dedicated server rather than a virtually hosted one.
Either involves costs that go beyond just the costs of better hardware.
- Or spreading his load across 2 machines.
But that doesn't work because the slow part of the process is cpu bound, and the second machine is the same spec as the first. Splitting the slow process across two machines means huge complication and expense for clustering software.
Not to mention the requirement to purchase expertise he doesn't have.
Not to mention that doubling his hardware costs would cut directly into his profit margins.
- Profile the errant code and see what he can do to speed it up.
Or the case of the hobbyists, college kids, and guys developing programs for friends, or aimed at the home market.
Requiring C/C++ compilers, and the skills to use them, isn't an option.
Requiring a $4000 high end server to run their programs isn't an option either.
If it doesn't run effectively on a reasonably configured typical home system, it won't be usable.
The corporate world is not the only world. And far from all the people that come to PM seeking solutions to their problems live in that world. In fact, I would suggest that those that have the option of throwing hardware at performance issues are probably in the minority.
So the next time you see someone seeking to eek out the performance of the hardware they have, by improving the performance of the software they write in that language they know. The language that specifically sets out to not being the exclusive preserve of professional programmers. By all means sit back and feel smug that you have that option, and by all means feel free to move quickly on to posts dealing with more professional matters.
But please, don't berate them for not having the option, or for seeking to spend their time, optimising their code, to make best possible use of the hardware that they have.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
...optimizing for CPU cycles in a language running in a 10-year old VM is rather silly.
Depends on how you're optimizing, of course. It looks to me like you're mainly railing against all those useless micro-optimizations (like using map EXP, vs MAP { EXP }).
But just choosing a sane algorithm for the job can easily reduce the time to run by many orders of magnitude, even if the algorithm is purely CPU bound. In that case, and if the dataset is large enough, CPU cycles obviously DO matter.
IOW "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
| [reply] |
|
|
And, that is the kind of understanding I was hoping people would come to. I know you know it. Hopefully, some junior will come by in a few years, run across this thread, and learn.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |