Home > Archive > Fortran > February 2008 > Difference between Intel Visual Fortran and Compaq VF
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Difference between Intel Visual Fortran and Compaq VF
|
|
|
| Anybody knows how big the difference is? Are there any significant
improvements from CVF to IVF?
| |
| Gary Scott 2008-02-13, 10:13 pm |
| yaqi wrote:
> Anybody knows how big the difference is? Are there any significant
> improvements from CVF to IVF?
Most if not all of the "public" differences are described on Intel's web
site. Source code is almost 100% compatible. module use names may need
to change slightly, many additional Windows APIs are documented, some
errors in the definitions fixed and more standard conforming (used to be
a lot of usage of 16#xxxxxxxx instead of z'xxxxxxxx', don't know that
that has universally changed though (I prefer the 16# syntax anyway)).
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Tim Prince 2008-02-13, 10:13 pm |
| yaqi wrote:
> Anybody knows how big the difference is? Are there any significant
> improvements from CVF to IVF?
The last major Intel CPU type fully supported by CVF was Pentium II, and
64-bit mode was a long way in the future. Maybe, if you run as if you had
a P-II, don't want any f2003 features, and don't want a supported
compiler, the differences won't be significant.
| |
| Gib Bogle 2008-02-14, 4:30 am |
| yaqi wrote:
> Anybody knows how big the difference is? Are there any significant
> improvements from CVF to IVF?
Go to www.polyhedron.com and look at Fortran > Compiler Comparisons
It seems that IVF is faster than CVF on most benchmarks, sometimes
considerably so. This doesn't say anything about your code, of course.
I have noticed a great increase in compilation speed since I installed
IVF.
| |
|
| On Feb 13, 6:59=A0pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
> Most if not all of the "public" differences are described on Intel's web
> site. =A0Source code is almost 100% compatible. =A0module use names may ne=
ed
> to change slightly, many additional Windows APIs are documented, some
> errors in the definitions fixed and more standard conforming (used to be
> a lot of usage of 16#xxxxxxxx instead of z'xxxxxxxx', don't know that
> that has universally changed though (I prefer the 16# syntax anyway)).
>
I've always wondered why the standard insists on the z'xxxxxxxx'
syntax ---I also prefer the #xxxxxxxx one.
And, in the same alignment of ideas... Will the variable format
expressions (e.g., '(<n>I4.0)') ever make it into the standard?
John.
| |
| Michael Metcalf 2008-02-14, 7:14 pm |
|
"Gib Bogle" <bogle@ihug.too.much.spam.co.nz> wrote in message
news:fp0m2o$o2r$1@lust.ihug.co.nz...
> yaqi wrote:
>
> Go to www.polyhedron.com and look at Fortran > Compiler Comparisons
>
> It seems that IVF is faster than CVF on most benchmarks, sometimes
> considerably so. This doesn't say anything about your code, of course. I
> have noticed a great increase in compilation speed since I installed IVF.
I can confirm that. Pay attention to all the 'Properties' to get the optimum
settings.
Regards,
Mike Metcalf
| |
| Gary Scott 2008-02-14, 7:14 pm |
| jwm wrote:
> On Feb 13, 6:59 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>
>
> I've always wondered why the standard insists on the z'xxxxxxxx'
> syntax ---I also prefer the #xxxxxxxx one.
It is much more flexible in specifying the number base (up to base 36 I
think).
>
> And, in the same alignment of ideas... Will the variable format
> expressions (e.g., '(<n>I4.0)') ever make it into the standard?
>
This has been argued for a long time. There are too many problems and
limitations with it and the results can be achieved with other methods.
>
> John.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Steve Lionel 2008-02-14, 7:14 pm |
| On Feb 13, 8:59 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
> yaqi wrote:
>
> Most if not all of the "public" differences are described on Intel's web
> site. Source code is almost 100% compatible. module use names may need
> to change slightly, many additional Windows APIs are documented, some
> errors in the definitions fixed and more standard conforming (used to be
> a lot of usage of 16#xxxxxxxx instead of z'xxxxxxxx', don't know that
> that has universally changed though (I prefer the 16# syntax anyway)).
A good starting point is http://www.intel.com/cd/software/pr...lers/284698.htm
which discusses migrating from CVF to Intel Visual Fortran.
Note that the # syntax, adopted from Microsoft Fortran PowerStation,
has subtly different semantics than the Z'xxx' syntax. The former is
always an integer constant whereas the latter's type is context-
dependent.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
| |
| Gib Bogle 2008-02-14, 7:14 pm |
| Hi Steve,
I fell victim to one tiny but hard-to-find gotcha when I transferred my
CVF projects to IVF. My project links in a module that is built
separately as a library. The project build went OK, but when I ran the
program I got all sorts of odd failure modes, memory access violations,
divide by zero, etc. It took me half a day, but I found that the
library had been built with External Procedures > Calling Convention set
to CVF, while the calling program used Default. (Solution was to set
all to Default) Did I do something wrong in the conversion, to run into
this?
Gib
| |
| Steve Lionel 2008-02-14, 10:13 pm |
| On Feb 14, 5:17 pm, Gib Bogle <g.bo...@auckland.no.spam.ac.nz> wrote:
> Hi Steve,
>
> I fell victim to one tiny but hard-to-find gotcha when I transferred my
> CVF projects to IVF. My project links in a module that is built
> separately as a library. The project build went OK, but when I ran the
> program I got all sorts of odd failure modes, memory access violations,
> divide by zero, etc. It took me half a day, but I found that the
> library had been built with External Procedures > Calling Convention set
> to CVF, while the calling program used Default. (Solution was to set
> all to Default) Did I do something wrong in the conversion, to run into
> this?
Did you also "convert" your executable project? I have not seen such
a problem reported before (nor have I run into it myself.) I'll agree
that it can be a bear to diagnose. This particular combination does
not cause link errors because CVF (and /iface:cvf) generates two
symbols for each routine, one of which looks like the C mechanism
convention.
Feel free to take this to our user forum - c.l.f is perhaps not the
best place for such a discussion.
Steve
|
|
|
|
|