Fortran - My two cents on Intel Visual Fortran versus ...

Author

My two cents on Intel Visual Fortran versus ...

awgreynolds@earthlink.net

2005-06-09, 3:58 pm

I have a sophisticated Fortran-95 application that currently compiles
under several compilers and operating systems (IBM XLF on MacOSX, Lahey
LF95 on Windows, and G95 on both OS's). I recently downloaded an
evaluation version of Intel Visual Fortran 8.1.

At first my code would not compile because IVF does not support
referencing a user function with an explicit interface in a statement
function. The other compilers had no problem with it and I don't know
whether it is some violation of the standard.

Anyway, I moved the statement function into a CONTAINS and got it to
compile. After trying different mixtures of optimization switches, the
best IVF could do on a 3.0 Ghz Pentium-4 is run my application 5%
faster than the much cheaper Lahey Express compiler (don't forget IVF
is not standalone because it requires a MS C++ installation).

This is a suprisingly modest gain in speed for a compiler from the same
people who produce the processor. For comparison, my application runs
20% faster on a "slower" 1.8Ghz PowerMac G5 using IBM's own XLF
compiler. (Don't get me started on the recent annoucement that Apple is
switching to Intel processors and compilers!).

I was an early user of DVF on Windows and have watched the
"mongrelization" of that clean DEC compiler by first having to
encompass the awful MS Powerstation 4.0 and then the original Intel EPC
based compilers. The number of switches with all the redundancy is
mind boggling compared to, for instance, Lahey's small clean set.

The bottom line is that I still see no compelling reason to move to
IVF.

Alan Greynolds
(Yes, the same guy quoted on the CVF website)

Richard E Maine

2005-06-09, 8:58 pm

In article <1118338406.585305.78190@g14g2000cwa.googlegroups.com>,
awgreynolds@earthlink.net wrote:

> IVF does not support
> referencing a user function with an explicit interface in a statement
> function. The other compilers had no problem with it and I don't know
> whether it is some violation of the standard.

That would surprise me if the cause is *EXACTLY* as you describe. It
certainly could be the case, but I'd be at least mildly surprised. I'd
want to see an actual sample before being convinced that your
description is accurate.

In particular...

The standard says that a statement function can't reference a user
function that *REQUIRES* an explicit interface. I'd guess that is your
problem. Note that there is a big difference between requiring an
explicit interface and having one. It is quite normal for a function to
have an explicit interface even though it doesn't require one.

Thus, if the function in question requires an explicit interface, then
the code is nonstandard. Like many nonstandard things, some compilers
might accept it. However, I note that the prohibition in question is a
constraint, so if any compilers accept such a thing without a warning
message (providing you've asked for all diagnostics available), then
those compilers are in violation of the standard.

If the function doesn't require an explicit interface, but compilation
fails if you give it one anyway, then that would be a compiler bug in
IVF. Could be, but I'd need to see the code before I'd accept such a
claim. It is far too easy for people to sloppily state things that
confuse important details (like the difference between having vs
requiring an explicit interface), or just to be unaware of some of the
things that trigger the requirement.

I'll note in general that statement functions have a lot of "funny"
conditions and don't generally mix well with "new style" stuff (such as
anything that requires an explicit interface). Indeed, statement
functions are obsolescent in f95 (and I hear that there was a vote to
delete them in f2008 - or whatever it ends up getting called.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

awgreynolds@earthlink.net

2005-06-10, 4:00 am

This small test case shows the pertinent details:

C:\ivf\geloe>type bug.f90
module disdata
real :: range(2,10)
contains
function CoordValue(i,j) result(v)
intent(in) i,j
v=range(i,j)
end function
end

program bug
use disdata
del(j)=CoordValue(2,j)-CoordValue(1,j)
end
C:\ivf\geloe>ifort bug.f90
Intel(R) Fortran Compiler for 32-bit applications, Version 8.1 Build
20050201Z Package ID: w_fc_pc_8.1.028
Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
30 DAY EVALUATION LICENSE

ifort: NOTE: The evaluation period for this product ends on 5-jul-2005
UTC.
bug.f90(12) : Error: External functions with explicit interface are not
supported in statement functions [COORDVALUE]
del(j)=CoordValue(2,j)-CoordValue(1,j)
--------^
bug.f90(12) : Error: External functions with explicit interface are not
supported in statement functions [COORDVALUE]
del(j)=CoordValue(2,j)-CoordValue(1,j)
------------------------^
bug.f90(12) : Info: This statement function has not been used. [DEL]
del(j)=CoordValue(2,j)-CoordValue(1,j)
-^
compilation aborted for bug.f90 (code 1)

Does this fit the "require an explicit interface" definition? With
checking for adherence to the 95 standard turned on, the other
compilers (FTN95 also) only warn that statement functions are obsolete
but they all still compile it.

Richard Maine

2005-06-10, 4:00 am

awgreynolds@earthlink.net writes:

> This small test case shows the pertinent details:
[elided]

> bug.f90(12) : Error: External functions with explicit interface are not
> supported in statement functions [COORDVALUE]

Hmm. I have some other errands to do right now, but the code looks ok
to me. Certainly nothing in the function requires an explicit
interface. I'd need to carefully check if any of the other strange
conditions on statement functions are violated, but I don't off-hand
think so. For example, I don't think there is a prohibition against
module procedures, but I really can't be sure without checking.
I'll look at it tomorroe if nobody else has checked yet before then.

I'd say odds are that it is probably an IVF bug. At the very least,
I'd say that the error message is incorrect in 2 separate ways.

1. San\me issue I mentioned to you - the error message rather
distinctly says functions "with explicit interface", which simply
is not a correct statement of the restriction. Makes one suspicious
that perhaps whoever wrote the error message didn't understand
the distinction.

Second, there are no external functio0ns anywhere in this code,
so the error message is wrong in that regard.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Umberto D'Ortona

2005-06-10, 8:57 am

Hi,
my two cents :

del(:) is not define in the main program :

awgreynolds@earthlink.net wrote:
module disdata
real :: range(2,10)
contains
function CoordValue(i,j) result(v)
intent(in) i,j
v=range(i,j)
end function
end

program bug
use disdata
! ---------------- HERE -----------
real :: del(10)
! --------------------
del(j)=CoordValue(2,j)-CoordValue(1,j)
end

[umberto@pounche Fortran]$ ifort bug.f90
[umberto@pounche Fortran]$

I agree, the error message of ifort is a little confusing.

Herman D. Knoble

2005-06-10, 4:00 pm

I'd suggest turning in the bug with a version that is compiled
and will run without undeclared, uninitialized variables.

Skip

module disdata
! This bug is not fixed in IFORT Version 8.1.
real :: range(2,4) = &
reshape( (/ 1.1, 2.1, 1.2,2.2, 1.3,2.3, 1.4,2.4 /), (/2,4/) )

contains
function CoordValue(i,j) result(v)
integer, intent(in) :: i,j
real :: v
v=range(i,j)
end function
end

program bug
use disdata
real :: del
integer :: j
del(j)=CoordValue(2,j)-CoordValue(1,j)
print *, del(3)
end

On 9 Jun 2005 18:30:27 -0700, awgreynolds@earthlink.net wrote:

-|This small test case shows the pertinent details:
-|
-|C:\ivf\geloe>type bug.f90
-|module disdata
-| real :: range(2,10)
-|contains
-| function CoordValue(i,j) result(v)
-| intent(in) i,j
-| v=range(i,j)
-| end function
-|end
-|
-|program bug
-| use disdata
-| del(j)=CoordValue(2,j)-CoordValue(1,j)
-|end
-|C:\ivf\geloe>ifort bug.f90
-|Intel(R) Fortran Compiler for 32-bit applications, Version 8.1 Build
-|20050201Z Package ID: w_fc_pc_8.1.028
-|Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
-|30 DAY EVALUATION LICENSE
-|
-|ifort: NOTE: The evaluation period for this product ends on 5-jul-2005
-|UTC.
-|bug.f90(12) : Error: External functions with explicit interface are not
-|supported in statement functions [COORDVALUE]
-| del(j)=CoordValue(2,j)-CoordValue(1,j)
-|--------^
-|bug.f90(12) : Error: External functions with explicit interface are not
-|supported in statement functions [COORDVALUE]
-| del(j)=CoordValue(2,j)-CoordValue(1,j)
-|------------------------^
-|bug.f90(12) : Info: This statement function has not been used. [DEL]
-| del(j)=CoordValue(2,j)-CoordValue(1,j)
-|-^
-|compilation aborted for bug.f90 (code 1)
-|
-|Does this fit the "require an explicit interface" definition? With
-|checking for adherence to the 95 standard turned on, the other
-|compilers (FTN95 also) only warn that statement functions are obsolete
-|but they all still compile it.

Steve Lionel

2005-06-10, 4:00 pm

On Thu, 09 Jun 2005 19:10:36 -0700, Richard Maine <nospam@see.signature>
wrote:

>I'd say odds are that it is probably an IVF bug.

I agree - I'll get this fixed. I would encourage anyone who finds a problem
with whatever compiler they are using to report it to the vendor directly.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Steve Lionel

2005-06-10, 4:00 pm

On Thu, 09 Jun 2005 19:10:36 -0700, Richard Maine <nospam@see.signature>
wrote:

>I'd say odds are that it is probably an IVF bug.

Oh, and CVF has the same bug - no surprise.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

awgreynolds@earthlink.net

2005-06-10, 4:00 pm

I myself consider the "bug" briefly mentioned in my original post to
be minor, obscure, and easy to get around. That's why I'm surprised
that all the responses focussed on it and not the other more important
(at least to me) points I made. To summarize, I'm still disappointed
by the marginal performance you gain on Intel processors using the
bloated, relatively expensive IVF.

Alan Greynolds

Richard E Maine

2005-06-10, 4:00 pm

In article <d8bim9$mjd$1@news.univ-mrs.fr>,
Umberto D'Ortona <XumbertoX@l3Xm.univ-mrsX.removeX.fr> wrote:

> del(:) is not define in the main program :

Yes it is. Del is a statement function (statement functions being the
subject of the immediate discussion). Statement functions definitions
look misleadingly like assignment statements. They have been known to
confuse both compilers and humans. I don't particularly like them. But
that's what del is in the subject code.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Jan Vorbrüggen

2005-06-10, 4:00 pm

> To summarize, I'm still disappointed by the marginal performance you
> gain on Intel processors using the bloated, relatively expensive IVF.

Well, I'll leave the bloated and expensive to others...but do you think
Intel, because it designed the processor, has a magic bullet that will
generate significantly faster code than anybody else? In particular when
you compare CVF and IVF, i.e., the same high-level optimization approach?
That's not very likely. I have read of examples where IVF was pretty good
at vectorizing code when that was possible...but then, I suppose the Path-
scale compiler is pretty good at that as well.

Jan

Rich Townsend

2005-06-10, 4:00 pm

awgreynolds@earthlink.net wrote:
> I myself consider the "bug" briefly mentioned in my original post to
> be minor, obscure, and easy to get around. That's why I'm surprised
> that all the responses focussed on it and not the other more important
> (at least to me) points I made. To summarize, I'm still disappointed
> by the marginal performance you gain on Intel processors using the
> bloated, relatively expensive IVF.

Are you sure you're benchmarking with a code that really stresses the
compilers? I know it's not a direct comparison, but Intel Fortran on
Linux produces code that executes approximately twice as fast as the
nearest competitor I've tried (Lahey).

cheers,

Rich

Abdul Qat

2005-06-10, 4:00 pm

<awgreynolds@earthlink.net> wrote in message
news:1118414947.281753.208760@z14g2000cwz.googlegroups.com...
> I myself consider the "bug" briefly mentioned in my original post to
> be minor, obscure, and easy to get around. That's why I'm surprised
> that all the responses focussed on it and not the other more important
> (at least to me) points I made. To summarize, I'm still disappointed
> by the marginal performance you gain on Intel processors using the
> bloated, relatively expensive IVF.
>
> Alan Greynolds
>

FWIT, the IVF and CVF bug isn't exhibited by Microsoft Fortran PowerStation
4 which compiles your code snippet without a hitch, :-).

--
Salaam,
Gerry T.
______
"It's the suppression of the word that gives it the power, the violence,
the viciousness." Lenny Bruce

awgreynolds@earthlink.net

2005-06-10, 4:00 pm

Something like a factor of two is what I was expecting from Intel, but
not what I got with my real-world engineering code on Windows XP. On
the other hand, its exactly what I get with XLF on the IBM processor in
my PowerMac when compared to other compilers on MacOSX. Maybe its more
a problem with my expectations than with Intel :-)

