From .Fortran to .Call?
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