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: f5d71,304c86061dc69dba X-Google-Attributes: gidf5d71,public X-Google-Thread: 1014db,304c86061dc69dba X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,304c86061dc69dba X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2004-02-12 04:49:16 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <402B763E.4000309@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) References: <20040206174017.7E84F4C4114@lovelace.ada-france.org> <54759e7e.0402071124.322ea376@posting.google.com> <2460735.u7KiuvdgQP@linux1.krischik.com> <54759e7e.0402081525.50c7adae@posting.google.com> <54759e7e.0402091826.2847e0c@posting.google.com> <54759e7e.0402101819.95cec1d@posting.google.com> <402A29B4.3010807@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 12 Feb 2004 12:49:15 GMT NNTP-Posting-Host: 165.247.67.51 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1076590155 165.247.67.51 (Thu, 12 Feb 2004 04:49:15 PST) NNTP-Posting-Date: Thu, 12 Feb 2004 04:49:15 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:5482 comp.lang.c:22066 comp.lang.c++:18880 comp.lang.java:2875 Date: 2004-02-12T12:49:15+00:00 List-Id: Ole-Hjalmar Kristensen wrote: > > Yes, but there are some caveats. Ada insists on getting floating point > arithmetic "right", so it will typically do it differently than C, > even though the Ada and C programs superficially look the same. For Well, I *did* say that only if you had similarly coded examples could you hope to do any comparison. Not that you couldn't do a comparison and see a difference. ;-) Secondly, one needs to insist that some code under evaluation must produce a *correct* result. If a C coded example computes the wrong answer at twice the speed of a similar Ada example that gets the answer right, is it even worth discussing? My final objection to the whole "Benchmark Wars" is that for 90% of the uses of compilers, it just plain doesn't matter. If I build a program to solve a matrix and it gets me an answer displayed on my screen in 10 seconds - but I re-code it in another language and the answer pops up in 8 seconds instead, what am I going to do with those extra two seconds? Save them up for Christmas? People do this sort of math stuff all day long in spreadsheets which are interpreting the answers at great inefficiency and they spend lots of time not caring about it. So why do programmers without a real performance constraint spend so much time getting their panties in a bunch over something that never has a real impact on what they're doing? Keep in mind that I work with apps where miliseconds count, so I know how to worry about compiler efficiency. I also know I can get good compiler efficiency out of Ada (plus all of Ada's other benefits), so when I *must* be efficient, I know I can get there. But when I go over to a PC or workstation to develop some hacker tool I need, worrying about a few extra CPU cycles is way down on my list of concerns. Too many people spend too much time agonizing over "Compiler Efficiency" - usually without any real scientific data to back up their perceptions of what is fast and what is slow - and most of the time it just plain doesn't matter. I'd bet that if we took most of the applications that people use on a daily basis and inserted random delay statements throughout them to double the amount of CPU cycles they use, nobody would notice any difference in how they got their job done. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ======================================================================