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] |
