From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e0423f8984d47f76 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-09 15:36:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!newshub1.home.nl!home.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!news2.euro.net!newspeer1-gui.server.ntli.net!ntli.net!newsfep4-glfd.server.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problems converting Float to Integer efficiently References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 09 Oct 2003 23:36:29 +0100 NNTP-Posting-Host: 81.100.88.147 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep4-glfd.server.ntli.net 1065738990 81.100.88.147 (Thu, 09 Oct 2003 23:36:30 BST) NNTP-Posting-Date: Thu, 09 Oct 2003 23:36:30 BST Organization: ntl Cablemodem News Service Xref: archiver1.google.com comp.lang.ada:560 Date: 2003-10-09T23:36:29+01:00 List-Id: Jeff C, wrote: > If you can use a more up to date gcc (a 3.X series) and have a pentium 4 > (maybe ok on III) > then you can try this little thing I made ... > Asm ("cvttss2si %1, %0",inputs => float'asm_input("m", y), > Outputs => integer'asm_output("=r",temp)); This works great! I have had no problems on my Athlon (1100MHz clock speed) and GNAT 3.15p My experiments show the following: -- X is integer, Y is float X := X + Truncate(Y); -- 0.029us 1x X := X + Integer (Y); -- 0.360us 12x X := X + Integer (Float'Floor (Y)); -- 1.196us 41x This is timed in a tight loop. Optimisation "-O3", Checks suppressed, inlined where possible. I checked carefully that the "right" code was being generated, and the test was fair. These lines are not exactly equivalent in function - I wanted "floor", but "Truncate" is OK As you can see, the "obvious" Ada code for converting to integer is at least 12x slower than Jeff's version. This has the potential to be quite significant in my code which implements interpolation of five dimensional arrays for function approximation. I also had a look at the "stereopsis" and "gems" web site. It seems the deficiency of compiler in getting integers from floats has caused other people difficulties too. I'm slightly worried that the "Truncate" function will fail if the FPU/SSE mode is changed. I'll try to cross that hurdle if I encounter it. Quoting the stereopsis site : "I've seen quite well-written code get 8 TIMES FASTER after fixing conversion problems. Fix yours! And here's how.." This whole situation illustrates one of the things which frustrates me about coding in Ada/GNAT: performance and reliability of Ada code is often very good, but you need to be eternally vigilant that you are getting out the code that you think you should be getting. The speed of the compiled code is sometimes critically dependent on apparently inocuous choices. Things like enumerated types, use of generics under certain circumstances etc. can cause apparently good source code to crawl. Is this a necessary price for ditching low-level HLLs like 'C'? Perhaps someone should create a web site highlighting the problem areas and explaining the solutions? Volunteers anybody? Thanks guys for the help on this! -- Adrian Wrigley, Cambridge, England.