Author: Uri Blass
Date: 00:49:43 02/25/03
Go up one level in this thread
On February 25, 2003 at 02:30:30, David Rasmussen wrote: >> >>The only reason that I decided to try C++ is inlining functions >>I see that I do not need it because it seems to me based on looking at the help >>that __inline in C is the same as __inline in C++ and I see no difference >>between __inline and inline in C++. >> >>I do not know how to select the option inline every suitable function and I now >>only optimize for speed(I use VC++6). >> > >C++ has many advantages over C (better type safety etc.) and speed can be one of >them, but you have to learn to use C++ the proper way. It's not a good way just >to take a C program and compile it with a C++ compiler. You _can_ use C++ just >as a better C, and that is often a good idea for many kinds of projects. But you >have to put some time into it, just as you've put some time into learning and >using C. If you work two months on your program just doing what you normally do, >but using a C++ compiler, you may find that suddenly the C++ compiler is faster >for you than your C compiler. Because that is the environment you've been >working and testing in. Whenever you've made some small decision about something >because you got a 0.1% speedup, that might not be because what you wrote was >better C or better chess programming, but simply that you wrote something that >suited your C compiler better. I basically do changes because I believe that they can do my program better. This is not a random process. There were cases when I did not do productive changes because they did my code slower inspite of the fact that they were correct but I do not believe that there were cases when I did counterproductive changes that made my program faster. I can give you a simple example of a speed improvement that I can make I have in my program the following #define dsee(target,side) ((directsee[(target)]>>((side)<<4))&65535) side can get only 2 numbers LIGHT and DARK. It may be better if I change it to #define dsee(target,LIGHT)=((directsee[(target)]&65535) #define dsee(target,DARK)=((directsee[(target)]>>16)&65535) The last thing can be done faster by #define dsee(target,DARK)=((directsee[(target)])&65535<<16) but in that case I need to change other places in my program because dsee(target,DARK) does not mean the same thing. If you really care about these tiny speed >improvements (which is a very bad idea at this point, I think), and you want to >use a C++ compiler for it's many advantages, I suggest that you work in that >environment for some time before making a decision. If you learn to use C++ in >the way it was meant (that doesn't necesarily mean object oriented, but C++ is >_not_ C, it is very different), you will reap even more benefits than tiny >temporary speed gains that will disappear anyway as you make your program more >complex. You really can't "solve the speed issue" first and then go on doing >everything else. You have to find a good design, and only when your program and >design is mature, you can work on speed. __Using a profiler__. There is no contradiction and I think better design can help to do movei clearer and faster. 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.