X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Date: Wed, 18 Feb 2004 09:42:20 -0600 From: Eric Rudd Subject: Re: C99 Functions Under Development and Checkout In-reply-to: To: djgpp-workers AT delorie DOT com Message-id: <403387DC.8080102@cyberoptics.com> Organization: CyberOptics MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030925 References: <40312BCC DOT 1080507 AT cyberoptics DOT com> X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Eli Zaretskii wrote: >As someone who was involved, albeit as an interested bystander, in >Eric's efforts to produce fast, reliable, and standard-conforming >functions, I largely agree with these sentiments. > >So I think that it is not too awful that we will continue to have >these deviations from C9x. > In the C99 standard, there is the following: 6.10.8 Predefined macro names [#2] The following macro names are conditionally defined by the implementation: __STDC_IEC_559__ The decimal constant 1, intended to indicate conformance to the specifications in annex F (IEC 60559 floating-point arithmetic). We can conform to the standard with the current math functions by not defining this macro. Then, when someone has the inclination and energy to modify the functions, they can define this macro. I have read Esa's posting, and can also see his point of view; I agree that standards are important, and would tend to adhere to a standard rather than personal preference. However, I can't even reconcile IEC 60559 with the rest of the C99 standard, in particular, with the following clause: 7.12.1 Treatment of error conditions 1 The behavior of each of the functions in is specified for all representable values of its input arguments, except where stated otherwise. Each function shall execute as if it were a single operation without generating any externally visible exceptional conditions. 2 For all functions, a domain error occurs if an input argument is outside the domain over which the mathematical function is defined. Since, for example, inf/inf is outside the domain over which the arc tangent function is defined, it would seem that a domain error should occur. >>on the Pentium 4, the coprocessor handles NaNs, etc. through an >>exception mechanism that is as much as 300 times slower than normal >>execution. >> >> >Do you have details about this? Like more precise timings, the >reasons why it is so slow, etc.? > I doubt that the timings are completely consistent, but I modified an FFT test harness to take the 2-D FFT an array of NaNs, and got the following for a 1024-by-1024 array on a 550-MHz Pentium 3: Valid floats, 30 ms; NaNs, 1.06 s -- a ratio of 35. On a 1.7-GHz Pentium 4 there was even more of a difference: valid floats, 11 ms; NaNs, 2.6 s -- a ratio of over 200. My guess is that Intel wisely decided to make the routine floating-point computations more efficient, at the expense of unusual computations. I don't know how much DJGPP is involved in handling these exceptions, but the substantial differences between the Pentium 3 and Pentium 4 would suggest that the hardware is causing most of these delays. -Eric Rudd