|
 |
Patrick Elliott nous apporta ses lumieres en ce 2007/09/19 23:13:
> In article <46f198c1$1@news.povray.org>, ele### [at] netscape net
> says...
>> Ger nous apporta ses lumieres en ce 2007/09/19 13:16:
>>> Zeger Knaepen wrote:
>>>
>>> If vars are defined as float then why the need to define them as such? On
>>> the other hand, integers are much faster so why not use both?
>>>
>> Integer operations are not faster than floating point ones, this is due to the
>> arithmetic coprocessor that is integrated in all processors since the advent of
>> the Pentium. In fact, the oposite is almost always thrue for any multiplication,
>> division and modulo. It was even the case for the 286, 386 and 486 whenever you
>> also had an arithmetic coprocessor installed on your machine.
>>
> Tell that to the people that wrote Franctint (on a 486, Pentium or
> anything else). lol But seriously, even if they where marginally faster
> at one point, for specific situations, this isn't necessarily true now,
> nor applicable to what **this** program is doing. The results even in
> Fractint differed in some cases, depending on if you used the faster
> integers or floating point. One of the points of having POVRay behave as
> it does is "predictability" in what you get from it.
>
If using a 486 or earlier, AND NOT using an arithmetic coprocessor, integer
operations where much faster than floating point. Especialy the add and
substract. Multiplications where only slightly faster.
Add in the coprocessor and, apart from int add and sub, floating point jumps
ahead, largely ahead!
At that time, you could get slightly different results depending on the brand of
your coprocessor: differing algorythm and rounding method, as well as intrinsic
precision.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you stop using a protractor to
measure angles because you can do it just by looking.
Taps a.k.a. Tapio Vocadlo
Post a reply to this message
|
 |