I had some time, so I updated a toy package I have for explaining R and Fortran use to use both the .Call and the .Fortran interfaces [1]. I think the actual Fortran code is as close to identical as I can reasonably make it. On my computer, the .Call interface (_f) is around 4 times as fast as the .Fortran interface (_f2). Bill, I don't know if you can, or should, "just" change .Fortran to .Call. You certainly cannot do the reverse. I think my source code made as minimal a change as possible; maybe that would help. ------- set.seed(77) A <- runif(100, 0, 2000) microbenchmark(LLC_f(A, 500, 500), LLC_f2(A, 500, 500), times 10000L, control = list(order = 'block'), check = 'equal') Unit: nanoseconds expr min lq mean median uq max neval cld LLC_f(A, 500, 500) 700 702 799.5906 801 802 6601 10000 a LLC_f2(A, 500, 500) 3000 3101 3328.8712 3201 3401 19802 10000 b -------- Thanks, Avi [1] https://github.com/aadler/SimpFort On Sat, Dec 26, 2020 at 10:48 PM Avraham Adler <avraham.adler at gmail.com> wrote:> > I?ve tried recoding some of Delaporte to use the .Fortran interface and I don?t know what I?m doing wrong but it either doesn?t work or crashes my R instance completely. > > Avi > > On Sat, Dec 26, 2020 at 11:48 AM Koenker, Roger W <rkoenker at illinois.edu> wrote: >> >> I?ve recoded a version of one of my quantile regression fitting functions to use .C64 from dotCall64 rather than .Fortran. >> For a moderately large problem with n = 500,000 and p = 5, and solving for 1:49/50 quantiles the new version shows >> a 3% speedup, although for smaller problems it is actually slower that the .Fortran version. So, I?m (provisionally) >> unimpressed by the claims that .Fortran has a big ?overhead? performance penalty. Compared to the(more than) an order of >> magnitude (base 10) improvement that moving from R to fortran produces, 3% isn?t really worth the (admittedly) minimal >> additional coding effort. >> >> > On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan <naras at stanford.edu> wrote: >> > >> > Also, just came to know about dotcall64::.C64() (on CRAN) which allows for Fortran to be called using .Call(). >> > >> > -Naras >> > >> > On 12/23/20 8:34 AM, Balasubramanian Narasimhan 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://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$ >> >> 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://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$ 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 at 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 at 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 at 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 at 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 at r-project.org mailing list >> >> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$ >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Sent from Gmail Mobile