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!news1.google.com!newsread.com!news-xfer.newsread.com!tdsnet-transit!newspeer.tds.net!sn-xit-03!sn-xit-08!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: Fri, 11 Mar 2005 01:20:08 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <1132e5g2cor3oe2@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> <112v9p788s1684d@corp.supernews.com> <42307820$0$26539$9b4e6d93@newsread4.arcor-online.net> In-Reply-To: <42307820$0$26539$9b4e6d93@newsread4.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:9098 comp.realtime:1242 comp.software-eng:4810 Date: 2005-03-11T01:20:08-05:00 List-Id: Georg Bauhaus wrote: > Done. You might be disappointed by the results. In short: > < 1%, < 3%; and < 8% for a different program, really. I'm not disappointed at all, in fact the numbers are way worse than I expected, given that you used: > VERY_LARGE_NUMBER: constant := 100_000_000; You're using 800MB of memory, and unless you have at least 1GB, you're probably swapping in and out. Also you're probably trashing your TLB. You're *definitely* thrashing all levels of cache. The other point is that the branch prediction table is primed (i.e. it will always go to the dont-fail case). In a real program, the branch-predictor would mispredict more often. If, after all that, the effects of the check are at all visible, it means that the checks are probably significant. Try again with smaller numbers that yield arrays 1/8 the size of your L1 and 1/4 the size of your L2. E.g., If you've got a 64 KB L1 and a 1MB L2, make VERY_LARGE_NUMBER 1000 and 64000. Call this benchmark repeatedly till you get to a total run-time of about 1sec. I checked; on my machine, if I run the C code below with 100k entries vs 50k entries the performance is 4.7s vs. 0.7s ~ 6.5x slowdown vs 2x change in size [I'm using time under cygwin on a Xeon 3.06GHz dual-processor system]. This indicates that I have a 512KB L2-cache. Now, I added the bounds check. At 50k, there is a 27% slowdown, at 100k there is about a 1% slowdown. You have to be *very* careful that what you're measuring isn't hidden behind some other effect. ---------------------------------------------------------- #define N 50000 void setup_perm( int perm[] ) { int i; for( i = 0; i < N; i++ ) { perm[i] = i; } } void do_perm( int perm[], int val[] ) { int i; for( i = 0; i < N; i++ ) { /* if( perm[i] >= N ) { abort(); } */ val[perm[i]] = i; } } int perm[N]; int val[N]; int main(void) { int i; setup_perm(perm); for( i = 0; i < 10000; i++ ) { do_perm(perm, val); } return 0; }