2013-03-01 11 views
16

Mam pakiet R, który używa wielu podprogramów Fortran dla zagnieżdżonych pętli obliczeń rekursywnej liniowej algebry (w dużym stopniu zależnych od procedur BLAS i LAPACK). Jako interfejs do Fortran używam funkcji .Fortran. Właśnie przeczytałem Jonathan Callahan's blog post o użyciu .Call zamiast .C w przypadku podprogramów napisanych w C/C++, i to mnie pomyślałem, że byłoby lepiej użyć interfejsu .Call również przy użyciu podprogramów Fortran, pisząc proste opakowanie w C, które następnie wywołuje podprogramy Fortran?R: Zalety korzystania z podprogramu Fortran z opakowaniem .Call i C/C++ zamiast .Fortran?

Jak powiedziałem, moje kody Fortran są dość proste w tym sensie, że gram w wielowymiarowe tablice typu double lub integer. Ale nauczyłem się, że muszę napisać całkiem sporo czeków po stronie R, aby upewnić się, że wszystko się nie psuje z powodu przypadkowego zapomnienia zmiany trybu przechowywania niektórych macierzy na całkowitą lub wymiarów niektórych matryc zostały zmienione itp.

Podprogramy zapisywane są jako F90/95.

+1

wydaje się być rozsądnym do użycia .Call() z pewną funkcją C, i wtedy możesz rzeczywiście wywołać twoje podprogramy Fortrana z kodu C, co jest stosunkowo łatwe (lub nawet zrobić wszystko w C, jeśli naprawdę nie potrzebujesz Fortran). – steabert

+0

Tak, ale jakie korzyści może to przynieść? Mógłbym całkowicie przełączyć się na C, ale to byłoby zbyt kłopotliwe i wątpię, że byłoby użyteczne, ponieważ wtedy wzywałbym funkcje Fortran BLAS z C. –

+0

Może być istotna: http://www.ualberta.ca/AICT/RESEARCH/LinuxClusters/doc/ifc91/main_for/mergedProjects/bldaps_for/pgsclmix.htm – KLDavenport

Odpowiedz

3

Może zaistnieć korzyść, jeśli pracujesz z dużym zestawem danych. .Call może być znacznie szybszy, ponieważ nie kopiujesz danych za każdym razem, gdy wywołujesz funkcję. Dla przypadku opisanego w tej kwestii, nie będzie taka korzyść, ponieważ zwolnienie R 2.15.1 stwierdza stan

.C() i .Fortran() zrobić mniej Kopiowanie: argumenty, które są surowe, logiczne, liczby całkowite, rzeczywiste lub złożone i są nienazwane, nie są kopiowane przed wywołaniem, a (nazwane lub nie) nie są kopiowane po wywołaniu. Listy nie są już kopiowane (mają być używane tylko do odczytu w kodzie C).

Przejście na .Call oznacza rezygnację z wygody interfejsu .Fran. Przekazałbyś SEXP do kodu C, wykonałbyś wszelkie kontrole/manipulacje danymi za pomocą (strasznego i niezbyt udokumentowanego) R API, a następnie wywołałeś funkcję Fortran z C. Każdy, kto pracuje z twoim kodem, będzie musiał zrozumieć R API i interakcja C/Fortran.

+0

Tak, kopiowanie wydaje się być jedną wyraźną korzyścią, chociaż z R 2.15.1 różnica jest nieco zmniejszona: ".C()' i '.Fortran()' robią mniej kopiowania: argumenty, które są surowe, logiczne, całkowite Wektory rzeczywiste lub złożone i nienazwane nie są kopiowane przed wywołaniem, a (nazwane lub nie) nie są kopiowane po wywołaniu. " (Od R News). –

+0

Wygląda na to, że w moim wniosku efekty kopiowania nie są znaczące; Testowałem wywoływanie mojego kodu z '.Fortran' przy użyciu' DUP = FALSE' i 'DUP = TRUE', i praktycznie nie widziałem żadnych różnic, chociaż używałem tablic zawierających miliony elementów. –

+0

Nie wiedziałem o zmianie zachowania tych funkcji. Zmieniłem to pytanie, aby to odzwierciedlić. – user2225804

Powiązane problemy