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: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,304c86061dc69dba X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,304c86061dc69dba X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2004-02-15 06:15:40 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!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: <402F7EFC.9070304@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: Sun, 15 Feb 2004 14:15:40 GMT NNTP-Posting-Host: 165.247.65.125 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1076854540 165.247.65.125 (Sun, 15 Feb 2004 06:15:40 PST) NNTP-Posting-Date: Sun, 15 Feb 2004 06:15:40 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:5577 comp.lang.c:22557 comp.lang.c++:19173 comp.lang.java:2953 Date: 2004-02-15T14:15:40+00:00 List-Id: Well, from my experience with benchmarking for realtime systems, we generally drew on sample code that was typical of our control systems. Compiler A might do a real good job of optimizing one algorithm while Compiler B was better at another. This was done for purposes of selecting which Ada compiler we wanted to use for the given target - not for selecting a language. We never attempted language-to-language benchmarking because we pretty much figured it was pointless. Too many variables to really get a meaningful result and we knew we could get realtime quality out of most languages usually used for the purpose. So we picked the language based on other factors (error reduction, improved productivity, etc) and then benchmarked the competitors in that category. Key to trying to do any evaluation of anything in a scientific manner is to hold "all other things being equal" and when it comes to code in different languages with different compilers, you have a tough time doing this. A key result of our tests is that there are seldom any clear winners. It depends a lot on what your real-world code is going to look like. Some languages may be ruled out for lack of a competing implementation (if nobody makes an embedded compiler for your target, the game is over) but usually the "conventional" players are around. Then - depending on the specific compiler - there are various ways of getting optimal code for the algorithms you're interested in and usually you have to learn that along the way. Its seldom an exact science. Sooner or later you pick something and then get on with getting the job done. So long as you didn't pick something hopelessly inefficient, you usually find a way to get reasonable results with what you picked. I'd offer again my observation that for probably 90% of the software development that goes on in the world, relative compiler/language inefficiency is a total non-issue and people ought not to sweat over it. Even if there was any truth to the "Ada is slow..." rumor (and a given compiler is twice as slow as some highly optimized C example?) you'll never even see it in most applications. One ought to then focus in on other important factors that go along with language selection such as available compilers, reliable implementations, improvements in error rates and/or productivity, available tools, available libraries, time-to-market issues, etc. MDC Jerry Coffin wrote: > > IMO, this produces a benchmark that is so far departed from the real > world that while it may produce results that are accurate (for some > definition of the word) they're utterly devoid of relationship with > reality, and therefore of any real meaning. > > If you want to do a comparison, you need to compare things how they're > really used. There are certainly variations among programmers, but to > be meaningful the test code should fall well within the range of normal > variations. We all know that "real programmers can write Fortran in any > language", but writing Fortran in Ada, C++, Java, etc., doesn't really > accomplish much, and the performance of such code is meaningless at > best, and more likely to be downright misleading. > -- ====================================================================== 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 ======================================================================