Alan

Brian Wannamaker

2005-06-10, 4:00 pm

On Fri, 10 Jun 2005 09:27:27 -0400, Steve Lionel
<Steve.Lionel@REMOVEintelME.com> wrote:

>I agree - I'll get this fixed. I would encourage anyone who finds a problem
>with whatever compiler they are using to report it to the vendor directly.
>
As an end-user, I on the other hand, would encourage everyone
confirming a bug with any compiler to report it also to the usergroup.
I do not see any advantage with all of us spending time to discover
and confirm the same bug.

BWW

Steve Lionel

2005-06-10, 8:57 pm

On 10 Jun 2005 09:51:40 -0700, awgreynolds@earthlink.net wrote:

>Something like a factor of two is what I was expecting from Intel, but
>not what I got with my real-world engineering code on Windows XP. On
>the other hand, its exactly what I get with XLF on the IBM processor in
>my PowerMac when compared to other compilers on MacOSX. Maybe its more
>a problem with my expectations than with Intel :-)

A factor of two is a bit of a stretch, even for us. We HAVE seen some
programs achieve that over CVF, but 20-30% is more typical. Of course, YMMV,
but it's unusual to find programs that don't show at least a 10% speedup. The
best performance is found when enabling SSE2 or SSE3 optimizations on
supported processors, and using the multifile interprocedural analysis and
profile-guided optimization can make big improvements as well.

