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 <erinm.hodgess at
gmail.com> 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 <rkoenker at
illinois.edu> wrote:
> I?ve recoded a version of one of my quantile regression fitting functions
to use .C64 from dotCall64 rather than .Fortran.
> For a moderately large problem with n = 500,000 and p = 5, and solving for
1:49/50 quantiles the new version shows
> a 3% speedup, although for smaller problems it is actually slower that the
.Fortran version. So, I?m (provisionally)
> unimpressed by the claims that .Fortran has a big ?overhead? performance
penalty. Compared to the(more than) an order of
> magnitude (base 10) improvement that moving from R to fortran produces, 3%
isn?t really worth the (admittedly) minimal
> additional coding effort.
>
> > On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan <naras at
stanford.edu> wrote:
> >
> > Also, just came to know about dotcall64::.C64() (on CRAN) which allows
for Fortran to be called using .Call().
> >
> > -Naras
> >
> > On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
> >> I think it should be pretty easy to fix up SUtools to use the
.Call instead of .Fortran following along the lines of
> >>
> >>
https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
> >> I too deal with a lot of f77 and so I will most likely finish it
before the new year, if not earlier. (Would welcome testers besides myself.)
> >>
> >> Incidentally, any idea of what the performance hit is,
quantitatively? I confess I never paid attention to it myself as most Fortran
code I use seems pretty fast, i.e. glmnet.
> >>
> >> -Naras
> >>
> >>
> >> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
> >>> Thanks to all and best wishes for a better 2021.
> >>>
> >>> Unfortunately I remain somewhat confused:
> >>>
> >>> o Bill reveals an elegant way to get from my rudimentary
registration setup to
> >>> one that would explicitly type the C interface functions,
> >>>
> >>> o Ivan seems to suggest that there would be no performance
gain from doing this.
> >>>
> >>> o Naras?s pcLasso package does use the explicit C typing,
but then uses .Fortran
> >>> not .Call.
> >>>
> >>> o Avi uses .Call and cites the Romp package
https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
where it is asserted that "there is a (nearly) deprecated interface
.Fortran() which you
> >>> should not use due to its large performance overhead.?
> >>>
> >>> As the proverbial naive R (ab)user I?m left wondering:
> >>>
> >>> o if I updated my quantreg_init.c file in accordance with
Bill?s suggestion could I
> >>> then simply change my .Fortran calls to .Call?
> >>>
> >>> o and if so, do I need to include ALL the fortran
subroutines in my src directory
> >>> or only the ones called from R?
> >>>
> >>> o and in either case could I really expect to see a
significant performance gain?
> >>>
> >>> Finally, perhaps I should stipulate that my fortran is
strictly f77, so no modern features
> >>> are in play, indeed most of the code is originally written in
ratfor, Brian Kernighan?s
> >>> dialect from ancient times at Bell Labs.
> >>>
> >>> Again, thanks to all for any advice,
> >>> Roger
> >>>
> >>>
> >>>> On Dec 23, 2020, at 1:11 AM, Avraham Adler
<avraham.adler at gmail.com> wrote:
> >>>>
> >>>> Hello, Ivan.
> >>>>
> >>>> I used .Call instead of .Fortran in the Delaporte package
[1]. What
> >>>> helped me out a lot was Drew Schmidt's Romp examples
and descriptions
> >>>> [2]. If you are more comfortable with the older Fortran
interface,
> >>>> Tomasz Kalinowski has a package which uses Fortran 2018
more
> >>>> efficiently [3]. I haven't tried this last in
practice, however.
> >>>>
> >>>> Hope that helps,
> >>>>
> >>>> Avi
> >>>>
> >>>> [1]
https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
> >>>> [2]
https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
> >>>> [3]
https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
> >>>>
> >>>> Tomasz Kalinowski
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
> >>>> <naras at stanford.edu> wrote:
> >>>>> To deal with such Fortran issues in several packages I
deal with, I
> >>>>> wrote the SUtools package
(https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$
) that you
> >>>>> can try. The current version generates the
registration assuming
> >>>>> implicit Fortran naming conventions though. (I've
been meaning to
> >>>>> upgrade it to use the gfortran -fc-prototypes-external
flag which should
> >>>>> be easy; I might just finish that during these
holidays.)
> >>>>>
> >>>>> There's a vignette as well:
> >>>>>
https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$
> >>>>>
> >>>>> -Naras
> >>>>>
> >>>>>
> >>>>> On 12/19/20 9:53 AM, Ivan Krylov wrote:
> >>>>>> On Sat, 19 Dec 2020 17:04:59 +0000
> >>>>>> "Koenker, Roger W" <rkoenker at
illinois.edu> wrote:
> >>>>>>
> >>>>>>> There are comments in various places,
including R-extensions ?5.4
> >>>>>>> suggesting that .Fortran is (nearly)
deprecated and hinting that use
> >>>>>>> of .Call is more efficient and now preferred
for packages.
> >>>>>> My understanding of ?5.4 and 5.5 is that explicit
routine registration
> >>>>>> is what's important for efficiency, and your
package already does that
> >>>>>> (i.e. calls R_registerRoutines()). The only two
things left to add
> >>>>>> would be types (REALSXP/INTSXP/...) and styles
(R_ARG_IN,
> >>>>>> R_ARG_OUT/...) of the arguments of each
subroutine.
> >>>>>>
> >>>>>> Switching to .Call makes sense if you want to
change the interface of
> >>>>>> your native subroutines to accept arbitrary
heavily structured SEXPs
> >>>>>> (and switching to .External could be useful if you
wanted to play with
> >>>>>> evaluation of the arguments).
> >>>>>>
> >>>>> ______________________________________________
> >>>>> R-devel at r-project.org mailing list
> >>>>>
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >>
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> --
> Erin Hodgess, PhD
> mailto: erinm.hodgess at gmail.com