From .Fortran to .Call?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

From .Fortran to .Call?

Koenker, Roger W
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.  I understand
and greatly appreciate its use with dyn.load() and R CMD SHLIB for development workflow.
In an effort to modernize my quantreg package I wanted to solicit some advice
about whether it was worthwhile to move away from .Fortran, and if so how this
might be most expeditiously carried out.

As things currently stand my src directory has, in addition to couple dozen .f
files, a file called quantreg_init.c that contains

#include <R_ext/RS.h>
#include <stdlib.h> // for NULL
#include <R_ext/Rdynload.h>

/* .Fortran calls */
extern void F77_NAME(brutpow)(void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *);
extern void F77_NAME(combin)(void *, void *, void *, void *, void *, void *, void *);
extern void F77_NAME(crqf)(void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *);



static const R_FortranMethodDef FortranEntries[] = {
    {"brutpow",   (DL_FUNC) &F77_NAME(brutpow),   14},
    {"combin",    (DL_FUNC) &F77_NAME(combin),     7},
    {"crqf",      (DL_FUNC) &F77_NAME(crqf),      26},

...

void R_init_quantreg(DllInfo *dll)
{
    R_registerRoutines(dll, CEntries, NULL, FortranEntries, NULL);
    R_useDynamicSymbols(dll, FALSE);
}
This was originally setup by an experienced R person in about 2006, but has
always been rather opaque to me; I just follow the template to add fortran
functions.  My questions are:  what would I need to do beyond replacing
.Fortran calls by .Call in my R code?  And would it help? Obviously, what
I’m dreading is being told that all those “void”s would have to be specified
more explicitly even though they are already specified in the fortran.  My willingness to
embarrass myself by writing this message was triggered by comparing
timings of a prototype function in R and its fortranization in which the
prototype was actually faster.  Thanks in advance for any suggestions.
   








______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Bill Dunlap-2
To make C prototypes for routines defined in a *.f file you can use
gfortran's -fc-prototypes-external flag.  You still have to convert 'name_'
to 'F77_NAME(name).

bill@Bill-T490:~/packages/quantreg/src$ gfortran -fc-prototypes-external
-fsyntax-only boot.f
... [elided defs of complex types] ...
/* Prototypes for external procedures generated from boot.f
   by GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0.

   Use of this interface is discouraged, consider using the
   BIND(C) feature of standard Fortran instead.  */

void pwy_ (int *m, int *n, int *k, int *m5, int *n2, double *a, double *c,
double *b, double *t, double *toler, int *ift, double *x, double *e, int
*s, double *wa, double *wb);
void xys_ (int *mofn, int *m, int *n, int *k, int *mofn5, int *n2, double
*a, double *b, double *tau, double *toler, int *ift, double *x, double *e,
int *s, double *wa, double *wb, double *aa, double *bb, int *ss);
void wxy_ (int *m, int *n, int *k, int *m5, int *n2, double *a, double *b,
double *tau, double *toler, int *ift, double *x, double *e, int *s, double
*wa, double *wb, double *aa, double *bb, double *w);

#ifdef __cplusplus
}
#endif
bill@Bill-T490:~/packages/quantreg/src$ gfortran --version
GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

On Sat, Dec 19, 2020 at 9:05 AM Koenker, Roger W <[hidden email]>
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.  I understand
> and greatly appreciate its use with dyn.load() and R CMD SHLIB for
> development workflow.
> In an effort to modernize my quantreg package I wanted to solicit some
> advice
> about whether it was worthwhile to move away from .Fortran, and if so how
> this
> might be most expeditiously carried out.
>
> As things currently stand my src directory has, in addition to couple
> dozen .f
> files, a file called quantreg_init.c that contains
>
> #include <R_ext/RS.h>
> #include <stdlib.h> // for NULL
> #include <R_ext/Rdynload.h>
>
> /* .Fortran calls */
> extern void F77_NAME(brutpow)(void *, void *, void *, void *, void *, void
> *, void *, void *, void *, void *, void *, void *, void *, void *);
> extern void F77_NAME(combin)(void *, void *, void *, void *, void *, void
> *, void *);
> extern void F77_NAME(crqf)(void *, void *, void *, void *, void *, void *,
> void *, void *, void *, void *, void *, void *, void *, void *, void *,
> void *, void *, void *, void *, void *, void *, void *, void *, void *,
> void *, void *);
>
> …
>
> static const R_FortranMethodDef FortranEntries[] = {
>     {"brutpow",   (DL_FUNC) &F77_NAME(brutpow),   14},
>     {"combin",    (DL_FUNC) &F77_NAME(combin),     7},
>     {"crqf",      (DL_FUNC) &F77_NAME(crqf),      26},
>
> ...
>
> void R_init_quantreg(DllInfo *dll)
> {
>     R_registerRoutines(dll, CEntries, NULL, FortranEntries, NULL);
>     R_useDynamicSymbols(dll, FALSE);
> }
> This was originally setup by an experienced R person in about 2006, but has
> always been rather opaque to me; I just follow the template to add fortran
> functions.  My questions are:  what would I need to do beyond replacing
> .Fortran calls by .Call in my R code?  And would it help? Obviously, what
> I’m dreading is being told that all those “void”s would have to be
> specified
> more explicitly even though they are already specified in the fortran.  My
> willingness to
> embarrass myself by writing this message was triggered by comparing
> timings of a prototype function in R and its fortranization in which the
> prototype was actually faster.  Thanks in advance for any suggestions.
>
>
>
>
>
>
>
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Ivan Krylov
In reply to this post by Koenker, Roger W
On Sat, 19 Dec 2020 17:04:59 +0000
"Koenker, Roger W" <[hidden email]> 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).

