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-Thread: 103376,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newsfeed.stanford.edu!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: CTips Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Wed, 09 Mar 2005 20:47:02 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <112v9p788s1684d@corp.supernews.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <422ee0ce$0$1091$9b4e6d93@newsread2.arcor-online.net> In-Reply-To: <422ee0ce$0$1091$9b4e6d93@newsread2.arcor-online.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Xref: g2news1.google.com comp.lang.ada:8990 comp.realtime:1167 comp.software-eng:4725 Date: 2005-03-09T20:47:02-05:00 List-Id: Georg Bauhaus wrote: > CTips wrote: > >> In fact, to get the performance similar to that which can be obtained >> in C, one would pretty much have to write in the C subset of Ada [i.e. >> turn off most of the checking, use libraries written in C + asm]. > > > Is there any significant evidence for this other than > special cases for any of the languages discussed? Don't have something specific to Ada, but I've seen work on PL.8, which had similar dynamic bounds checking. They observed, *on the average* about 8%, but this was on a machine with a special trap instruction for bounds checking. It would be closer to 15-20% if the check had to be done using subtract/compares/branches. Also, other work done on bounds checking ~1990 (maybe by Rajiv Gupta) has numbers between 0 and 50% slowdown. And these, by the way, IIRC dont actually count the cost of having to use handles vs. pointers, just the cost of the raw access. You can measure the slowdown yourself. Try running the following loop in Ada: void do_perm(int a[], int perm[]) { int i; for( i = 0; i < VERY_LARGE_NUMBER; i++ ) a[perm[i]] = i; } where perm[i] is a dynamically created array, such as: void setup_perm(int perm[]) { int i; for( i = 0; i < VERY_LARGE_NUMBER; i++ ) perm[i] = i; } Run the codes with and without bounds checking and see the difference. > And why on earth should translators for programming languages > be so dumb as to produce fast code only when the input language > is like "the C subset"? Because the run-time check code required by the language will require extra work. > If a compiler knows about enum values and can use them in the > construction of objects matching hardware, or of arrays of bytes, > or whatever, why should the enum values incur a speed penalty? > Because the compiler checks that there is static matching > at compile time? Compile time checks are for free ... sometimes. Be careful that you aren't really adding runtime checks. For instance, int foo(index_type i, int a[index_type'range]) { ... a[i] ... } will have no check, since it is guaranteed that the size of a is equal to the range of values of i. However, if we now invoke this using int i; ... foo( (index_type)i, a); then we (may) have to add a run-time check to see whether i is in the range of index_type. There is a secondary, but fairly important affect. Compiler resources are finite, and compilers also suffer from "bit-rot". Roughly, you can only cram in so much effort into a compiler before its run-time or bug-rates or heuristic-balancing effort become unacceptable. In the case of a feature rich language like Ada (or C++), much of the effort goes into getting all the features right. In C, almost all the effort goes into the optimizations. Even when people appear to use the same backend, in practice, there are various optimizations which get disabled for non-C languages because they break at various corner cases in other languages. >> And even there I'd have my doubts - given the additional features that >> Ada compilers have to deal with, I doubt that they would have focused >> as much on the optimizations. > > > Given that the language provides > pragma Optimize (Time/Space/Off) > I doubt that this general doubt can be justified. and you are speaking from how many years of compiler development...? >> (How can you get beaten by Python? The mind boggles!) > > > Easy. You are not actually beaten by Python, but by a highly > optimized C matrix library which is bound to python as an > extension. > If you're interested, for Ada 2005, ISO vector and matrix > subprograms are added to the language standard. > > > Georg