[Rd] From .Fortran to .Call?

[Bill Dunlap]

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 <williamwdunlap using gmail.com>
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 <rkoenker using illinois.edu>
> 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 using 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 using 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 using 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 using 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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

	[[alternative HTML version deleted]]