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 19:05:34 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail From: "Jeff C," Newsgroups: comp.lang.ada References: Subject: Re: Problems converting Float to Integer efficiently X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: NNTP-Posting-Host: 66.31.4.164 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1065751533 66.31.4.164 (Fri, 10 Oct 2003 02:05:33 GMT) NNTP-Posting-Date: Fri, 10 Oct 2003 02:05:33 GMT Organization: Comcast Online Date: Fri, 10 Oct 2003 02:05:33 GMT Xref: archiver1.google.com comp.lang.ada:564 Date: 2003-10-10T02:05:33+00:00 List-Id: "Dr. Adrian Wrigley" wrote in message news:Oplhb.9211$RU4.88029@newsfep4-glfd.server.ntli.net... > Jeff C, wrote: > > > 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! No problem... The problem is not really unique to Ada. Even with C if you are writing performance critical code you often run into areas where you have to do "something" to make the code run better. This can be an assembly language insertion or just a restructing of the code to help the compiler figure out what you wanted better. I have ended up having to create my own memcpy/bcopy serveral times because the "optimized" one from the compiler ended up doing something really bad for a specific (but potentially common) situation. The problem with any website or list I have ever seen that tries to tell you things to "look out for" is that they all tend to be full of misleading information that is either based on someone not understanding the tool or language or based on some specific compiler, version, bug, os, etc. My best advice is to run a profiler and see what you can see. Of course this is one of those things that people always say but there are plenty of ways for profilers to get somewhat confused too so even using a profiler can be somewhat of an art form. I have personally used generics to actually make some code faster in the past (and had no problems with performance critical code with enumeration types as long as you stay away from 'image 'value in performace critical code and avoid rep-specing them when you don't need to). Now even my last statement is full of half-truths and misleading info. I can just see someone going ah-ha I won't use a 'image I'll build a lookup table of pointers to strings and return that...and of course the code would be just as slow..(probably).....