[Rd] From .Fortran to .Call?

[Avraham Adler]

Hi.

I haven't tested the speed of the old .Fortran interface, but in this
post [1] I describe how to build a simple interface (there are two
small packages on github that correspond to the code) and in this one
[2] I compare the speed of the different languages, but all using
.Call.

Hope that helps,

Avi

[1] https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/
[2] https://www.avrahamadler.com/2018/12/23/the-need-for-speed-part-2-c-vs-fortran-vs-c/

On Wed, Dec 23, 2020 at 11:34 AM Balasubramanian Narasimhan
<naras using stanford.edu> wrote:
>
> 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
>
>
> 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$