[Rd] From .Fortran to .Call?

[Martin Maechler]

>>>>> 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 .. ;-)

Martin



    > 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