Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Floating point VS Integer Math.

Author: Ivan Tirado

Date: 22:51:18 05/14/98

Go up one level in this thread


On May 15, 1998 at 00:31:19, David Blackman wrote:

>On May 14, 1998 at 21:35:52, Ivan Tirado wrote:
>
>>  Ok. So in *normal* micros integer math dominates. Is this necessarily
>>so? Are you SURE? I do some programming myself, and I remember that the
>>Glide reference manual ( 3DFX graphics ) states that it uses floating
>>point math in its library: ( I paraphrase now ) "...because it is MUCH
>>faster in pentiums..". Was 3DFX wrong when it wrote this? Or am I
>>confusing something here? ( i.e. is FIXED POINT math == integer math ??
>
>Floating point multiply is faster than integer multiply on a lot of
>modern
>cpus, probably including the pentium. Floating divide is sometimes
>faster than
>integer divide too.
>
>However floating point add, subtract and compare will be slower than
>integer add, subtract and compare on just about anything. The inside
>loops of chess programs tend to do a lot of add, subtract and compare,
>but very little multiply and divide. So integer arithmetic is probably
>the best choice for chess. It would be different for graphics.
>
>Fixed point is nearly the same as integer. You use integers but pretend
>there
>is a binary point at some fixed place inside the number. You can do
>normal
>integer add and subtract for fixed point. For fixed point multiply or
>divide you do an integer multiply or divide followed by a shift.

  Thanks for the reply. Yes, you're right. I have seen this behaviour
myself with the add - substract on floating point numbers. Remember that
multiplication is basically fast addition, so an algirithim may still
benefit from FP multiply, although not from FP divide. This, of course
from a mathematical standpoint, since the FP internals may alter the
outcome ( may or may not be faster, platform dependent ). Now, since
you've stated that chess programs use a lot of add-substracts with
integers, wouldn't MMX give a BIG speedup to the eval? Or is coding for
MMX too hard/inconvenient? I believe that an eval function optimized for
MMX would vastly outperform a similar algorithm in a non MMX setup.
Would you please comment on this?



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.