[Rd] From .Fortran to .Call?

Erin Hodgess er|nm@hodge@@ @end|ng |rom gm@||@com
Wed Dec 23 22:12:29 CET 2020


Will there be any interest in using Coarrays Fortran, please?

Thanks,
Erin

Erin Hodgess, PhD
mailto: erinm.hodgess using gmail.com


On Wed, Dec 23, 2020 at 10:29 AM Martin Maechler <maechler using stat.math.ethz.ch>
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.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
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



More information about the R-devel mailing list