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!news.glorb.com!fr.ip.ndsoftware.net!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Thu, 10 Mar 2005 17:39:47 +0100 From: Georg Bauhaus User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) 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> <112v9p788s1684d@corp.supernews.com> In-Reply-To: <112v9p788s1684d@corp.supernews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42307820$0$26539$9b4e6d93@newsread4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 10 Mar 2005 17:38:56 MET NNTP-Posting-Host: 20467763.newsread4.arcor-online.net X-Trace: DXC=OeM8:8PLn55gL1_>^S7Mi=:ejgIfPPld4jW\KbG]kaM8GSi?jHD8GO0X>8oCbEoIQ1hP3YJKgE\j<:` CTips wrote: > 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. Done. You might be disappointed by the results. In short: < 1%, < 3%; and < 8% for a different program, really. [...] If I run your program as an Ada program, I must use unconstrained arrays to get a significant difference at all. And in this case I am no longer copying the meaning of the C program. If I use arrays of known sizes, and turn all checks ON, the Ada/C ratio is near 1.03. Still this is certainly *not* using the C subset of Ada because the compiler sees Ada arrays of integers, not C int[]s, it is compiling Ada programs, using Ada rules, semantics, optimizations, passing modes etc.. If I turn checks off then there is no more significant difference. If I rewrite your program and actually implement a different algorithm, as outlined in your post (unconstrained arrays), then indeed this program runs with a slowdown of 7-8%. But same speed of Ada and C programs doesn't mean "C subset", since to run at about the same speed, I don't have to turn off the checks, and I don't loos all language constructs. If you think that a factor of 0.03 generally is an inacceptable slowdown so no checks please etc, then I don't know what to say. Except that marketing works this way. gcc -W -O2 -ansi -pedantic (C) gnatmake -O2 -gnato -gnatE -gnatVa -fstack-check -gnatwa (Ada, checks) gnatmake -O2 -gnatp -gnatwa (Ada, no checks) GCC 4.0.0, 20050215 in all cases Here is the slow version, that is, the different algorithm, really. The near same speed version can be obtained by shifting three comments. with Perms; procedure perm_a is use Perms; perm: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1); other: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1); --perm: constant PA_Ptr := new Perm_Array; --other: constant PA_Ptr := new Perm_Array; begin setup_perm(perm.all); do_perm(other.all, perm.all); end Perm_A; package Perms is VERY_LARGE_NUMBER: constant := 100_000_000; type Perm_Array is array(Natural range <>) of Integer; --type Perm_Array is array(0 .. VERY_LARGE_NUMBER - 1) of Integer; type PA_Ptr is access Perm_Array; procedure do_perm(a: out Perm_Array; perm: in Perm_Array); procedure setup_perm(perm: in out Perm_Array); end Perms; package body Perms is procedure do_perm(a: out Perm_Array; perm: in Perm_Array) is begin for i in perm'range loop a(perm(i)) := i; end loop; end do_perm; procedure setup_perm(perm: in out Perm_Array) is begin for i in perm'range loop perm(i) := i; end loop; end setup_perm; end Perms; > 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. Seems not to apply here, but this is just one case. Is there evidence of significant optimization superiority of C in the general case? Georg