Author: Sune Fischer
Date: 16:16:49 04/23/02
Go up one level in this thread
On April 23, 2002 at 16:48:40, Gareth McCaughan wrote:
>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.
I just got thinking about this when I saw the profiling for Crafty,
5048.910 10.4 11124.408 23.0 2711409 _Evaluate (evaluate.obj)
4428.789 9.1 4428.789 9.1 19410143 _FirstOne (boolean.obj)
2845.005 5.9 5460.414 11.3 1431561 _GenerateCaptures (movgen.obj)
FirstOne is called extremely often, isn't that expensive?
>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.
That may depend on how you generate the moves.
In some designs it may not be easy to generate captures first.
I think if I could generate checks, then it might be worth trying checks before
killers or something. All these posibilities will be limited by the kind of
structures you choose, so you need to have a firm grasp on what you want to do
later on and take that into account during the design phase.
Some things are easily optimizable, but the backbone design is usually not.
>> 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.
yeah, its for the fun, who else would in their right mind spend so many hours
making a weak engine, when they can buy Tiger for an amount they can earn in
less than half a days work.
>> 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.
I predict that by the year 2020 it will require a 15 GHz machine with 20 GB
memory to open wordpad ;)
>--
>g
-S.
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.