History of Salford and Silverfrost

John,

Thanks for bringing this thread to light.

To comment on 'I don't believe the Polyhedron benchmarks either, on a 64bit machine a 32bit silverfrost compiled program easily out performs a full 64bit gfortran version on a numerically intensive task.'

I have not found the 64-bit .exe perform any slower than their 32-bit equivalent. There are a number of aspects of 64-bit that usually make them faster.

FTN95 performance in Polyhedron benchmarks is an interesting topic. I have actually looked into a few of the tests and used /timing to find where FTN95 is going slow. Typically the cause is bad coding approaches in the tests that FTN95 does not optimise. Things like x2.0d0; I just changed it to x2 or x*x and the run times reduced substantially. Poor memory management and Stack usage is another common problem. I suspect that other compilers perform much better as they have included optimisation that targets the specific bad coding identified in the tests. Not much good for those who do not use these bad coding structures.

As a user of FTN77 on the Pr1me, I have benefited from the many good features of the Salford/Silverfrost Fortran over this period.

John

John-Silver, Yes, over time this forum gathered a lot of interesting stuff.

JohnCampbell, Great that you are looking at this and already found some shortcuts. Finally someone has been doing that with FTN95, because first time we discussed these tests in comp.lang.fortran almost two decades ago. Salford Fortran was in the state of switch to Fortran 90 at that time and cleaning just the bugs took more then a decade so the optimization was not a first priority. Right now probably it's good time for that.

Have you tried one test on Polyhedron which gave whopping, hairs-rising 30x slowdown? Was this due to a lot of underflows? Or another John (Polyhedron's John Applegate) made something somewhere with the compiler settings? 😃