Author: Gareth McCaughan
Date: 13:48:40 04/23/02
Go up one level in this thread
On April 23, 2002 at 05:03:42, Sune Fischer wrote:
[I said:]
>> 4. When you have any optimization issue, there are three rules
>> about optimizing code.
>>
>> a. "Jackson's First Rule": Don't do it.
>> b. "Jackson's Second Rule" (for experts only): Don't do it yet.
>> c. Profile your code. Measure, don't guess.
>
> I wonder if the profiler will find everything.
> How much does it cost to call a function?
> Where will this time show up in the profile, on the function being called
> or on the function calling, or not at all?
Function calls are fairly cheap these days, I think. ("These days"
being for at least the last 10 years.) Where the function call cost
shows up depends on your profiler.
Of course a profiler won't find everything. That's not its job. What
it will do is to tell you what bits of your program (usually very large
bits, and often not the bits you think) are contributing only (say) 5%
to the runtime of the program, and therefore aren't worth optimizing.
(That doesn't mean you can ignore them completely. Algorithmic
changes, as opposed to code optimizations, are where the really
big speedups lie, and you can't always find those by looking
only at the hot spots.)
> In contrary to what many people suggests, I think one should not completely
> ignore optimizations. If you give it no thought at all, you quickly stand to
> lose a factor of 10 or worse.
> Things like generating the entire movelist and then sorting the
> entire movelist by some simple O(N^2) algorithm, and doing all this
> with a huge array being allocated on the fly is real bad, it will
> cost a lot of performance.
Quite true. Two comments.
1. It's debatable whether to call that an "optimization" at all;
I would, but some people use "optimization" to refer specifically
to algorithm-preserving changes.
2. Switching from generating the whole move list and then sorting it
with bubblesort, to generating the whole move list and then sorting it
using a more intelligent sorting algorithm, or to generating the whole
move list and then doing as many stages of selection sort as you need,
is easy to do if the program has been written cleanly. You can do it
later. That already deals with a lot of the inefficiency you're talking
about. Switching to something cleverer that doesn't generate all the
moves first is more work, but I think it's clear that the extra effort
of doing it later rather than from the start is easily outweighed by
the improved debuggability in the early stages if you start with simple
move generation code.
> Knowing that what you write will be fast and efficient,
> is part of the fun IMO.
Absolutely true. It takes self-control to concentrate on making
your programs better even when that means having less fun :-).
When you're working on something only as a hobby, maybe it's worth
having more fun even though you know it will result in more pain
in debugging and a worse program.
> I also think a lot of professional programmers do not spend enough time
> optimizing for speed. They are too busy implementing a lot of fancy features,
> the end result is are programs that can do a lot, but will do it slowly
> and use a ton of memory. That means we all have to upgrade our hardware,
> which means the programmers can become even more sloppy with their code
> etc...
>
> They all wait with the speed optimization till their program is done,
> but when is a program done? It never is, suddenly its time to release
> the program and they spend the last critical hours franticly debugging..
>
> Am I right? ;)
Possibly. But I am not convinced that programs would get faster
if programmers spent more time doing early optimizations. I think
they'd just get buggier.
--
g
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.