Author: Omid David Tabibi
Date: 11:35:03 07/06/03
Go up one level in this thread
On July 06, 2003 at 14:12:34, Gerd Isenberg wrote: >On July 06, 2003 at 14:00:03, Omid David Tabibi wrote: > >>On July 06, 2003 at 13:29:56, Gerd Isenberg wrote: >> >>>On July 06, 2003 at 12:57:59, Dieter Buerssner wrote: >>> >>>>On July 06, 2003 at 05:02:50, Gerd Isenberg wrote: >>>> >>>> >>>>>With mvc using math.h abs is fastest. With gcc cdq inline assembly abs or omids >>>>>c-abs is much faster than the branching lib abs (maybe a macro from some header >>>>>file?). >>>> >>>>Hi Gerd, as far as I can see, abs is no macro in my gcc environment. It wouldn't >>>>be possible with Standard C methods, would it? Because you would not be allowed >>>>to evaluate the argument twice. Of course, they could use compiler specific >>>>extensions and/or inlining. I checked by precompiling the source. I think, Gcc >>>>will detect abs() just like other functions (memcpy for example) and can inline >>>>it directly. Ineeded I see the "simple_abs" method branch in the assembly. >>>> >>>>The strange thing, that omid_abs was significantly faster than nothing with MSVC >>>>and rand(), do you have any idea? >>> >>>hmm, not really - may be because omids_abs is the only one which predicts the >>>conditional loop jump correctly all the times ;-) >> >>That's what I thought; but apparently 'sar' costs more than the branch I tried >>to evade. >> > > >maybe the sar latency is the reason that a out of order preexecuted dec edi >outcome is predicted correcty. Doesn't VTune report branch misspredictions? I'm rather new to VTune, maybe more experienced users of VTune know how to get that info. The branch misprediction rate should be around 50% in my program, as abs is used to find distances between squares (sq1 - sq2). That's why I wrote an alternative abs to evade the presumably high cost of branch mispredictions.
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.