Will there be any interest in using Coarrays Fortran, please? Thanks, Erin
Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Wed, Dec 23, 2020 at 10:29 AM Martin Maechler <maech...@stat.math.ethz.ch> wrote: > >>>>> 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.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 > > ______________________________________________ > 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
