Recently in Matching First Character of Strings Efficiently there was a controversy about the utility of optimizing some bit of code for speed.
On one hand, playing with code optimization is fun and others' code can display enlightening and potentially useful techniques.
On the other hand, Knuth, among others, claim that "premature optimization is the root of all evil", for a few reasons:
- You can easily waste more time and money optimizing code than you will save in running it
- Optimized code often has a funky, fragile structure that is hard to modify or generalize down the line.
- Optimized code is often hard to read, and/or things are done in inexplicible ways.
Because of these problems, we should not encourage novices by indulging in such 'evil' speed optimization challenges.
How can we reconcile these two points of view?
Well, perl golf has a lot of the same issues that speed optimization does. The nice thing about calling some attempt at keystroke optimization 'golf' is that it at once gives a sporting flavor to the challenge, and reminds others that it is only a game, not a production technique.
I propose that we prepend speed optimization games with something like 'sprint', so that we can have fun without the regret of leading others down the path of darkness.
|
Re: Golfing and Sprinting
by Abigail-II (Bishop) on Mar 16, 2004 at 00:59 UTC
|
On the other hand, Knuth, among others, claim that "premature optimization is the root of all evil", for a few reasons:
- You can easily waste more time and money optimizing code than you will save in running it
- Optimized code often has a funky, fragile structure that is hard to modify or generalize down the line.
- Optimized code is often hard to read, and/or things are done in inexplicible ways.
Yes, good points, although I'd change the 'often' of the second and third points to 'sometimes' - assuming we talk about Perl here, and not C or assembler. Note however that these points all deal
with full programs, probably running in production, and
created while being paid.
Because of these problems, we should not encourage novices by indulging in such 'evil' speed optimization challenges.
That's a conclusion I don't want to draw. Typically the
challenges presented here and in other forums are about a
small piece of code, that's isolated from their context.
I think that playing around with a small piece of code,
trying out alternatives, consider what they do, without
the burden of context is an excellent way to understand a language better.
Abigail
| [reply] |
|
|
It's always nice to bust out a Larry quote:
Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.
--Larry Wall
| [reply] |
|
|
Bravo!
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
| [reply]
[d/l] |
Re: Golfing and Sprinting
by bmann (Priest) on Mar 16, 2004 at 00:21 UTC
|
"premature optimization is the root of all evil"
The key is premature optimization. You can easily spend lots of time and money optimizing code that has no bearing whatsoever on the actual performance of your program! For example, i/o might take 2 minutes, and sorting the data takes 1 millisecond. Who cares if a different sorting algorithm will cut the sort time in half - optimize the i/o and forget about the sort. Profile your program, then optimize the bottlenecks.
That being said, pointless optimization of a problem to see who comes up with the fastest algorithm, that sounds like fun and a great way to learn a little more about the language!
| [reply] |
|
|
Another key is 'micro-' (or 'nano-', which I started using because some tiny optimizations in Perl made what I was used to calling 'micro-optimization' seem huge in comparison because Perl can have much bigger overhead than something like C).
I wouldn't much mind many discussions of optimization that are premature if they covered real optimization techniques. Instead, most premature optimization discussions end up dealing with really tiny tasks.
This is problematic because, 1) being tiny, they are usually a part (tiny part) of a wide variety of algorithms so people overestimate their importance ("I can apply this speed-up all over the place!"). And 2) being tiny, the difference between what Benchmark.pm measures and what you can actually gain from using them is huge so people focus on "four times as fast!" and don't even think about "adds up to less than 1% of the run time of my script".
So, premature optimization is a bad habit but can be fun and educational in a perverse sort of way. And in very rare situations, micro-optimizations can actually pay off (at least a little bit). So I can cut people slack for playing with premature optimization as a learning exercise if it isn't micro-optimization. And I can see attempting micro-optimization if you've done the profiling to show that this micro-operation is actually adding up to a significant portion of your run time (that is, if the optimization isn't premature).
But I will always find premature micro-optimization to be something to be critical of when I see it (especially if I don't see anyone else pointing out that the numbers aren't nearly as exciting as they appear and the techniques aren't automatically the best choice in real code).
In that other thread, we see examples of both: people suggesting that the fastest code should be used in future code and people thinking that a 4x speed-up in a micro-optimization could end up with a 4x speed-up of total run time.
So, in theory, premature nano-optimization could be educational. In practice, I don't usually see interesting discoveries made and I very often see enthusiastic adoption of 'the winner' to the point of any other method being 'corrected' because it isn't 'efficient'.
| [reply] |
Re: Golfing and Sprinting
by chip (Curate) on Mar 16, 2004 at 15:58 UTC
|
Salzenberg's Zeroth Rule of Optimization: "Never optimize before benchmarking."
I once wrote a communications program that used too much CPU. Turns out that its primary time sink was ... mktime()! It was converting YMDHMS into time_t for event storage. I changed the database format and got a 33% CPU time reduction.
More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason -- including blind stupidity.
-- W. A. Wulf, "A Case Against the GOTO"
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply]
[d/l] |
Re: Golfing and Sprinting
by Old_Gray_Bear (Bishop) on Mar 16, 2004 at 03:07 UTC
|
And, coincidently give me an incentive to learn how Perl's bench-marking modules work. This has a lot of potential.
Go Speed-Racer!
----
I Go Back to Sleep, Now.
OGB
| [reply] |
Re: Golfing and Sprinting
by Anonymous Monk on Mar 16, 2004 at 05:48 UTC
|
There's a lot you can debate about optimizing code. Everybody will always have their own opinion as to whether a certain optimization is 'useful' or 'necessary'. I tend to lean towards the idea that if major optimizations are needed, then chances are the entire script needs to be rewritten, not just one or two bits. I am also very against so called 'optimizations' where people steal the chance to slip obfuscated code into production code. If you can't come back to an 'optimized' snippet of code a month or two after having 'optimized' it and immediately see what that code does, it shouldn't have been done in the first place. If you created this optimization, you shouldn't have to come back months later to copy and paste the snippet into SoPW and ask what it does!
| [reply] |
|
|
If I put a funky optimisation into "serious" code, I tend to leave the unoptimised version in place in a comment. That way, if I need to make changes, I can either:
- read the unoptimised version to help me figure out what the optimised version does;
- or I can revert to the unoptimised version, easily change the functionality, and then optimise it again if necessary.
Yes, this is different from jus saying "use CVS" :-)
| [reply] |
Re: Golfing and Sprinting
by graff (Chancellor) on Mar 21, 2004 at 03:26 UTC
|
Rather than "sprint" (whose spelling feels a bit too close to a couple of commonly used functions), I think a term like "treadmill" comes much closer to evoking the essence of this sort of game.
When you see a hamster playing on a treadmill, it really is more fun the faster it goes. It's neat and you gotta love it -- going faster is just an Obviously Good Thing, even for the hamster.
A key conceptual difference between a sprint and a treadmill is that in a sprint, you end up at a finish line, usually someplace other than where you started sprinting, whereas on a treadmill, the point is not to get to some different place, but simply to move faster while staying in the same place where you were already.
Maybe the prospect of monks posting things like "Here's another treadmill challenge" might dampen the general enthusiam for posts of this sort. (Then again, the presumed negative connotation of "obfuscated" hasn't diminished the popularity of posts in that wing of the Monastery.) | [reply] |
Re: Golfing and Sprinting
by ambrus (Abbot) on Mar 17, 2004 at 20:38 UTC
|
Marking "sprints": good idea.
I know this rule, but still often fall
against it, and do unneccessary micro-optimizations.
| [reply] |
|
|
