Author: Jaime Benito de Valle Ruiz
Date: 19:09:38 08/19/03
Go up one level in this thread
On August 19, 2003 at 20:28:11, Dan Andersson wrote: > It all depends on what hardware architecture you are running on. Saving and >restoring state are memory operations on a much larger scale than make/unmake. >And CPUs run much faster than memory in most cases. If the CPU execution stalls >because of memory accesses it might cost you dearly. Therefore it is usually >much faster to do computations than memory reads. The extreme example: it might >be faster to read compressed data from a HD and decompress it than reading the >same uncompressed data from HD. > >MvH Dan Andersson Good comparison! In the past, with extremely slow computers, if you wanted to optimize the code, you just had to reduce the total number of cycles during the execution of a program. Therefore, the less the instructions, the faster the program (in general). Nowadays, processors have become much faster than memory access, and this can be a problem: Imagine that the processor executes an instruction that has to read some memory address. If this "memory reading process" is fast enough, the computer can carry on executing the next instruction, and so on and so forth. But if this takes a bit longer, and the processor needs the value of that memory address before the next instruction, it just has to wait until it is available. So it doesn't really matter whether your micro is as fast as 15000 MHz, because it has to wait for the memory to "catch up" with it. Of course there are tricks to speed things up, such as internal caches (built-in fast memory), etc... So, as Dan explained before, avoid too much memory access can speed things up even though you do more computation. Optimizing for speed is harder than it looks; all you can do is follow some main guidelines, and do tests to see what seems to be faster. As an example, I tried to optimize a funcion in assembler some time ago just by reducing the number of cycles, and trying to pair instructions and all that... I ended up with a function with very few cycles (and instructions), but 6 or 8 memory read/writes. The alternative function had only 2 memory accesses, and about 3 times more instructions to execute, and far more cycles. The second turned out to be faster during the search, so I had to dump the first one. If you are not sure, make two different version, and use #ifdef / #endif to see which one works better. I guess a lot of people do that. I personally undo the moves instead of saving them in the stack. Good luck. Regards, Jaime
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.