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 <rkoen...@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 < > na...@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.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://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$ > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Sent from Gmail Mobile [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