Of course, not all progams are CPU-bound. Even we can't work miracles with
disk drives and memory subsystems.

If you have a program which is not seeing an improvement over CVF (or any
competing compiler), we'd like to see it. We have a team of engineers who
specialize in performance analysis and tuning (something we could never afford
to do for CVF under Compaq.) Submit the example to Intel Premier Support.

If you go to
http://www.intel.com/software/produ...rade_to_ivf.htm today,
you'll see a downloadable document that compares features and performance of
IVF 8.1 to CVF. We'll update that when we launch the 9.0 product.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

awgreynolds@earthlink.net

2005-06-10, 8:57 pm

Your document seems to indicate significantly better speed improvement
over CVF (~25%) on the Polyhedron benchmarks than they actually report
on their website (~10%). Is the difference that you optimized and ran
the benchmarks on a processor with SSE3 support? Did you separately
optimize the individual benchmarks or use the the same compiler
switches for all like Poyhedron does?

Alan

PS. Footnote (9) indicates a 1GB L2 cache. A typo right?

Stig Kildegård Andersen

2005-06-10, 8:57 pm

> As an end-user, I on the other hand, would encourage everyone
> confirming a bug with any compiler to report it also to the usergroup.
> I do not see any advantage with all of us spending time to discover
> and confirm the same bug.

