Welcome to our forums
Does anyone have any views on whether this might be of any use or interest to the humble scientific Fortran user ?
https://eventbooking.stfc.ac.uk/news-events/fortran-modernisation-workshop
Does Silverfrost itself intend to participate?
Agree. All topics are from the top. Organizers seems are really smart. They should consider this in other places in the world
I have booked. It clashes with another conference which I had been planning to attend, but this one seems more interesting!
As a comment or request for future development I'd like to Silverfrost to look at 'NetCDF and HDF5 scientific file formats for data sharing in Fortran'. Reading and writing directly into HDF5 compressed files will become an important topic with 64bit computing with its TBytes of I/O data
If not the Unicode text fonts used in open source PlPlot i'd possibly looked at it as a substitution of our ugly, buggy, crappy, dead Simpleplot in %pl. The package is not abandoned like many many others, its 3D plotting capabilities look nice, and since it is open-source the users can modify it and would never stuck in the no-go situation like with Simpleplot
I would certainly agree about HDF5. Am currently in early stages of a 4-year project that will generate terabytes of data, and frankly worried about handling such data volumes efficiently!
I agree, Dan, about improving the graphics options. I don't use Simpleplot, and have mostly coded my own 2D and 3D graphics including SVG and VRML export interfaces, but it would be nice to stop banging my head against various brick walls!
I have made a note of Dan's request.
Simfit provides some 3D drawing facilities, see FTN95 help->Win32 platform->ClearWin+->SIMFIT->Simfit plotting styles. (The images don't show up for me when using the online help so you may need to open FTN95.chm to see them.)
SVG file output is available with ClearWin+. Documentation will be provided in the next release. Let me know if you want the information now.
Paul - thanks for the news about SVG export. Useful, as it's likely to be more general than my own, which was limited to just the functionality I needed at the time. Will take a look at the SIMFIT graphics, thx for the reminder!
One other simple question (commercial rather than technical). About to buy the upgrade, but there doesn't seem to be any '1yr updates' option as there is with a new purchase. Does it come with or without updates?
The upgrade doesn't come with updates. If you would like to buy an upgrade with updates then we can send you a quote.
The 64-bit version is now included in FTN95. I have amended the description to reflect this.
It did take quite a bit longer to finish the 64-bit compiler than we thought it would. Quite a bit longer. Anyone who bought 7.20 with a year of updates is entitled to 8.00. Now we have a 64-bit compiler updates will be more regular.
and I would like to say thanks for this 64 bit version. I have found it very robust for the 64 bit codes I have been testing and the ease of getting more memory for the clearwin+ applications has been great. I have also been beta testing the vector routines and find then a good addition for performance. I hope they can be finalised soon. I hope others find it similar.
John
I have now downloaded all the documents associated with this workshop (links are all here: http://www.nag.co.uk/content/fortran-modernization-workshop). One of them is a comparison of compilers - they compare features of 9 different compilers but Silverfrost is not one of them. The list was prepared by Polyhedron Solutions, who at one time actually sold the Salford/Silverfrost compiler. Maybe worth asking them to extend the list ?
One other question (maybe asked and answered before) - any current plans to develop Fortran 2003 or 2008 versions of the Silverfrost compiler?
The Polyhedron benchmarks are no longer so prominent on their website, but after a search I see that FTN95 v 7.20 has been used on a 64 bit version of Windows.
I imagine that using SSE etc may lead to different roundoffs between 32 and 64 bit versions of FTN95 as well as differences in performance. Has anyone run the Polyhedron benchmarks to compare 32 and 64 bit versions of FTN95?
Quoted from LitusSaxonicum Has anyone run the Polyhedron benchmarks to compare 32 and 64 bit versions of FTN95?
I don't think that it is useful to do so yet.
The Polyhedron performance benchmarks emphasize FPU performance. The 64-bit compiler does not support /opt yet, and the 32-bit compiler can only generate x87 instructions.
The Polyhedron diagnostics benchmarks can only be run with the 32-bit FTN95 compiler, since the 64-bit compiler does not yet support /undef, etc. The results for the 32-bit compiler are posted on the Polyhedron/AdeptScience/Fortran.uk pages.
Thanks Mecej4. I took the hint from Dave Bailey's thread that 64-bit version didn't support REAL*10 and that SSEx and AVX were in it. Even today, I suspect that some idea on relative performance would be useful, for example if FTN95 already runs faster in 64-bit than 32 bit then it can only get better. If it is lots slower, then it will be an uphill struggle. There was also a hint in another thread that at the end of a long calculation, the results diverged. I have no idea what the implications of that are.
Eddie
Eddie,
The present release of FTN95 /64 has removed support for 80 bit real10. My understanding is the only support for SSE/AVX instructions is via library functions, so these are not currently available in code as used for the Polyhedron benchmarks. As a consequence, the present /64 compiler is slow for numerical intensive calculations, as optimisation is not yet provided. The present FTN95 /64 is significantly slower than FTN95 /32 for numerical intensive real8 calculations. The Polyhedron benchmarks would not look good!
What optimisation will be provided in /64 will be interesting, as significant performance gains on other compilers are available via SSE/AVX vectorisation of inner DO loops. We will see if the FTN95 /64 /OPT project introduces this optimisation, or is limited to replicating the /32 optimisation approaches.
My experience is there is an insignificant performance penalty (none) transferring from 32-bit to 64-bit addressing, although more generally the changed instruction set does have both +ve and -ve effects. Changes from integer4 to integer8 is not a performance problem. Certainly, with /64 and using larger arrays can result in more memory <> cache delays, especially if not addressing arrays with a single variable stride. Poor array addressing and cache overflow are penalised more with /64.
My understanding is FTN95 /32 uses x87 instructions; although I am not sure to what extent it provides 80 bit precision.(are there still 80 bit registers?) Most REAL8 calculations retain only 64 bit, but if 80 bit registers are used, say for accumulators in a dot_product, higher precision can be available. My understanding is for REAL8, the Fortran 90/95 Standard requires calculations to be done to 64 bit, which negates the 80 bit precision. My recollection is that moving from F77 to F95 saw a loss of precision. If you ran a program that needed REAL*10-80 bit precision, then you could notice a slight loss of accuracy. These are unusual cases.
The present FTN95 /64 is significantly slower than FTN95 /32 for numerical intensive real*8 calculations. What is interesting is I have not seen any complaints about this, as I suspect most users are more interested in the extra memory available. I know that for graphics, I will not return to 32 bit clearwin+.
I have run the Polyhedron bench tests and the current non-optimised 64 bit results are on a par with or some what faster than the corresponding non-optimised 32 bit results.
Hi Paul,
I am mistaken with my comments, as I was recalling comparison tests of FTN95 /opt with FTN95 /64, both of which are very slow.
I have adapted a test I have been using recently to compare performance of a dot_product routine. I have tested dot_product_new (a,b,n) with different compilation options and N in the range 1 to 50. ( for SSE instructions, larger n values give better performance)
FTN95 /32 0.335 Gflop/s (floating point multiplies per second) FTN95 /64 0.423 FTN95 /OPT 0.743 FTN95 /64 1.225 ( using DOT_PRODUCT8@ )
I should resurrect the FTN95 /32 test with davidb's SSE routines, which I'd expect to get about 1.2 to 1.5.
Certainly Gflop values < 1.0 are slow.
John
John
Hopefully ftn95 /64 /opt will become fast enough otherwise (now that ClearWin+ is available separately) users could do their development using ftn95/ClearWin+ and then switch to a faster third party compiler for release.
The Polyhedron benchmarks have become more and more artificial, since they have simply increased repeat counts or increased the number of mesh points to keep up with increased processor speeds. It is more useful to take an actual code that is of current interest/concern and run timings on such a code.
There are instances where I have noticed that code compiled by FTN95 is slower than is reasonable. Here is one instance, relating to an engineering code that I am currently looking at, namely, the package HST3D ( wwwbrr.cr.usgs.gov/projects/GW_Solute/hst/ ). I found one bug in FTN95 8.05 that I reported ( forums.silverfrost.com/viewtopic.php?t=3343 ) and I modified the data files to work around this bug. Here are the results (in seconds, Dell laptop with i7-2720QM, Windows 10 Pro X64, network disconnected and antivirus turned off for runs).
Software: HST3D 2.2.16
HST3D 2.2.16
LF95 GFTN5.4(64) SILV(32) SILV(64) IFC17(64) CVF6.6C
Elder_heat 3.810 7.427 3.097 8.975
Elder_solute 3.176 6.313 178.374 2.876 7.727
Henry 0.407 0.767 1.613 2.565 0.407 1.061
Huyakorn 26.241 60.100 20.493 73.923
Hydrocoin 39.295 86.114 35.389 107.848
The compilers: Lahey LF95 7.1 (32-bit only) -Kfast,PENTIUM4,SSE2 GFTN5.4 : Gfortran 5.4, 64-bit, Cygwin-64 -O2 SILV : FTN95 8.05 /opt /p6 for 32-bit IFC17 : Intel Parallel Studio 2017, 64-bit -O2 -Qxhost CVF6.6C : Compaq Visual Fortran (32-bit only) /fast)
I have blanked out entries that were over 200 seconds.
It would be very helpful to have tools to hunt down and localize the bottlenecks in the EXEs that FTN95 produces.