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: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-04 07:56:52 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3B6C0DC7.661B3D46@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <9k9if8$rn3$1@elf.eng.bsdi.com> <3B687EDF.9359F3FC@mediaone.net> <5267be60.0108021911.7d8fe4@posting.google.com> <3B6B637F.E3FA243E@worldnet.att.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 04 Aug 2001 14:56:52 GMT NNTP-Posting-Host: 12.86.33.233 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 996937012 12.86.33.233 (Sat, 04 Aug 2001 14:56:52 GMT) NNTP-Posting-Date: Sat, 04 Aug 2001 14:56:52 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:11293 comp.lang.c:72105 comp.lang.c++:79919 comp.lang.functional:7300 Date: 2001-08-04T14:56:52+00:00 List-Id: Tor Rustad wrote: > > "James Rogers" wrote in message > > There is no such thing as a faster programming language. Certain > > compilers may produce faster code. Some compilers allow you to select > > optimization for a balance of speed and code size. These optimizations > > are not a language issue. They are compiler implementation issues. > > Not quite, when using a language which has built in security mechanisms on > a target which doesn't support these features natively (in HW), then there > will simply be a performance penalty. It may be significant, or it may very > well not be. In this case, perhaps it was? Let's get past generalities and talk facts here. Ada provides run time checking. It also provides the ability to eliminate the run time checking. The part of the Ariane 5 code that cause the problem had its run time checking removed. This results in performance undistinguishable from code generated by languages with no ability to automatically produce run time checking. The code had been tuned for performance. The problems encountered had no basis in poor performance. The problems were caused by a faulty software reuse process. > > Just ask yourself. "How fast is C? How Fast is C++?" There is no > > answer to that question. Speed is not specified in any language > > reference manual. > > Yes, comparing C vs C++ can be silly, more so when the code have identical > syntax. In the Ariane case, there was particular target (HW plattform), I am > shure there was performance differences between using different > languages/compilers/optimizers for this target. > > Write a "Hello world!" program in Java, and name one single case for which > my C version will run slower. ;-) Again, Java's slow performance is not an issue of the language. It is an issue of the run time environment. If you were to implement the Java machine in hardware, instead of using a virtual machine, then Java performance would be as fast as C. Java's performance real performance problems begin with the fact that Java only runs on one target. That target is emulated on most hardware. Software emulation of hardware always produces performance problems. > > In real life the language used do matter, so does the algorithms, compiler > and optimizer for that matter. Some langages support performance contructs, > e.g. in C99 we have const, restrict and volatile keyword, which let the > programmer control optimizations at low level. An other example is the > floating point conversion rules in C, which may give rather poor > floating-point performance (compared to for example a Fortran program), but > it depends on the target etc. I see now that you are admitting that performance is not controlled by the language. Implementations and environment may play a roll. Given your analysis of performance related to languages I could state that C programs are clearly slower than Ada programs with run time checking turned on. How can this be so? Easy. Ada provides efficient built in support for concurrency. C does not. Therefore, the most common and natural design for a C program is single threaded. On the other hand, it is very common to have a multi-threaded Ada program. Given a common platform, such as a PC running a Win 32 operating system, I could easily build an Ada program with multiple threads implementing a socket server, that would blow away any single threaded C implementation. I could do this with all run time checks enabled in Ada, and all optimizations enabled in C. Which language is faster? The answer still cannot be given. You can only measure specific implementations, not languages themselves. Jim Rogers Colorado Springs, Colorado USA