[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::fortran

Title:Digital Fortran
Notice:Read notes 1.* for important information
Moderator:QUARK::LIONEL
Created:Thu Jun 01 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1333
Total number of notes:6734

1148.0. "DLLIMPORT and code generation" by RDGENG::therml.reo.dec.com::BAKERS () Fri Jan 24 1997 10:35

DFANT 1.2

I'm trying to discover whether the same support exists for use of DLLIMPORT as 
does for C.  The problem is that one of my customers says that putting their 
application's .obj files into a DLL causes a 10% run-time performance hit as 
compared with static linking. There could be a number of reasons for this, and 
I don't have any more details yet, but I'm trying to determine whether the 10% 
is caused by normal DLL overhead, and whether it can be improved.

I'd expect there to be some sort of hit from using a DLL due to the revectoring 
of subroutine calls through the import address table. With C, using _declspec 
(dllimport) improves the generated code with respect to calls to DLL functions 
(doesn't branch to a thunk). By using the same techniques as I use with C, I've 
tried to get the same code generation behaviour with Fortran, but I can't seem 
to affect code generation - calls are still made by jumping through a thunk.

I modified the CHAREXMP example as a basis for working on this, putting cDEC$ 
ATTRIBUTES DLLIMPORT :: REVERSE immediately after the initial comments in 
CHAREXMP.FOR. (I also successfully used DLLEXPORT in the subroutines and hacked 
the Makefile so that it didn't use a .EXP, or invoke LIB to generate it)

The documentation on DLL*PORT only seems to show its use with COMMONs so I'm 
not sure whether I can really achieve what I want.

Info and comments appreciated.

Thanks.
Stephen
T.RTitleUserPersonal
Name		DateLines
1148.1TLE::EKLUNDAlways smiling on the inside!Fri Jan 24 1997 10:5618
    	Static linking is always going to be the very best for run-time
    performance.  However, the inherent penalty should not be all that
    large (unless all your programmers subscribe to the structured
    programming school where all routines are less than 10 lines long...)
    when you use DLLs instead.  There will be some startup costs.
    
    	Larger variations in run-time are more likely due to cache
    problems due to the resulting layout of the program and/or the lack
    of all the magic things that might happen if the sources are
    compiled or linked together (and the routines are inlined, etc.).
    If you are observing a really large penalty, I'll bet a careful
    analysis will show it's the cache.  For 10%, I'm not sure the
    analysis is worth it.  Is the 10% for a program that runs for an
    hour?  A minute?  5 seconds??
    
    Cheers!
    Dave Eklund
1148.2RDGENG::therml.reo.dec.com::BAKERSFri Jan 24 1997 11:1626
Dave, Many thanks for the quick reply!!

>        Larger variations in run-time are more likely due to cache
>    problems due to the resulting layout of the program and/or the lack
>    of all the magic things that might happen if the sources are
>    compiled or linked together (and the routines are inlined, etc.).
>    If you are observing a really large penalty, I'll bet a careful
>    analysis will show it's the cache. For 10%, I'm not sure the
>    analysis is worth it.  Is the 10% for a program that runs for an
>    hour?  A minute?  5 seconds??

I'm still waiting to hear what their *real* problem is (10% of what etc) and to 
get info on the apps structure, build commands etc. In the meantime I was 
investigating the DLLIMPORT stuff. One theory is that cache could get hurt if 
every call to a DLL function jumped via a thunk, rather than an indirect jump 
via the import address table (a la C). I too doubt that this alone would hurt 
performance by 10%, but stranger things have happened!!

So can DLLIMPORT's use in Fortran generate code as Visual C++ does? - i.e. not 
jumping to a thunk, but jumping indirectly to the DLL function using the import 
address table. If so, where do I put the CDEC$ statements and are there other 
compile and/or link requirements to get this to happen.

Thanks again,
Stephen
1148.3TLE::EKLUNDAlways smiling on the inside!Fri Jan 24 1997 14:408
    	I'm not familiar with what Visual C++ has done.  I'm pretty sure
    that f77 (and f90) have not yet done anything special, but I'm taking
    a quick look now at what might be done.  However, I would not bet my
    next paycheck that this will get back 10% of the time!
    
    Cheers!
    Dave Eklund