[Rd] From .Fortran to .Call?

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Wed Dec 23 18:20:14 CET 2020

>>>>> Balasubramanian Narasimhan 
>>>>>     on Wed, 23 Dec 2020 08:34:40 -0800 writes:

    > I think it should be pretty easy to fix up SUtools to use the .Call 
    > instead of .Fortran following along the lines of

    > https://github.com/wrathematics/Romp

    > I too deal with a lot of f77 and so I will most likely finish it before 
    > the new year, if not earlier. (Would welcome testers besides myself.)

    > Incidentally, any idea of what the performance hit is, quantitatively? I 
    > confess I never paid attention to it myself as most Fortran code I use 
    > seems pretty fast, i.e. glmnet.

    > -Naras

well, glmnet's src/*.f  code seems closer to assembly than to
even old fortran 77 style ..
which would not change when calling it via .Call() ...

The performance "hit" of using .Fortran is probably almost only
from the fact .C() and .Fortran() now compulsorily *copy* their
arguments, whereas with .Call() you are enabled to shoot
yourself in both feet .. ;-)


    > On 12/23/20 3:57 AM, Koenker, Roger W wrote:
    >> Thanks to all and best wishes for a better 2021.
    >> Unfortunately I remain somewhat confused:
    >> o  Bill reveals an elegant way to get from my rudimentary  registration setup to
    >> one that would explicitly type the C interface functions,
    >> o Ivan seems to suggest that there would be no performance gain from doing this.
    >> o  Naras’s pcLasso package does use the explicit C typing, but then uses .Fortran
    >> not .Call.
    >> o  Avi uses .Call and cites the Romp package https://github.com/wrathematics/Romp
    >> where it is asserted that "there is a (nearly) deprecated interface .Fortran() which you
    >> should not use due to its large performance overhead.”
    >> As the proverbial naive R (ab)user I’m left wondering:
    >> o  if I updated my quantreg_init.c file in accordance with Bill’s suggestion could I
    >> then simply change my .Fortran calls to .Call?
    >> o  and if so, do I need to include ALL the fortran subroutines in my src directory
    >> or only the ones called from R?
    >> o  and in either case could I really expect to see a significant performance gain?
    >> Finally, perhaps I should stipulate that my fortran is strictly f77, so no modern features
    >> are in play, indeed most of the code is originally written in ratfor, Brian Kernighan’s
    >> dialect from ancient times at Bell Labs.
    >> Again,  thanks to all for any advice,
    >> Roger
    >>> On Dec 23, 2020, at 1:11 AM, Avraham Adler <avraham.adler using gmail.com> wrote:
    >>> Hello, Ivan.
    >>> I used .Call instead of .Fortran in the Delaporte package [1]. What
    >>> helped me out a lot was Drew Schmidt's Romp examples and descriptions
    >>> [2]. If you are more comfortable with the older Fortran interface,
    >>> Tomasz Kalinowski has a package which uses Fortran 2018 more
    >>> efficiently [3]. I haven't tried this last in practice, however.
    >>> Hope that helps,
    >>> Avi
    >>> [1] https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
    >>> [2] https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
    >>> [3] https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
    >>> Tomasz Kalinowski
    >>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
    >>> <naras using stanford.edu> wrote:
    >>>> To deal with such Fortran issues in several packages I deal with, I
    >>>> wrote the SUtools package (https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$ ) that you
    >>>> can try.  The current version generates the registration assuming
    >>>> implicit Fortran naming conventions though. (I've been meaning to
    >>>> upgrade it to use the gfortran -fc-prototypes-external flag which should
    >>>> be easy; I might just finish that during these holidays.)
    >>>> There's a vignette as well:
    >>>> https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$
    >>>> -Naras
    >>>> On 12/19/20 9:53 AM, Ivan Krylov wrote:
    >>>>> On Sat, 19 Dec 2020 17:04:59 +0000
    >>>>> "Koenker, Roger W" <rkoenker using illinois.edu> wrote:
>>>>> There are comments in various places, including R-extensions §5.4
>>>>> suggesting that .Fortran is (nearly) deprecated and hinting that use
>>>>> of .Call is more efficient and now preferred for packages.
    >>>>> My understanding of §5.4 and 5.5 is that explicit routine registration
    >>>>> is what's important for efficiency, and your package already does that
    >>>>> (i.e. calls R_registerRoutines()). The only two things left to add
    >>>>> would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
    >>>>> R_ARG_OUT/...) of the arguments of each subroutine.
    >>>>> Switching to .Call makes sense if you want to change the interface of
    >>>>> your native subroutines to accept arbitrary heavily structured SEXPs
    >>>>> (and switching to .External could be useful if you wanted to play with
    >>>>> evaluation of the arguments).
    >>>> ______________________________________________
    >>>> R-devel using r-project.org mailing list
    >>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

    > ______________________________________________
    > R-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list