Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28689 Discussions

Fortran Dll file size by IVF 8.0 much larger than by CVF 6.x

wu_internet
Beginner
686 Views

This message is a follow on issue to the message with ID#: 8647. I posted it separately here. It is about porting dll project from CVF to IVF.

Under the compaq visual fortran, I build the dll by linkto the single threaded or multithreaded dll libraries, always, the dll file size is about 2MB. Under the Intel visual Fortran 8.0, no matter what libraries I link to, and in the release mode, the minimum dll file size I can achieve is more than 9MB. Anyone can tell me the difference between CVF and IVF when using linked to the same library and possible difference when I distribute the dll?

Regards,

David

0 Kudos
12 Replies
TimP
Honored Contributor III
686 Views
The usual reason for larger code size with ifort 8.0 is the introduction of vectorization and, consequently, multiple versions of loops, or, possibly, inter-procedural optimization. Multiple architecture optimizations, like /QaxNP, are particularly productive of multiple versions. Surely, you could give more information on what you have checked.
0 Kudos
wu_internet
Beginner
686 Views
Thanks for the suggestion.
I doubt that I am making the linkaginst the run time library always statically, However, I am not sure how to link dynamically. In the project...property...Fortran...Run time library, I checked the one I tried to link against, is there any other settings which I need to check and make a dynamic link aginst run time library? this must be a very basic question, however, when I checked the forum, always I come across "how to link statically". Therefore, I do need someone to give me a hand.
Regards,
David
0 Kudos
wu_internet
Beginner
686 Views

Thanks tcprince,

After some testing on different configurations, I found out that the dramatical size increase is caused by the enabling of runtime data array and string bound checking. Although same setting is done in CVF, the dll size is very small. However, bug has beenobserved in CVF that such checking on the array bound is not working well. After I remove the checking in IVF, the size come close to the one build under CVF.

Regards,

David

0 Kudos
Steven_L_Intel1
Employee
686 Views
Curious - I'm not aware of any bugs in CVF's array bounds checking. I don't know why using that in Intel Fortran would make the image size bigger - please submit an example to Intel Premier Support.
0 Kudos
wu_internet
Beginner
686 Views

Try the following code in CVF 6.x

real a(10)

if(a(0).gt.1..and.(.FALSE.)) then !The program should catch the array bound exceedance here.
a(0) = 1.0
endif

print*, 'If you see this message, the exceeds array bound has not been caught here'

stop
end

0 Kudos
wu_internet
Beginner
686 Views

Try the following code in CVF 6.x

real a(10)

if(a(0).gt.1..and.(.FALSE.)) then !The program should catch the array bound exceedance here.
a(0) = 1.0
endif

print*, 'If you see this message, the exceeds array bound has not been caught here'

stop
end

build the application with switch/check:bounds, the application works fine, but I don't think it should work in this way, it should be intercepted at the "if" clause.
David.
0 Kudos
Steven_L_Intel1
Employee
686 Views
Ah. The compiler can see that the array assignment will never be executed, so it removes all the code, including the reference, which is no longer needed.
0 Kudos
wu_internet
Beginner
686 Views

I have not thought the compiler has been so clever, how about the following example:

!Test the lower bound validation problem
real a(10)
logical lcondition

print*, 'The following code test the index exceeds array bound can/not be caught'
do i = 1,10
call getcondition(i,lcondition)
if(a(0).gt.1..and.lcondition) then !The program should catch the array bound exceedance here.
a(0) = 1.0
endif
print*, 'If you see this message, the exceeds array bound has not been caught here'

enddo
stop
end

subroutine getcondition(i,lcondition)
logical lcondition
integer i

if(i.le.20) then
lcondition = .FALSE.
else
lcondition = .True.
endif
return
end

As the lcondition is a variable now, if the compiler can remove the if clause again, I just think the compiler is too clever.

David

Message Edited by wu_internet on 04-14-2004 07:50 AM

0 Kudos
Steven_L_Intel1
Employee
686 Views
Two problems with this program:
1: You never use the value of a after the loop, so the compiler is within its rights to throw away all references and definitions to it. Add a print of a before the end of the program.
2. The compiler is free to evaluate lcondition first and skip the test on a if it is false, which it always is here. In fact, it does this. Change the test in getcondition to compare against 5 rather than 20 and you'll see that the array bounds error is caught.
0 Kudos
Steven_L_Intel1
Employee
686 Views
Two problems with this program:
1: You never use the value of a after the loop, so the compiler is within its rights to throw away all references and definitions to it. Add a print of a before the end of the program.
2. The compiler is free to evaluate lcondition first and skip the test on a if it is false, which it always is here. In fact, it does this. Change the test in getcondition to compare against 5 rather than 20 and you'll see that the array bounds error is caught.
Let me summarize - CVF's array bounds checking works, but the check is made only if the compiled code actually executes a reference to the array. If the references is removed due to optimization, or skipped because of other tests in the program, you won't see an error.
Two points to keep in mind:
1. The compiler is allowed to evaluate any logically equivalent expression as long as parentheses are honored.
2. If a piece of code's effect is only to generate a run-time exception, there is no guarantee that the code will be executed.
0 Kudos
wu_internet
Beginner
686 Views

Thanks, steve.

In that regard, the intel fortran compiler works just differently. All such "if" will be caught up with the array bound checking. Meanwhile, I do not understand why the switch on the checking will increase the dll file size so dramatically.

David.

0 Kudos
Steven_L_Intel1
Employee
686 Views
The Intel compiler evidently chooses to evaluate the expression in a different order. Both are acceptable.
I know that the Intel compiler passes a lot more information for the bounds checking than CVF does. For example, where CVF just gives a generic "array bounds exceeded" message, IVF says:
forrtl: severe (408): fort: (3): Subscript #1 of the array A has value 0 which is less than the lower bound of 1
I was not familiar with the implementation, but it seems that the compiler is inserting a string for the message (ready for formatting with sprintf) for each array reference, and the texts are all the same. Room for improvement here... I'll suggest this to the compiler team.
0 Kudos
Reply