public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/52537] New: slow trim function
@ 2012-03-09  8:48 talebi.hossein at gmail dot com
  2012-03-09  9:14 ` [Bug libfortran/52537] " burnus at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: talebi.hossein at gmail dot com @ 2012-03-09  8:48 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

             Bug #: 52537
           Summary: slow trim function
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: talebi.hossein@gmail.com


Hello,

The trim function in Gfortran seems to be a a lot slower than the intel
compiler. Sometimes I have to read some input text files which can very
large(1.5GB); Comparing the intel and gfortran, the gfortran takes 150 seconds
where intel spends only 50 seconds. I checked, and there seems to a large time
spend on the trim function. 

I am not sure if intel does some other optimization but I never got such huge
performance difference between gfortran and ifort.

Thank you.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
@ 2012-03-09  9:14 ` burnus at gcc dot gnu.org
  2012-03-11  7:51 ` tkoenig at gcc dot gnu.org
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-09  9:14 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jb at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-09 09:14:00 UTC ---
Some related bugs: PR 47065, PR 50673, PR 38199.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
  2012-03-09  9:14 ` [Bug libfortran/52537] " burnus at gcc dot gnu.org
@ 2012-03-11  7:51 ` tkoenig at gcc dot gnu.org
  2012-03-11 17:19 ` tkoenig at gcc dot gnu.org
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-03-11  7:51 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-03-11 07:50:17 UTC ---
Hi,

can you attach a self-contained example?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
  2012-03-09  9:14 ` [Bug libfortran/52537] " burnus at gcc dot gnu.org
  2012-03-11  7:51 ` tkoenig at gcc dot gnu.org
