One plausible explanation of why this works is that the use of MODULE, INTENT and DIMENSION give the compiler the hints it needs to be smart about how to access the non stride-1 list%A data structure and avoid the unnecessary creation of temporary arrays and as a result the code is now very efficient.Īnother plaussible explanation, however, is that these constructs simply confuses the compiler and as a result it does not produce any warnings anymore, but at runtime the performance is as bad as it used to be.Īny comments in deciding if this solution is really adequate or if I should look for a more proper solution it will be most appreciated. Microsoft (R) Incremental Linker Version 3.0Ĭopyright (C) Microsoft Corporation. Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.2.0 Build 20210228_000000Ĭopyright (C) 1985-2021 Intel Corporation. The modified code takes 0.0156s - 0s, so this does speeds up the execution: >ifort solution.f90 The following code is almost the same, but when compiler with -check all it does not produce a warning anymore: MODULE SRCHĬHARACTER(*), DIMENSION(:),INTENT(IN) :: LSTĪs a result, when tested to run consecutively 100k times with an array of 100k entries in an Intel(R) Core™ i5-8365U CPU 1.60GHz, 1896 Mhz, 4 Core(s) laptop, the original codes takes 24.8s - 25.3s. This is understandable as the shape of the list array type is not the same as the expected array of strings argument, and as a result the list%A column is a non stride-1 array, so the compiler decides to make a copy of list%A before passing it to the method.Īfter some research, Arjen Markus suggested several improvements to modernize the old code and use accessor auxiliary functions that circumvected the problem.įurther research indicated that this scenario can be fixed without resorting to auxiliary functions and that it can be fixed by only introducing a minimum set of some of the new language features like MODULE, INTENT and DIMENSION that change the way the arguments and the signature of the function are defined. *forrtl: warning (406): fort: (1): In call to VSRCH, an array temporary was created for argument #2*
When compiled with -check all a warning appears telling us that pasing the column list%A to the VSRCH method creates a temporary array:
In the original simplified code below, The main TEST program reads an array of complex types, and uses the VSRCH to find the location of a string in one of the string colums of the complex type: INTEGER FUNCTION VSRCH(STR, LST, L) The situation emerges in legacy code that processes business-like data structures from data blobs that I cant modify. I would like to hear your recommendation on how to optimize the scenario in where I need to pass a column of a type array element as a parameter to a function while avoiding the creation of temporary arrays.
0 kommentar(er)
