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 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$
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 at 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 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$
>>>>> 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.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://stat.ethz.ch/mailman/listinfo/r-devel
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://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 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://stat.ethz.ch/mailman/listinfo/r-devel