I do not understand why sites such as premier support do not offer a
searchable (and _up to date_) list of confirmed bugs. Vendors could leave
out the shady examples and the ones containing "secret code" and only
include the ones with small and easy to understand examples. I should think
such a thing could be rigged to communicate with the vendors internal bug
tracking system so that ,eventually, it would require little effort on their
part.
I have looked at the "known software defects ..." document for the
Intel Fortran compiler, but it appears to be very incomplete, i.e none of
the current bug reports I have on premier support are in it :-) Also I think
the list should contain only bugs that persist even wih the newest
version/update/patch/whatever of the product. An ETA for a fix of eaxh bug
would also be helpful for those of us who have to plan ahead....

As an end user you would then have the opportunity to take a quick look at
that list before embarking on a programming adventure where known compiler
bugs will spoil the fun sooner or later. Given that it apparently takes from
a some months to a few yearsto fix compiler bugs, i.e. always too long to
way for, I think doing this would be a valuable service to customers.

Best Regards,
Stig Kildegård

2005-06-10, 8:57 pm

Steve Lionel wrote:
>
> If you have a program which is not seeing an improvement over CVF (or any
> competing compiler), we'd like to see it.

Someone offered me a car with an improved acceleration but it came with
a wooden seat and *no* dashboard... I'll pass, as I'm sure will most of
the CVF drivers.