--
Best regards,
Ivan

P.S. I think that this question is better asked in the
[hidden email] mailing list instead of R-devel.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Balasubramanian Narasimhan
To deal with such Fortran issues in several packages I deal with, I
wrote the SUtools package (https://github.com/bnaras/SUtools) 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://bnaras.github.io/SUtools/articles/SUtools.html

-Naras


On 12/19/20 9:53 AM, Ivan Krylov wrote:

> On Sat, 19 Dec 2020 17:04:59 +0000
> "Koenker, Roger W" <[hidden email]> 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).
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Avraham Adler
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://CRAN.R-project.org/package=Delaporte
[2] https://github.com/wrathematics/Romp
[3] https://github.com/t-kalinowski/RFI

Tomasz Kalinowski



On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
<[hidden email]> wrote:

>
> To deal with such Fortran issues in several packages I deal with, I
> wrote the SUtools package (https://github.com/bnaras/SUtools) 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://bnaras.github.io/SUtools/articles/SUtools.html
>
> -Naras
>
>
> On 12/19/20 9:53 AM, Ivan Krylov wrote:
> > On Sat, 19 Dec 2020 17:04:59 +0000
> > "Koenker, Roger W" <[hidden email]> 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).
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Koenker, Roger W
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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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).
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Bill Dunlap-2
       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 <[hidden email]>
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 <[hidden email]>
> 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
> > <[hidden email]> 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" <[hidden email]> 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).
> >>>
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Balasubramanian Narasimhan
In reply to this post by Koenker, Roger W
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


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 <[hidden email]> 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
>> <[hidden email]> 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" <[hidden email]> 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).
>>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Avraham Adler
Hi.

I haven't tested the speed of the old .Fortran interface, but in this
post [1] I describe how to build a simple interface (there are two
small packages on github that correspond to the code) and in this one
[2] I compare the speed of the different languages, but all using
.Call.

Hope that helps,

Avi

[1] https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/
[2] https://www.avrahamadler.com/2018/12/23/the-need-for-speed-part-2-c-vs-fortran-vs-c/

On Wed, Dec 23, 2020 at 11:34 AM Balasubramanian Narasimhan
<[hidden email]> 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://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
>
>
> 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 <[hidden email]> 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
> >> <[hidden email]> 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" <[hidden email]> 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).
> >>>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Göran Broström-3
In reply to this post by Koenker, Roger W


On 2020-12-19 18:04, Koenker, Roger W wrote:
> There are comments in various places, including R-extensions §5.4 suggesting that .Fortran is (nearly)
> deprecated

This scares me somewhat: Where in §5.4 do you find that suggestion? My
package eha is built upon a stand-alone Fortran 77 program from the
early eighties (emanating from an appendix in [1]) and has served me
well over the years, I see no reason at all to switch to .Call for that
old stuff. But of course, if .Fortran will be deprecated ... Can someone
confirm if, and if so when, that will happen?

Regarding speed, as I understand it, it is a question of making many
(short) calls to .Fortran for solving one problem. If you make only one
or just a few calls to .Fortran (the case in eha), no problem.

[1] Kalbfleisch & Prentice (1980). The Statistical Analysis of Failure
Time Data.

Göran Broström

: and hinting that use of .Call is more efficient and now preferred for
packages.  I understand