@ 2012-03-11 17:19 ` tkoenig at gcc dot gnu.org
  2012-03-11 17:28 ` talebi.hossein at gmail dot com
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-03-11 17:19 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-03-11
     Ever Confirmed|0                           |1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (2 preceding siblings ...)
  2012-03-11 17:19 ` tkoenig at gcc dot gnu.org
@ 2012-03-11 17:28 ` talebi.hossein at gmail dot com
  2012-04-12 10:47 ` tkoenig at gcc dot gnu.org
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: talebi.hossein at gmail dot com @ 2012-03-11 17:28 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #3 from Hossein Talebi <talebi.hossein at gmail dot com> 2012-03-11 17:27:42 UTC ---
Hello,

Hummm, a self contained example... That will be possible when I go back to the
office. I can also check it myself with a simpler example. For now, maybe you
can figure out something from this subroutine. I can probably write this
subroutine in another way to make it faster. But, the question still is, why
intel does the same thing much faster.  

!==============================================================================
subroutine
femmesh_input_elements(this,funit,nelem,max_connectivity,fname,reflag,element_format)

!attention: here the Proc0 reads and distributes to other
! procs. also, the profiling is done here partially
! for the number of element and so on. The format of saving
! element connectivities is done according to METIS to make
! it easier to distribute the elements.

    use strings
    !------------------- INOUT variables------------------
    class(ty_femmesh) :: this
    type(ty_element_format) :: element_format

    integer,intent(in) :: funit
    character(*) :: fname, reflag

    integer :: nelem,max_connectivity, linenum
    integer  :: j,ferror, ios,i
    character (len=1200) :: st_input

    integer :: maxc,funit2, buf_siz,iprc, ierror
    integer, allocatable :: ELEMENTS_buf(:,:)
    integer :: I50(0:50)
    character(1200) :: pcommand
    integer mstatus(MPI_STATUS_SIZE), tag, G_elid, elid, ipr, eltab,nn , pEidf,
pEconnf,pEmatidf

    funit2=funit
    linenum=0; ferror=0; eltab=0
    this%max_connect=element_format%max_connectivity
    this%max_Eltab=MIN_TABS+this%max_connect

    pEidf=element_format%pEidf
    pEconnf=element_format%pEconnf
    pEmatidf=element_format%pEmatidf

! distribute the initial mesh to the processors so every processor knows
! what element it will get. The last element gets the remaining of the elements
+ its share

    this%numElements= int( nelem / this%femcomm%nprocs)

    if (this%femcomm%me == this%femcomm%nprocs-1) then
        if (this%femcomm%me == this%femcomm%nprocs-1)
this%numElements=this%numElements+ mod(nelem,this%femcomm%nprocs)
    endif

    this%femcomm%elemdist(1)=1

    !make elemdist and numEl_pp
    do i=1, this%femcomm%nprocs
        this%femcomm%elemdist(i+1) =this%femcomm%elemdist(i)+ int( nelem /
this%femcomm%nprocs)
        this%femcomm%numEl_pp(i)=int( nelem / this%femcomm%nprocs)
    enddo
    this%femcomm%elemdist(this%femcomm%nprocs+1) =
this%femcomm%elemdist(this%femcomm%nprocs+1)+ mod(nelem,this%femcomm%nprocs)
    this%femcomm%numEl_pp(this%femcomm%nprocs) =
this%femcomm%numEl_pp(this%femcomm%nprocs)+ mod(nelem,this%femcomm%nprocs)

    !preparing the buffer to send and recieve elements
    buf_siz=this%femcomm%numEl_pp(this%femcomm%nprocs) +1

    eltab=2+max_connectivity
    Call allocate_I2d(this%Elements_input,eltab,buf_siz)
    Call allocate_I2d(ELEMENTS_buf,eltab,buf_siz)
    Call allocate_I2d(this%Elements, this%max_Eltab ,this%numElements)

    Call MPI_BARRIER(this%femcomm%femworld,ierror)

    tag = 1; G_elid=0 ;I50=0

    if (this%femcomm%me .eq. 0) then

        if (trim(element_format%fname) /= '') then
            if (element_format%reflag=='txt') then
                funit2=openfile_txt(element_format%fname)
            else
                Call this%error%universe_one('femmesh_input_elements: I am not
able to read this type of element file')
            endif
        endif

        ELEMENTS_buf=0

        do ipr=0, this%femcomm%nprocs -1
          j=0;
          do
            read (funit2,"(A200)",iostat=ferror) st_input

            if (ferror < 0) then
                call this%error%universe_one("femmesh_input_elements:
unexpected end of the file")
            endif
            call compact(st_input)
            if (trim(st_input)=='' .or.  st_input(1:1)=='#') then
                cycle
            endif

            j=j+1
            linenum=linenum+1
            read (st_input,*,IOSTAT=ios) I50(1:50)
            I50(0)=1 !set the zero index as 1, which sets all the unset values
1
            elid=I50(1)
            G_elid=G_elid+1
            if (G_elid /=elid) then
                print *,st_input
                call this%error%universe_one("femmesh_input_elements: Bad
element numbering or number "// &
                        " of elements or element format")
            endif
            !ELEMENTS_buf(1:eltab,j)=I50(1:eltab)
            ELEMENTS_buf(1,j)=I50(pEidf)
            ELEMENTS_buf(2,j)=I50(pEmatidf)
            ELEMENTS_buf(3:3+max_connectivity-1
,j)=I50(pEconnf:pEconnf+max_connectivity-1)

            I50=0
            if (j >= this%femcomm%numEl_pp(ipr+1)) exit
          enddo
          if (ipr ==0) then
            this%Elements_input=ELEMENTS_buf
          else
            call MPI_SEND(ELEMENTS_buf, eltab*buf_siz, MPI_INTEGER, ipr, tag,
this%femcomm%femworld, ierror)
          endif
      enddo

    else
        call MPI_RECV(ELEMENTS_buf, eltab*buf_siz, MPI_INTEGER, 0, tag,
this%femcomm%femworld, mstatus, ierror)
        this%Elements_input=ELEMENTS_buf
    endif

    !mode all the data to ELements
    do i=1,this%numElements
        do nn=3, eltab
            if ( (this%Elements_input(nn,i)==0) .or.
(this%Elements_input(nn,i)==this%Elements_input(nn-1,i) ) &
            .and. (nn .ne. 3) ) Exit
            this%Elements(pEconn+nn-3,i)=this%Elements_input(nn,i)
        enddo
        this%Elements(pEid,i)=this%Elements_input(1,i)
        this%Elements(pEmatid,i)=this%Elements_input(2,i)
        this%Elements(pEnnode,i)=nn-3
    enddo

    deallocate(this%Elements_input) !nullify the Elements_input, but maybe
later it can be of use
    call this%error%info("Reading Elements finished")


end subroutine femmesh_input_elements


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (3 preceding siblings ...)
  2012-03-11 17:28 ` talebi.hossein at gmail dot com
@ 2012-04-12 10:47 ` tkoenig at gcc dot gnu.org
  2012-05-11 14:16 ` tkoenig at gcc dot gnu.org
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-04-12 10:47 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-04-12 10:47:36 UTC ---
For this particular case,

if (trim(a) == '') 

could be simplified to

if (len_trim(a) == 0)

