------- Comment #3 from dominiq at lps dot ens dot fr 2008-09-14 19:09 -------
On a Core2 2.1Ghz, the original code gives
[ibook-dhum] f90/bug% time gfc pr34554.f90
193.792u 0.273s 3:14.46 99.7% 0+0k 0+27io 0pf+0w
[ibook-dhum] f90/bug% time a.out
152 135210384
0.000u 0.001s 0:00.00 0.0% 0+0k 0+2io 0pf+0w
The following code where the PARAMETERs have been removed
program sum_f95
implicit none
integer i, j
integer n, iv1
n = 152
iv1 = size([([('',i=1,j**3)],j=1,n)])
write(*,*) n, iv1
end program sum_f95
gives
[ibook-dhum] f90/bug% time gfc pr34554_2_db.f90
0.027u 0.022s 0:00.08 50.0% 0+0k 0+15io 0pf+0w
[ibook-dhum] f90/bug% time a.out
152 135210384
0.745u 0.637s 0:01.38 99.2% 0+0k 0+0io 0pf+0w
So using parameters give a runtime speedup at the expense of a very long
compilation time. However is it reasonable that the computation of
size([([('',i=1,j**3)],j=1,n)]) be almost 200 times slower when done by the
compiler?
For the original test, the compile times for different n are
n=52
2.736u 0.024s 0:02.76 99.6% 0+0k 0+26io 0pf+0w
n=102
39.522u 0.079s 0:39.79 99.4% 0+0k 0+12io 0pf+0w
n=152
193.792u 0.273s 3:14.46 99.7% 0+0k 0+27io 0pf+0w
So the compilation time is O(n^4).
For the second test, the runtimes are
n=52
0.013u 0.011s 0:00.02 100.0% 0+0k 0+0io 0pf+0w
n=102
0.155u 0.139s 0:00.29 96.5% 0+0k 0+0io 0pf+0w
n=152
0.745u 0.637s 0:01.38 99.2% 0+0k 0+0io 0pf+0w
So the execution time is also O(n^4), but the prefactor is two order of
magnitude larger at compile time (it means that you have to run the same code
200 times to have a real benefit on the total compile+execution time).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