beliavsky@aol.com

2005-06-10, 8:57 pm

Stig Kildeg=E5rd Andersen wrote:

<snip>

> I do not understand why sites such as premier support do not offer a
> searchable (and _up to date_) list of confirmed bugs. Vendors could leave
> out the shady examples and the ones containing "secret code" and only
> include the ones with small and easy to understand examples. I should thi=
nk
> such a thing could be rigged to communicate with the vendors internal bug
> tracking system so that ,eventually, it would require little effort on th=
eir
> part.
> I have looked at the "known software defects ..." document for the
> Intel Fortran compiler, but it appears to be very incomplete, i.e none of
> the current bug reports I have on premier support are in it :-) Also I th=
ink
> the list should contain only bugs that persist even wih the newest
> version/update/patch/whatever of the product. An ETA for a fix of eaxh bug
> would also be helpful for those of us who have to plan ahead....
>
> As an end user you would then have the opportunity to take a quick look at
> that list before embarking on a programming adventure where known compiler
> bugs will spoil the fun sooner or later. Given that it apparently takes f=
rom
> a some months to a few yearsto fix compiler bugs, i.e. always too long to
> way for, I think doing this would be a valuable service to customers.

Compiler bugs are fixed most quickly when there is a single developer,
working in his spare time, for free :).

I agree with your suggestions.

2005-06-10, 8:57 pm

"Stig Kildegård Andersen" wrote:
>
> I have looked at the "known software defects ..." document for the
> Intel Fortran compiler, but it appears to be very incomplete, i.e none of
> the current bug reports I have on premier support are in it

Think business! Would you put a thick folder of known defects next to
your "shinny" car you're trying to sell, half naked broad sprawled on
the hood notwithstanding!??

James Van Buskirk

2005-06-11, 3:57 am

<beliavsky@aol.com> wrote in message
news:1118436603.458202.100160@g14g2000cwa.googlegroups.com...

> Compiler bugs are fixed most quickly when there is a single developer,
> working in his spare time, for free :).

I don't know about that. One of the first g95 bugs I reported
is still outstanding after 6 months. But maybe you are right --
after all, I had a bug report for CVF that took years to resolve.

BTW, I noticed that Outlook Express didn't automatically mark
your quoted message as such. Is this some kind of defect in
OE, or is there some anomaly in the way you are posting that
does this?

I do have an example, that's not quite done yet, that CVF and
LF95 don't handle well at all, like 10-22% efficiency. If I
get time this w

end, maybe I'll be able to finish the example
and see if Intel can do anything useful with it.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

beliavsky@aol.com

2005-06-11, 3:58 pm

James Van Buskirk wrote:

<snip>

> BTW, I noticed that Outlook Express didn't automatically mark
> your quoted message as such. Is this some kind of defect in
> OE, or is there some anomaly in the way you are posting that
> does this?

As usual, I just used "show options", "Reply to Author" using Google
Groups, with Internet Explorer as my browser.

Sponsored Links