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: 109fba,304c86061dc69dba X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,304c86061dc69dba X-Google-Attributes: gid1014db,public X-Google-Thread: f5d71,304c86061dc69dba X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-17 01:12:34 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!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.adelphia.com!news.adelphia.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 17 Feb 2004 03:12:33 -0600 From: Jerry Coffin 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 Date: Tue, 17 Feb 2004 02:19:52 -0700 Message-ID: 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> <402F7EFC.9070304@noplace.com> Organization: TAEUS X-Newsreader: MicroPlanet Gravity v2.50 NNTP-Posting-Host: 68.64.173.106 X-Trace: sv3-OjnPo6SWzah+DhmqhRzMj/lY2UZ84cyjGa3mpngJY2VBuNmoH6pEGPdX1iCdeVE2xDfSMdVT320N4IZ!fWbCL2ONUS3bIagyzDYDWybO36j1C13ggM+UI6FUdtTbUU4ZOKa2PR//ytqvs8M+2Qk+jxFy2xjC!qVEU8dxbnrrildTdsNqAL+s= X-Complaints-To: abuse@adelphia.com X-DMCA-Complaints-To: abuse@adelphia.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5627 comp.lang.c:22859 comp.lang.c++:19350 comp.lang.java:2973 Date: 2004-02-17T02:19:52-07:00 List-Id: In article <402F7EFC.9070304@noplace.com>, nobody@noplace.com says... > Well, from my experience with benchmarking for realtime systems, we > generally drew on sample code that was typical of our control systems. That doesn't sound like anything I'd depend on for a realtime system -- to be meaningful in a realtime context, you normally need to look at a worst case, not a typical one. > We never attempted language-to-language benchmarking because we pretty > much figured it was pointless. I agree that it usually is -- I didn't intend to advocate comparing languages at all, but merely to offer my opinion that the method being advocated would render the results definitely pointless instead of only probably pointless. [ ... ] > 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. Quite true. > 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. I suppose that depends on the applications you spend your time writing. I agree that with the typical office applications (for example) a factor of 2 (or even 10) in speed will rarely be noticed. OTOH, I've worked on code for doing MPEG encoding. Back when I was working on it, a 1 GHz (or so) Pentium III was about the state of the art, and with that my code took around 3 to 3 1/2 hours to encode one hour of video. Most of the other code I was aware of at the time was closer to 5 hours on the same hardware. I suspect even with today's faster hardware this is still over an hour -- and in a case like this, a factor of 2 is clearly quite a big win. I'm the first to admit that most applications aren't this compute- intensive, but I'll also point out that MPEG encoding isn't exactly unheard-of either, and there are a number of other tasks that are even more so (e.g. cryptanalysis in many cases). > 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. Generally quite true. -- Later, Jerry. The universe is a figment of its own imagination.