[Rd] 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 <naras using 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 using gmail.com> wrote:
>>>> 
>>>> Hello, Ivan.
>>>> 
>>>> I used .Call instead of .Fortran in the Delaporte package [1]. What
>>>> helped me out a lot was Drew Schmidt's Romp examples and descriptions
>>>> [2]. If you are more comfortable with the older Fortran interface,
>>>> Tomasz Kalinowski has a package which uses Fortran 2018 more
>>>> efficiently [3]. I haven't tried this last in practice, however.
>>>> 
>>>> Hope that helps,
>>>> 
>>>> Avi
>>>> 
>>>> [1] https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
>>>> [2] https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
>>>> [3] https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
>>>> 
>>>> Tomasz Kalinowski
>>>> 
>>>> 
>>>> 
>>>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
>>>> <naras using stanford.edu> wrote:
>>>>> To deal with such Fortran issues in several packages I deal with, I
>>>>> wrote the SUtools package (https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$ ) that you
>>>>> can try.  The current version generates the registration assuming
>>>>> implicit Fortran naming conventions though. (I've been meaning to
>>>>> upgrade it to use the gfortran -fc-prototypes-external flag which should
>>>>> be easy; I might just finish that during these holidays.)
>>>>> 
>>>>> There's a vignette as well:
>>>>> https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$ 
>>>>> 
>>>>> -Naras
>>>>> 
>>>>> 
>>>>> On 12/19/20 9:53 AM, Ivan Krylov wrote:
>>>>>> On Sat, 19 Dec 2020 17:04:59 +0000
>>>>>> "Koenker, Roger W" <rkoenker using illinois.edu> wrote:
>>>>>> 
>>>>>>> There are comments in various places, including R-extensions §5.4
>>>>>>> suggesting that .Fortran is (nearly) deprecated and hinting that use
>>>>>>> of .Call is more efficient and now preferred for packages.
>>>>>> My understanding of §5.4 and 5.5 is that explicit routine registration
>>>>>> is what's important for efficiency, and your package already does that
>>>>>> (i.e. calls R_registerRoutines()). The only two things left to add
>>>>>> would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
>>>>>> R_ARG_OUT/...) of the arguments of each subroutine.
>>>>>> 
>>>>>> Switching to .Call makes sense if you want to change the interface of
>>>>>> your native subroutines to accept arbitrary heavily structured SEXPs
>>>>>> (and switching to .External could be useful if you wanted to play with
>>>>>> evaluation of the arguments).
>>>>>> 
>>>>> ______________________________________________
>>>>> R-devel using r-project.org mailing list
>>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
>> 
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$