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 

Suggested additional optimization

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
LitusSaxonicum



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

PostPosted: Sat Mar 17, 2012 3:17 pm    Post subject: Suggested additional optimization Reply with quote

I think that it is possibly worth automatically optimizing source code of the form real**real to real**integer when the exponent is in actual fact an integer.

I have been looking at the Polyhedron benchmark mp_prop_design which is not only the slowest, but the one where FTN95 does worst. The run times are improved around 10% if you do this optimization by hand (there are lots of instances of this, to powers 2, 3, 4 and 5, all of which are coded in the following form (simplified by me):

Code:
beta = alpha**2.0D0


It still doesn't bring the executable anywhere near as fast as the leaders, but it makes a comparatively large difference. On my machine and using the timer in the program, it reduces run times from 10.8 to 9.8 minutes.

I am aware that repeated multiplication can also be quicker than raising to a small power, but do not know where the cutoff happens.

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


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

PostPosted: Sat Mar 17, 2012 8:21 pm    Post subject: Reply with quote

Thanks for the suggestion Eddie but I would be surprised if any compiler would do this. Raising to a real power should imply that the programmer requires a logarithmic process rather than repeated multiplication. Maybe the compiler could provide a warning or a comment but even then testing a real for equality to an integer may not be trivial.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Mon Mar 19, 2012 4:48 pm    Post subject: Reply with quote

Hi Paul,

It (the compiler) doesn't have any problem in knowing that a floating point entity is an integer when it tells me off for testing equality to zero (threads passim)!

In the case of mp_prop_design, the code looks like it was written by a novice, and after passing it through SPAG it loses the nice formatting it had in the original.

I wasn't suggesting checking for say

a**4.00000000001D0

only for a**4.0D0 or a**4.D0 (or the quivalent single precision versions)

and also not a**b where b=4.0D0 either (a run time check).

A programmer who writes a**2.0D0 clearly doesn't intend it to be done one way or another - he/she simply doesn't understand the difference (as in the case of mp_prop_design)! The check would have to be done at source code level, and would require checking (say) for "." or ".0" and possibly stopping there, as more decimal places would, in my view, point to a wish to do it logarithmically.

It isn't a show-stopper for me, as I would always use an integer exponent if I could; or repeated multiplications, especially for 2nd and 3rd powers.

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


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

PostPosted: Mon Mar 19, 2012 5:41 pm    Post subject: Reply with quote

OK. I will see if I can at least provide a warning message for power 2.0.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Thu Mar 22, 2012 6:02 pm    Post subject: Reply with quote

I have found that a number of the Polyhedron benchmarks can be improved substantially for FTN95 with some simple changes, including:
- shifting large local arrays from the stack to static declaration.
- changes to do loop order for sequential memory access.
Their selected FTN95 compilation used a very large stack.

That being said, there must be some substantial optiomisation bias (targeted to the examples) in some of the other compilers to achieve the performance they report. My codes do not perform as bad relatively, as the benchmark examples.
Some of the examples use a small memory, which are better suited to cache optimisation, but the advantage can be lost with larger size problems.
Some of my code show very poor cacheing with FTN95, especially when working backwards through a large array.

New vector instructions also appear to work well for the other compilers.

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



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

PostPosted: Thu Mar 22, 2012 10:12 pm    Post subject: Reply with quote

John,

Other business interrupted me exploring these issues, so thanks for highlighting them. The last time I spent some time on the benchmarks I did wonder if running SPAG on them worsened FTN95's performance, but on reflection I think it is more in the programming styles of the benchmarks themselves.

The issue of performance of the two leading compilers (in speed terms) on the Polyhedron benchmarks comes up again and again in their support forums - so I agree that there could be optimization to suit the benchmarks. However, I agree with you that I have no complaints about the speed in my applications. However, I was appalled to find the mp_prop_design taking over 10 minutes, as the application doesn't look as if it does anything particularly complex.

I wonder if FTN95 doesn't optimize as aggressively as other compilers as a historical relic from the time when FTN77/DBOS was a speed leader?

It would be useful to have a consolidated list of hand optimizations and programming style hints for speed with FTN95. I'm not surprised that a Fortran 77 style runs faster than a more modern style, or am I just predjudiced?

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 -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
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