Author: Sune Fischer
Date: 02:03:42 04/23/02
Go up one level in this thread
On April 22, 2002 at 18:10:20, Gareth McCaughan wrote: >On April 21, 2002 at 21:22:53, Russell Reagan wrote: > >> My specific question is about whether it's faster to use a struct >> for your position, or to simply have some global variables. >> Global variables seem like they would be faster because you >> don't have to dereference the pointer. > >1. All the people who have said that this is too small a difference > to worry about, are absolutely right. > >2. Global variables might be faster because you might save a > pointer dereference. On the other hand, it'll be in cache > all the time and shouldn't cost much. And if the pointer is > in a register then you might have the same number of memory > references either way. And global variables might be slower > because constructing the address to look up might take a few > instructions. All of these are small issues. > >3. Global variables will make your program harder to parallelize. > Don't worry about this. There are so many *real* difficulties > with making a decent parallel program (the search, the hash > tables, etc) that this sort of superficial thing will be lost > in the noise. > >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. > >-- >g 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? I supose one can get an indirect measurement if the function can be inlined. 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. That was my first design, I rewrote it but I didn't find it trivial to do. I simply had to change it, I couldn't stand looking at what I knew was p*ss poor code. Knowing that what you write will be fast and efficient, is part of the fun IMO. 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? ;) -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.