1 |
On Tuesday 31 January 2012 19:58:32 Anthony G. Basile wrote: |
2 |
> On 01/29/2012 02:14 PM, Mike Frysinger wrote: |
3 |
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote: |
4 |
> >> I've run nbench on two amd64 systems both running the same kernel |
5 |
> >> vanilla-3.2.2. |
6 |
> > |
7 |
> > i don't think nbench is a good benchmark for this as it isn't really |
8 |
> > testing what you think it's testing. it's very good at validating math |
9 |
> > support in the ISA/ABI, optimized compiler output, and supplementary |
10 |
> > math implementations in libgcc. PIE vs non-PIE will still be able to |
11 |
> > multiply/divide in pretty much the same amount of time. |
12 |
> |
13 |
> I know, but the problem is, what benchmark best approximates common |
14 |
> every day use? So I wrote the following which really hits the problem |
15 |
> hard on x86: |
16 |
> |
17 |
> int modfac(int n) |
18 |
> { |
19 |
> if(n==0) return 1; |
20 |
> return n * modfac(n-1); |
21 |
> } |
22 |
> |
23 |
> int main() |
24 |
> { |
25 |
> int i; |
26 |
> for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096); |
27 |
> return 0; |
28 |
> } |
29 |
> |
30 |
> Using vanilla kernel 3.2.2, userland built with vanilla toolchain, |
31 |
> gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code |
32 |
> simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get: |
33 |
> |
34 |
> time -p ./test |
35 |
> real 327.89 |
36 |
> user 327.72 |
37 |
> sys 0.00 |
38 |
> |
39 |
> Keep everything else the same, even the same hardware, but switch to |
40 |
> userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus |
41 |
> error), I get: |
42 |
> |
43 |
> time -p ./test |
44 |
> real 629.68 |
45 |
> user 629.37 |
46 |
> sys 0.00 |
47 |
> |
48 |
> The hardware is 8 x "Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz" with 12 GB |
49 |
> ram. That's nearly a factor of 2x but how often does one set up 4k |
50 |
> stack frames in everyday use? |
51 |
|
52 |
you mean how often do people do recursion on data sets ? is that 2x slow down |
53 |
really because of the *depth* of the stack ? |
54 |
-mike |