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.ad...@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 <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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
