Re: [Rd] From .Fortran to .Call?
Erin, I think rumors of the deprecation of .Fortran are greatly exaggerated, but I’d welcome some confirmation of this from someone in R core. There is quite a lot of .Fortran usage in packages, and perhaps even in base R... > On Dec 26, 2020, at 7:57 PM, Erin Hodgess wrote: > > Is .Fortran going to be deprecated, please? I have gotten amazing speed up > with geostatistics processes using HPC type tools. > > Thanks > > On Sat, Dec 26, 2020 at 9:48 AM Koenker, Roger W > 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 > > 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 > 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
Re: [Rd] From .Fortran to .Call?
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 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 > 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 > 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 assumi
Re: [Rd] From .Fortran to .Call?
Is .Fortran going to be deprecated, please? I have gotten amazing speed up with geostatistics processes using HPC type tools. Thanks On Sat, Dec 26, 2020 at 9:48 AM Koenker, Roger W 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 > 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 > 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 conven
Re: [Rd] From .Fortran to .Call?
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 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 > >>> 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 > > >
Re: [Rd] From .Fortran to .Call?
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 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 > 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 >> 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 >> > 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 + >> >>> "Koenker, Roger W" 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 inter
Re: [Rd] From .Fortran to .Call?
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 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 > 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 > > 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 + > >>> "Koenker, Roger W" 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$ > > ___
[Rd] In function isum in summary.c, k should be R_xlen_t
In summary.c, in function 'isum', the loop is 'ITERATE_BY_REGION' that contains 'for' loop for (int k = 0; k < nbatch; k++) It is since SVN revision 73445, in released R since version 3.5.0. Previously, the loop is for (R_xlen_t i = 0; i < n; i++) Inside 'ITERATE_BY_REGION', the type of the index, 'k', should still be 'R_xlen_t' as previously. If 'sx' is a regular vector (not ALTREP), data pointer is taken and 'nbatch' is the length of the vector, like without 'ITERATE_BY_REGION'. With 64-bit R, it is possible that the vector is a long vector. In that case, correct iteration should reach index outside the range of 'int'. However, I haven't found an example in 64-bit R of wrong behavior of sum(x) for 'x' with storage mode "integer" and length 2^31 or more. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] In function isum in summary.c, k should be R_xlen_t
Don't know this piece well but I am guessing that you haven't found an example because the iterator is going up to the length of a vector anymore but only to the number of batches, which is unlikely to be more than 2^31. On Tue, Dec 22, 2020 at 12:30 PM Suharto Anggono Suharto Anggono via R-devel wrote: > > > In summary.c, in function 'isum', the loop is 'ITERATE_BY_REGION' that > contains 'for' loop > for (int k = 0; k < nbatch; k++) > It is since SVN revision 73445, in released R since version 3.5.0. > Previously, the loop is > for (R_xlen_t i = 0; i < n; i++) > > Inside 'ITERATE_BY_REGION', the type of the index, 'k', should still be > 'R_xlen_t' as previously. If 'sx' is a regular vector (not ALTREP), data > pointer is taken and 'nbatch' is the length of the vector, like without > 'ITERATE_BY_REGION'. With 64-bit R, it is possible that the vector is a long > vector. In that case, correct iteration should reach index outside the range > of 'int'. > > However, I haven't found an example in 64-bit R of wrong behavior of > sum(x) > for 'x' with storage mode "integer" and length 2^31 or more. > > __ > 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
