Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Nils M Holm <news2009@t3x.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Odd benchmark behavior |
| Date | 2012-03-27 06:20 +0000 |
| Organization | TARFU |
| Message-ID | <9td4i1FvsgU1@mid.individual.net> (permalink) |
| References | <9talg3F84gU1@mid.individual.net> <jkptnr$j8a$1@dont-email.me> |
BartC <bc@freeuk.com> wrote:
> I suspect the % operation (which needs a divide) dominates the proceedings.
> I put in an extra dummy % op, and it nearly doubled the runtime (3.5 to 6.6
> seconds).
Yes, division is certainly an expensive operation, but I like your
initial guess better (memory access dominates the results). So I
rewrote the program slightly to give the optimizer a chance to do
better register allocation and voila:
scc p2.c: 30s
gcc -O2 p2.c: 15s
Here is the new program (using an even more brute-force algorithm):
----------------------------------------------------------------
#include <stdio.h>
#define MAX 10000
main() {
int i, j, k, n;
for (k=0, i=3; k<MAX; i+=2) {
for (j=2; j<i/2; j++)
if (i % j == 0)
break;
if (j < k) continue;
n = i;
k++;
}
printf("%d\n", n);
}
----------------------------------------------------------------
I also tried a dummy remainder and it indeed doubled the run time
of the SCC-generated executable while the GCC-generated executable
was not affected. I guess that GCC simply removes the dead code.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Odd benchmark behavior Nils M Holm <news2009@t3x.org> - 2012-03-26 07:51 +0000
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-26 11:26 +0200
Re: Odd benchmark behavior "BartC" <bc@freeuk.com> - 2012-03-26 10:40 +0100
Re: Odd benchmark behavior gwowen <gwowen@gmail.com> - 2012-03-26 03:37 -0700
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-26 14:13 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-26 11:55 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-27 09:17 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-27 09:20 +0200
Re: Odd benchmark behavior "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-03-27 13:39 -0400
Re: Odd benchmark behavior pete <pfiland@mindspring.com> - 2012-03-27 21:49 -0500
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-04-05 12:18 +0200
Re: Odd benchmark behavior pete <pfiland@mindspring.com> - 2012-04-05 06:48 -0400
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-04-05 14:12 +0200
Re: Odd benchmark behavior pete <pfiland@mindspring.com> - 2012-04-05 09:03 -0400
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-04-05 16:18 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-04-07 13:26 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-04-06 09:31 +0200
Re: Odd benchmark behavior "io_x" <a@b.c.invalid> - 2012-03-27 19:01 +0200
Re: Odd benchmark behavior "BartC" <bc@freeuk.com> - 2012-03-26 10:36 +0100
Re: Odd benchmark behavior Nils M Holm <news2009@t3x.org> - 2012-03-26 10:02 +0000
Re: Odd benchmark behavior Ian Collins <ian-news@hotmail.com> - 2012-03-26 22:58 +1300
Re: Odd benchmark behavior "BartC" <bc@freeuk.com> - 2012-03-26 15:16 +0100
Re: Odd benchmark behavior Nils M Holm <news2009@t3x.org> - 2012-03-27 06:20 +0000
Re: Odd benchmark behavior "BartC" <bc@freeuk.com> - 2012-03-27 10:13 +0100
Re: Odd benchmark behavior Nils M Holm <news2009@t3x.org> - 2012-03-27 11:59 +0000
csiph-web