As for speed, I suspect much of the speedup when converting from .Fortran to .Call will be due to checking the validity of the arguments (lengths, types, ranges, etc.) in C code instead of in R code. There can also be less copying of the arguments and the returned objects will tend to be smaller.
-Bill On Wed, Dec 23, 2020 at 8:27 AM Bill Dunlap <williamwdun...@gmail.com> wrote: > 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? > > No. .Call(C_func, arg1, arg2) expects C_func's arguments to all be SEXP* > (pointers to R objects), never the double* or the like that .Fortran > expects. > > -Bill > > On Wed, Dec 23, 2020 at 3:58 AM Koenker, Roger W <rkoen...@illinois.edu> > 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.ad...@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 >> > <na...@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" <rkoen...@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@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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
