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
> <kasperdanielhan...@gmail.com> 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 <rkoen...@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.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
