forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Fortran 2003/2008
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 1929
Location: South Pole, Antarctica

PostPosted: Tue Oct 29, 2013 12:57 pm    Post subject: Reply with quote

Yes, date and time are correct
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Tue Nov 05, 2013 1:36 pm    Post subject: Reply with quote

Dan,

I have created a timing module (library) which contains routines that use most of the timing routines I have used with FTN95. I have copied it to dropbox. It includes estimates of calling time penalty and also the precision of the timers.
The approach I have taken is to provide 3 functions to interface each timer, being:
integer*8 function timer_tick () ! which returns the number of ticks
integer*8 function timer_frequency () ! which returns ticks per second
real*8 function timer_sec () ! which returns the seconds

For elapsed time, CPU_CLOCK@ and QueryPerformanceCounter perform well.
Most other timers perform very poorly, as their value is updated 64 times per second. This included all estimates of processor time. It is important to understand that all timers have an update frequency, which is different from the tick rate and those with an update frequency of 64 cycles per second are not worth using. This includes the intrinsics CPU_TIME, Date_and_Time and Salford's DCLOCK@.

My preference is to use CPU_CLOCK@ and ignore the warning message, as I have never experienced the problem reported.
I have provided a routine to calculate the clock rate for cpu_clock@, which runs fairly quickly ( < .001 seconds).

John


https://www.dropbox.com/s/yvsck1xysec4crm/timing_routines.f90
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1929
Location: South Pole, Antarctica

PostPosted: Wed Nov 06, 2013 10:54 pm    Post subject: Reply with quote

Would be good to check these timers with my parallel library, which might mess something but I'm out of place right now. Want to try yourself?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Mon Nov 11, 2013 12:02 am    Post subject: Reply with quote

Dan,

Email me the links to the library etc and I'll give it a test.
I don't think I have the libraries you are refering to.

John
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1095

PostPosted: Mon Feb 16, 2015 4:27 am    Post subject: Re: Reply with quote

DavidB,

Thanks for contributing the fast_asm_ddotprod code. I had occasion to look at it as part of John Campbell's code, where he experienced huge slowdowns caused by similar routines compiled from Fortran code.

Here is a minor tweak to take care of the part where you wrote
Code:
 Can't get final reduction to work, so will do this in Fortran for now
  80  movupd v, xmm0%            ; move xmm0 to v array
   edoc
   
   ! Final reduction, the result is the sum of the two values in v
   fast_asm_ddotprod = sum(v)

end function fast_asm_ddotprod

The change, which will not really affect the speed much, but make your code "clean SSE", is as follows:
Code:

  80    movaps   xmm1,xmm0
        unpckhpd xmm1,xmm0
        addsd    xmm0,xmm1
        movsd    v,xmm0
   edoc
   
   fast_asm_ddotprod = v

end function fast_asm_ddotprod

The declaration of the local variable v should be changed to REAL*8 v.
Unfortunately, FTN95 does not know the instruction unpckhpd, so instead of inline assembler one may (i) produce an obj file from your original code, (ii) dumpbin /disasm > asm file, (iii) edit file and make the changes indicated above, (iv) assemble the asm file.

Perhaps you felt all this was not worth the trouble, and that is what you meant by "cannot get ... to work".


Last edited by mecej4 on Mon Feb 16, 2015 2:07 pm; edited 1 time in total
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 554
Location: UK

PostPosted: Mon Feb 16, 2015 9:12 am    Post subject: Reply with quote

When I found that the assembly code I needed (unpckhpd) wasn't included in the FTN95 inline assembler I just fell back on using Fortran as I felt it was easier (Paul did look into adding support for unpckhpd and others but found it was not trivial so it wasn't pursued).

Your solution is better but requires more work to get a working subroutine. It probably does not make much difference in terms of efficiency.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1929
Location: South Pole, Antarctica

PostPosted: Mon Apr 09, 2018 10:25 am    Post subject: Reply with quote

How about 64bit Vec_Add_SSE and Vec_Sum_SSE previously written in assembler for 32bits ? Anyone try to use FTN95 own or have done own 64bit version?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Mon Apr 09, 2018 1:21 pm    Post subject: Reply with quote

Dan,

The 64-bit routines work well and provide vector instruction speed-up.
For real*8, I have used:
Code:
 real*8 function Vec_Sum_SSE ( a, b, n )
!
!   Performs the vector opperation  Vec_Sum_DO = [a] . [b]

    integer*4 n
    real*8    a(n), b(n), s
!
    integer*8 n8
    real*8    DOT_PRODUCT8@
    external  DOT_PRODUCT8@
!
    if (n > 1) then
       n8 = n
       s = DOT_PRODUCT8@ (a, b, n8 )
    else if (n==1) then
       s = a(1) * b(1)
    else
       s = 0
    end if
!
   vec_sum_SSE = s

 end function vec_sum_SSE

 subroutine Vec_add_SSE ( Y, X, a, n )
!
!   Performs the vector operation  [Y] = [Y] + a * [X]
!
   integer*4 n
   real*8    Y(n), X(n), a
   integer*8 n8
!
     if ( n > 1 ) then
!       Y = Y + a * X
       n8 = n
       call AXPY8@ (y, x, n8, a)

     else if ( n == 1 ) then
       Y(1) = Y(1) + a * X(1)

     end if

 end subroutine Vec_add_SSE


note: integer*8 n8
check the 64 bit documentation for other routines.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1929
Location: South Pole, Antarctica

PostPosted: Tue Apr 10, 2018 6:02 am    Post subject: Reply with quote

Cool, thanks John,
I owe you !
And great job, Silverfrost
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Thu Apr 18, 2019 9:32 am    Post subject: Reply with quote

Paul,

