Author: James Robertson
Date: 20:19:12 06/18/00
Go up one level in this thread
On June 18, 2000 at 19:17:20, Bruce Moreland wrote: >On June 18, 2000 at 17:15:36, James Robertson wrote: > >>I did this. To do a 64 bit shift, MSVC calls a function named _allshl or >>_allshr. This is the code it provides (copied and directly from the debug >>executable and uncleaned): > >Try with full optimization, you'll probably get the same stuff, but it's worth a >try to see if it does something different, and you can do it in like 10 seconds. > >>My assembler code is much faster than what the optimized compiler produces. :) >>Also, certain instructions, such as bsf/bsr are impossible to use in C/C++, and >>so inline assembler is a necessity, if for those commands only. > >You are being a little evasive and talking around this a bit, so I'll lightly >blast you, in case you need it. You probably don't need it, but it can't hurt. I have total of 64 lines assembler in my program.... it is faster than what the compiler/optimizer produces, mostly because bsf/bsr can't be represented in C++ and not from any great assembler skills on my part. James > >It is very easy to make something twice as fast as it was before, while having >absolutely no impact upon wall-clock speed. There are two kinds of time, there >are instruction cycles and there is wall-clock time. You are talking about >instruction cycles, but performance optimizations should have some basis in >wall-clock time. If you can't use some sort of generic analog clock to detect a >significant speed increase, any performance change is a bad idea, unless you get >something else good from it. Decreased readability and portability, and >increased complexity, don't qualify as good. > >In short: Careful with that ax, Eugene. > >bruce
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.