I have an idea. I noticed that bringing N down to 10 and stripping all the printf's (extremely bad for loop optimisation!) it really flies:
Code:
irene /tmp> cc -n32 -Ofast=ip28 -r10000 -mips4 -o loop loop.c
irene /tmp> time loop
pixel 0,0 195fe0 pixel xmax,ymax 195fe0
0.127u 0.061s 0:00.27 66.6% 0+0k 0+0io 0pf+0w
I have added those pixel printf's at the end, otherwise the compiler decides that nothing get's done with the result, so it might optimise the whole loop, by throwing it away. heheh
Good, now increase N by 2 and watch what happens:
Code:
N=10
pixel 0,0 195fe0 pixel xmax,ymax 195fe0
0.127u 0.061s 0:00.27 66.6% 0+0k 0+0io 0pf+0w
N=12
pixel 0,0 8b894f pixel xmax,ymax 8b894f
0.143u 0.061s 0:00.29 68.9% 0+0k 0+0io 0pf+0w
N=14
pixel 0,0 2ff50b4 pixel xmax,ymax 2ff50b4
0.160u 0.064s 0:00.29 75.8% 0+0k 0+0io 0pf+0w
N=16
pixel 0,0 107b7cc0 pixel xmax,ymax 107b7cc0
0.177u 0.064s 0:00.37 62.1% 0+0k 0+0io 0pf+0w
N=18
pixel 0,0 5aa31180 pixel xmax,ymax 5aa31180
0.193u 0.065s 0:00.45 55.5% 0+0k 0+0io 0pf+0w
N=20
pixel 0,0 7fffffff pixel xmax,ymax 7fffffff
1.189u 3.528s 0:06.67 70.4% 0+0k 0+0io 0pf+0w
Kablam! Integer overflow. That will cost you deerly. Now if you change the pixel array to float instead of int and remove the casts, it performs much better:
Code:
N=20
pixel 0,0 8367358464.000000 pixel xmax,ymax 8367358464.000000
0.083u 0.063s 0:00.20 70.0% 0+0k 0+0io 0pf+0w
You still have to do something about your results going to infinity and apply some sort of so-called clamping of the pixel array, cause you only want a restricted range of colors to display, right?
This advice ofcourse doesn't come cheap
I'll expect that Onyx2 on my doorstep tomorrow, okay
Login
Register
FAQ
Search
)