Somewhere I suggested I would post a list of additions to FTN95 to include some features of F03 and F08 that are hopefully "easier" to include.
Supporting F03 and F08 syntax can be helpful for compatibility with other Fortran environments.

This is my limited list:-

I have reviewed the F03 and F08 changes and have listed some changes which I think could be introduced.

1) New system routines (some already supported)

F2003 routines
COMMAND_ARGUMENT_COUNT
GET_COMMAND
GET_COMMAND_ARGUMENT
GET_ENVIRONMENT_VARIABLE

F2008 routines
Compiler_Version
Compiler_Options
Execute_command_Line
Leadz
Trailz
Storage_size

2) Changes to I/O to support new standardised syntax
IOMSG=
NEWUNIT=
*(..) unlimited format item
Support for stream I/O syntax (in conjunction with TRANSPARENT, such as positioning)

3) Support for ISO_FORTRAN_ENV module for features available in F95

The main outstanding problem I see is support for Integer constants as subroutine arguments, especially Integer*8 constants, eg 999_8 for an 8-byte integer and 999_4 for a 4-byte integer are not portable

These suggested changes omit any new code structures, which I anticipate would be more complex.

I hope this is a realistic list and would be easily achieved.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Thu Apr 18, 2019 10:13 am    Post subject: Reply with quote

John

Thank you for the feedback.

The following items are already available or have been added for the next release.

COMMAND_ARGUMENT_COUNT
GET_COMMAND
GET_COMMAND_ARGUMENT
GET_ENVIRONMENT_VARIABLE
EXECUTE_COMMAND_LINE

IOMSG=

Integer constants should already work correctly although the native KIND values are different. For example, by default 999_4 represents 999 as a 64 bit integer constant. For portability you can use 999_k where k is calculated via a call to SELECTED_INT_KIND. Alternatively the command line option /ALT_KINDS provides for KIND values based on byte size.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Sun Apr 21, 2019 4:30 am    Post subject: Reply with quote

Paul,

I would like to make recommendations of how FTN95 can better support KIND values, especially constants, although my past recommendations for non-standard extensions have not worked well, eg SIZE for /64.

FTN95 now supports two concepts for KIND. It would be good if they could be merged, with FTN95 supporting both concepts, without compile options. It remains how to treat the conflicts, which is mainly 11_4 or "integer(4) :: I"

For REAL, a non-standard extension should have little side effects.
I suggest that kind values of 1,2,3 and 4,8,10 all be accepted, so that 2.0_4 and 2.0_1 are both seen as a 4-byte real. I don't think FTN95 supports REAL*16, so there should not be any confusion with kind = 4.

For INTEGER, there is significant confusion with kind = 4 (and =3), while kind values of 1,2,3 and 8 are not in dispute. Kind = 7 is a useful although non-portable introduction. However, providing 11_4 as an 8-byte constant would work as a subroutine argument. There can be problems providing an 8-byte constant for some intrinsic functions, such as TRANSFER. I would recommend providing a warning for use of integer kind=4 constants, as with the warning of comparing 2 real values for equality.

I can not provide recommendations for COMPLEX as I am not familiar with their use. (Can someone who knows, recommend how to handle the complex*8 vs complex(8) problem, again with a warning perhaps?)

This approach can be useful, when using some 3rd party software that it can be used without modifying the code. I do this in Plato on a regular basis. (access to modifying the default X64/Win32 and Checkmate/Debug/Release compile options in PLATO would also be a useful addition).
Also, the use of 8-byte integer constants in a concise and portable way is always annoying.

In summary, it would be good if an extended set of kind values could be recognised by the FTN95 compiler with minimal complaint, especially where there should be no confusion as to what is extended. The real values of 4,8,16 and integer values of 1,2,4,8 are becoming an increasingly used, but nonstandard / not recommended approach.

Any other opinions before this might be implemented ?

John
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1974
Location: Yateley, Hants, UK

PostPosted: Sun Apr 21, 2019 10:28 am    Post subject: Reply with quote

Quote:
Also, the use of 8-byte integer constants in a concise and portable way is always annoying.


Is there a directive similar to INTS and INTL? Compile time options are all very well, but one can forget to apply them. OPTIONS, on the other hand, is embedded in the source code. (Remembering, of course, that once like me you have invested heavily in Clearwin+, there aren't really any alternative compilers ...)

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Mon Apr 22, 2019 8:10 am    Post subject: Reply with quote

John

Your suggestion that FTN95 ought to accept all unambiguous KIND values is worth considering. There is only one ambiguous value (integer kind=4) at the moment and only one that I can think of (real kind=4) that could conceivably be ambiguous in the future. Logical kind=4 is like integer kind=4.

So how does one deal with kind=4 and should unambiguous values be accepted?

Eddie

Any of the compiler options INTS, INTL, DREAL, XREAL and ALT_KINDS can appear in an OPTIONS directive. INTL was inherited from FTN77 and sets the default integer kind to 32 bit integers. This is the default for FTN95.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1974
Location: Yateley, Hants, UK

PostPosted: Mon Apr 22, 2019 2:41 pm    Post subject: Reply with quote

Paul,

Thanks.I realised that INTL (INTEGER*4) was the default for FTN95 32-bit. Is INTEGER*8 the default for 64 bit, especially for constants? I suspect not.

FTN95 is rather intelligent, so that writing:

Code:
      PROGRAM IntLongLong
      INTEGER*8 I
      I = 9223372036854775807
      WRITE(*,'(I24)') I
      END


simply gives one the rather clever warning:

WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to INTEGER(KIND=4)

The correct answer is output.

The same warning is given in 32 bit AND 64 bit modes, so I suspect that the default for constants is normally INTEGER*4.

Not to be unKIND, but KIND seems to me to be a way of imposing chaos, not removing it.

Eddie
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 9 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group