Probably best done via front-end optimization.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (4 preceding siblings ...)
  2012-04-12 10:47 ` tkoenig at gcc dot gnu.org
@ 2012-05-11 14:16 ` tkoenig at gcc dot gnu.org
  2012-05-11 19:06 ` tkoenig at gcc dot gnu.org
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-05-11 14:16 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-05-11 13:56:16 UTC ---
Author: tkoenig
Date: Fri May 11 13:56:06 2012
New Revision: 187406

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187406
Log:
2012-05-11  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/52537
    * frontend-passes.c (optimize_op):  Change
    old-style comparison operators to new-style, simplify
    switch as a result.
    (empty_string):  New function.
    (get_len_trim_call):  New function.
    (optimize_comparison):  If comparing to an empty string,
    use comparison of len_trim to zero.
    Use new-style comparison operators only.
    (optimize_trim):  Use get_len_trim_call.

2012-05-11  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/52537
    * gfortran.dg/string_compare_4.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/string_compare_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/testsuite/ChangeLog


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (5 preceding siblings ...)
  2012-05-11 14:16 ` tkoenig at gcc dot gnu.org
@ 2012-05-11 19:06 ` tkoenig at gcc dot gnu.org
  2012-05-11 19:17 ` tkoenig at gcc dot gnu.org
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-05-11 19:06 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-05-11 18:50:27 UTC ---
Author: tkoenig
Date: Fri May 11 18:50:14 2012
New Revision: 187413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187413
Log:
2012-05-11  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/52537
    * gfortran.dg/string_compare_4.f90:  Change option
    to -fdump-tree-original.  Add test case for kind=4.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/string_compare_4.f90


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (6 preceding siblings ...)
  2012-05-11 19:06 ` tkoenig at gcc dot gnu.org
@ 2012-05-11 19:17 ` tkoenig at gcc dot gnu.org
  2012-06-07 14:51 ` tkoenig at gcc dot gnu.org
  2012-06-07 16:03 ` talebi.hossein at gmail dot com
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-05-11 19:17 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-05-11 19:16:08 UTC ---
Does this fix the problem?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (7 preceding siblings ...)
  2012-05-11 19:17 ` tkoenig at gcc dot gnu.org
@ 2012-06-07 14:51 ` tkoenig at gcc dot gnu.org
  2012-06-07 16:03 ` talebi.hossein at gmail dot com
  9 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-06-07 14:51 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-06-07 14:51:00 UTC ---
I think this is fixed.  Please reopen if there
is an issue that is still problematic.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug libfortran/52537] slow trim function
  2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
                   ` (8 preceding siblings ...)
  2012-06-07 14:51 ` tkoenig at gcc dot gnu.org
@ 2012-06-07 16:03 ` talebi.hossein at gmail dot com
  9 siblings, 0 replies; 11+ messages in thread
From: talebi.hossein at gmail dot com @ 2012-06-07 16:03 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

--- Comment #9 from Hossein Talebi <talebi.hossein at gmail dot com> 2012-06-07 16:03:09 UTC ---
I think I found where the problem is. It is not with the trim(). It is mostly
with read (st_input_all(j),*,IOSTAT=ios) I50(1:50).

I attach a self contained program. With intel it takes 11sec but for gfortran
takes 40sec. The input file is 404MB.



program fileread

    integer :: linenum
    integer  :: j,ferror, ios,i
    character (len=200) :: st_input
    character (len=200) :: st_input_all(5373122)
    integer :: funit2
    integer :: I50(0:50)
    integer   G_elid, nn !, pEidf, pEconnf,pEmatidf
    integer, allocatable :: element_tab(:), Elements(:,:)

    linenum=0; ferror=0;
    open (funit2, file = "/data/msh/bigmesh.elements", access =
'sequential',iostat=ferror)

    if (ferror/=0) then
        STOP "error reading the file"
    endif

    print *, "reading the file..."

    G_elid=0
    do j=1,5373122
        read (funit2,"(A200)",iostat=ferror) st_input_all(j)
        if (G_elid== 5373121 ) then
            print *,  st_input_all(j)
        endif        
    enddo

    G_elid=0
    do j=1,5373122
        G_elid=G_elid+1
        read (st_input_all(j),*,IOSTAT=ios) I50(1:50)
        if (G_elid== 5373121 ) then
            print *,  I50
        endif
    enddo

    close(funit2)
    print *, I50
    STOP "permix I am stopped"

end program fileread


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-06-07 16:03 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-09  8:48 [Bug libfortran/52537] New: slow trim function talebi.hossein at gmail dot com
2012-03-09  9:14 ` [Bug libfortran/52537] " burnus at gcc dot gnu.org
2012-03-11  7:51 ` tkoenig at gcc dot gnu.org
2012-03-11 17:19 ` tkoenig at gcc dot gnu.org
2012-03-11 17:28 ` talebi.hossein at gmail dot com
2012-04-12 10:47 ` tkoenig at gcc dot gnu.org
2012-05-11 14:16 ` tkoenig at gcc dot gnu.org
2012-05-11 19:06 ` tkoenig at gcc dot gnu.org
2012-05-11 19:17 ` tkoenig at gcc dot gnu.org
2012-06-07 14:51 ` tkoenig at gcc dot gnu.org
2012-06-07 16:03 ` talebi.hossein at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).