> and greatly appreciate its use with dyn.load() and R CMD SHLIB for development workflow.
> In an effort to modernize my quantreg package I wanted to solicit some advice
> about whether it was worthwhile to move away from .Fortran, and if so how this
> might be most expeditiously carried out.
>
> As things currently stand my src directory has, in addition to couple dozen .f
> files, a file called quantreg_init.c that contains
>
> #include <R_ext/RS.h>
> #include <stdlib.h> // for NULL
> #include <R_ext/Rdynload.h>
>
> /* .Fortran calls */
> extern void F77_NAME(brutpow)(void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *);
> extern void F77_NAME(combin)(void *, void *, void *, void *, void *, void *, void *);
> extern void F77_NAME(crqf)(void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *, void *);
>
> …
>
> static const R_FortranMethodDef FortranEntries[] = {
>      {"brutpow",   (DL_FUNC) &F77_NAME(brutpow),   14},
>      {"combin",    (DL_FUNC) &F77_NAME(combin),     7},
>      {"crqf",      (DL_FUNC) &F77_NAME(crqf),      26},
>
> ...
>
> void R_init_quantreg(DllInfo *dll)
> {
>      R_registerRoutines(dll, CEntries, NULL, FortranEntries, NULL);
>      R_useDynamicSymbols(dll, FALSE);
> }
> This was originally setup by an experienced R person in about 2006, but has
> always been rather opaque to me; I just follow the template to add fortran
> functions.  My questions are:  what would I need to do beyond replacing
> .Fortran calls by .Call in my R code?  And would it help? Obviously, what
> I’m dreading is being told that all those “void”s would have to be specified
> more explicitly even though they are already specified in the fortran.  My willingness to
> embarrass myself by writing this message was triggered by comparing
> timings of a prototype function in R and its fortranization in which the
> prototype was actually faster.  Thanks in advance for any suggestions.
>    
>
>
>
>
>
>
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Martin Maechler
In reply to this post by Balasubramanian Narasimhan
>>>>> 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 <[hidden email]> 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
    >>> <[hidden email]> 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" <[hidden email]> 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).
    >>>>>
    >>>> ______________________________________________
    >>>> [hidden email] mailing list
    >>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Bill Dunlap-2
In reply to this post by Koenker, Roger W
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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>
>> 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
>> > <[hidden email]> 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" <[hidden email]> 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).
>> >>>
>> >>
>> >> ______________________________________________
>> >> [hidden email] mailing list
>> >>
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Erin Hodgess-2
In reply to this post by Martin Maechler
Will there be any interest in using Coarrays Fortran, please?

Thanks,
Erin

Erin Hodgess, PhD
mailto: [hidden email]


On Wed, Dec 23, 2020 at 10:29 AM Martin Maechler <[hidden email]>
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 <
> [hidden email]> 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
>     >>> <[hidden email]> 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" <[hidden email]> 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).
>     >>>>>
>     >>>> ______________________________________________
>     >>>> [hidden email] mailing list
>     >>>>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
>
>     > ______________________________________________
>     > [hidden email] mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Balasubramanian Narasimhan
In reply to this post by Balasubramanian Narasimhan
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://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
>
>
> 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 <[hidden email]>
>>> 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
>>> <[hidden email]> 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" <[hidden email]> 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).
>>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
>>>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Koenker, Roger W
Yes, dotcall64 looks interesting.  There is a paper about it here:

https://www.sciencedirect.com/science/article/pii/S2352711018300785?via%3Dihub

and the R spam package contains many examples of its use for fortran source.

> On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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" <[hidden email]> 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).
>>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Koenker, Roger W
In reply to this post by Balasubramanian Narasimhan
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 <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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" <[hidden email]> 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).
>>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Erin Hodgess-2
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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]>
> 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
> >>>> <[hidden email]> 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" <[hidden email]> 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).
> >>>>>>
> >>>>> ______________________________________________
> >>>>> [hidden email] mailing list
> >>>>>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Erin Hodgess, PhD
mailto: [hidden email]

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Avraham Adler
In reply to this post by Koenker, Roger W
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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]>
> 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
> >>>> <[hidden email]> 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" <[hidden email]> 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).
> >>>>>>
> >>>>> ______________________________________________
> >>>>> [hidden email] mailing list
> >>>>>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Sent from Gmail Mobile

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Koenker, Roger W
In reply to this post by Koenker, Roger W
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>> <[hidden email]> 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" <[hidden email]> 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).
> >>>>>>
> >>>>> ______________________________________________
> >>>>> [hidden email] mailing list
> >>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> --
> Erin Hodgess, PhD
> mailto: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: From .Fortran to .Call?

Koenker, Roger W
In reply to this post by Koenker, Roger W
Indeed, using profmem there is a significant advantage in memory:

>  sum(mb$bytes)
[1] 261834640   #using .Fortran
> sum(ma$bytes)
[1] 149221000  #using .C64

> On Dec 26, 2020, at 10:22 PM, Kasper Daniel Hansen <[hidden email]> wrote:
>
> Did you check memory usage? I don't know anything about Fortran, but using .Call for C code doesn't duplicate the memory of the objects you supply to the interface, and in some instances, that's an advantage. But that assumes you're doing something like
>   .Call("foo", xx)
> and not
>   Call("foo", as.matrix(xx))
>
>
>
> On Sat, Dec 26, 2020 at 5:48 PM Koenker, Roger W <[hidden email]> 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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12