--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-04-15 00:35
---
I think this can be closed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-04-11 13:07
---
Dominique, thanks for testing. You are not getting near the same speedup I am.
It must be related to cache size. I will submit the patch for approval some
time in the next few days.
--
http://gcc.gnu.org/
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-11 08:26 ---
> + /* If we can successfully get an array element at the max array size then
s/can/cannot/ ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-11 08:11 ---
With the patch in comment #9 applied to the fortran-exp branch, the timing for
the original test is slightly slower than trunk ~250s compared to ~240s.
Note that the procedure node_copy_and_append should be deleted
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-04-11 06:44
---
Created an attachment (id=20360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20360&action=view)
patch for fortran-exp branch
Please test on fortran-exp branch.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-04-11 06:38
---
Restoring the size check to gfortran-exp branch I get the following results
with the test case in comment #1.
Current trunk (4.6):
$ time gfc pr34554.f90
real8m26.965s
user8m21.252s
sys 0m2.477s
$ .
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-04-11 01:49
---
I have an idea.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-04-10 15:50 ---
(In reply to comment #5)
> I will start looking at this. Daniel, any ideas?
I'd think that the fortran-exp branch tries to unroll the whole thing, which
then doesn't fit into memory any more at some point. Hence the
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-04-10 15:41
---
The fortran-exp branch has a performance regression with these test cases.
Trunk is slow to compile it, but does succeed. The branch can not even get
close to it.
I will start looking at this. Daniel, any ideas?
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-03 22:11 ---
array.c (gfc_get_array_element) states:
"Access is not efficient at all, but this is another place where things do not
have to be particularly fast."
As get_array_element shows up in #2, this might be a place to sta
--- 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
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-12-22 12:18 ---
For reference: iv1 = 135210384
A typical backtrace:
#0 0xb7f0c82e in __gmpz_sub_ui () from /usr/lib/libgmp.so.3
#1 0x08050dce in expand_constructor (c=0x89b9280)
at ../../../gcc/gcc/fortran/array.c:1330
#2 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-22 11:44 ---
Isn't this the same as PR 20923 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
13 matches
Mail list logo
