Author: Uri Blass
Date: 02:46:54 04/23/02
Go up one level in this thread
On April 23, 2002 at 05:03:42, Sune Fischer wrote: >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. In my program I thought about optimization in cases that it is important but only about changing the algorithm and I decided to do nothing about optimization of writing the same algorithm faster by assembler that I do not know. >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. It is not clear if doing it in O(N*logN) is better because often the first move fail high and you can do it in O(N). >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. Speed optimization is important if you expect a factor of 10 but I do not think that professional programmers expect this factor by optimization of their program. I am sure that they spend time about optimization in cases that they can get a big improvement. I also did it and before having a chess program I improved the speed of my move generator by a factor of about 100(I am not sure about the exact number but my first move generator was very slow). Uri
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.