Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Gdy Scilab okazuje się za wolny...

Scilab to znany (szczególnie wśród studentów) pakiet naukowy wykorzystywany w wielu dziedzinach - od prostych obliczeń, przez macierze, algebrę liniową, przetwarzanie sygnałów, statystykę itp. W przeciwieństwie do swojego głównego konkurenta - GNU Octave - nie stara się być klonem Matlaba (a przynajmniej nie dąży do 100% kompatybilności).

Przy porównywaniu tego typu pakietów istotne są dwie kwestie: możliwości i wydajność. Za sprawą Xcos (odpowiednik Matlab/Simulink) Scilab zdaje się mieć większą funkcjonalość od Octave. Posiada również własny edytor o nazwie SciNotes oraz centrum do zarządania modułami ATOMS. Kwestię wydajności można prześledzić przy pomocy tego benchmarka.

Aktualnie trwają przygotowania do wydania wersji 5.3.0 pakietu Scilab. W wersji tej skupiono się szczególnie na poprawie wydajności ("new performance improvements including first HPC features"). Trwają również prace nad wykorzystaniem mocy GPU do obliczeń.

Scilab został stworzony z myślą o obliczeniach numerycznych i w tych sprawdza się dobrze. Gorzej radzi sobie z typowymi zadaniami stawianymi językom programowania, np. z pętlą for. Wydajność tego typu operacji można poprawić stosując podprogramy napisane w językach niższego poziomu np. Fortranie. Niedawno na forum Scilaba toczyła się dyskusja nad użyciem takiego właśnie podprogramu. Istnieje jednak proste rozwiązanie, do którego instrukcję można znaleźć na stronie kompilatora g95.

Na początku podano przykład wykorzystujący pętlę. Można domyślać się, że osiągnięto w ten sposób wzrost wydajności w sensie jakościowym, nie podano natomiast o ile szybciej dzięki temu wykonywane są obliczenia. Zastosujmy zatem podany przykład napisany w Scilabie oraz z wykorzystaniem podprogramu napisanego w Fortranie realizującego to samo zadanie.

a=rand(m,n); b=%pi; tic(); //SUBROUTINE foof(c,a,b,n,m) //INTEGER :: n,m //DOUBLE PRECISION :: a(*),b,c(*) //DO i = 1,m*n // c(i) = sin(a(i))+b //END DO //END SUBROUTINE foof c=call("foof",a,2,"d",b,3,"d",n,4,"i",m,5,"i","out",[m,n],1,"d"); t1=toc(); printf('Scilab + Fortran SUBROUTINE: %6.3f \n',t1) // "Scilab is working with double precision floats." // http://wiki.scilab.org/Scilab_precision d=zeros(m,n); tic(); for i=1:m*n, d(i)=sin(a(i))+b; end t2=toc(); printf('Scilab: %6.3f \n',t2)

Uzyskane czasy obliczeń przedstawiono na poniższym wykresie:

Z wykresu można łatwo odczytać, że zastosowanie w podanym przykładzie podprogramu napisanego w Fortranie pozwala na obniżenie czasu wykonywania pętli ponad 100x.

Do obliczeń wykorzystano laptop z procesorem Intel Core 2 Duo T7100 @1.80GHz 1.80GHz z systemem Windows Vista (32bit), Scilab 5.2.2, G95 0.92.

 

Komentarze

0 nowych
Airborn   8 #1 24.09.2010 01:23

Szkoda, że przedstawiony benchmark pochodzi ze strasznie archaicznych wersji tych narzędzi. na dobrą sprawę nie mówi on nic, bo sytuacja mogła się znacznie zmienić w tym czasie (nie sprawdzałem dokładnie, ale to raczej kwestia 2 lat albo i więcej)

iluzion   5 #2 24.09.2010 08:07

@Airborn

Przedstawione na tej stronie wyniki są już nieaktualne, ale benchmark działa. Odpalałem go jakiś czas temu i wymagał jedynie drobnych modyfikacji, o ile mnie pamięć nie myli.

Scilab: http://www.sciviews.org/benchmark/Scilab2.sce
Octave: http://www.sciviews.org/benchmark/Octave2.m
R: http://www.sciviews.org/benchmark/R2.R

  #3 24.09.2010 12:45

Ma wyjść 5.3.0 a tym czasem... Trwają pracę nad 6.0 :D Tzn. z lakonicznych informacji wynika że przepisują pełno rzeczy łącznie z samym rdzeniem programu. Xcos nie umywa się do simulink, podstawowym problemem jest brak już pre-definiowanych klocuszków do budowy silników elektrycznych itp. a jest to możliwe do zaimplementowania samemu bo to można opisać równaniami różniczkowymi. Jeśli idzie o benchmark jak pamiętam w scilab jest wbudowany benchmark wystarczy go jednym poleceniem uruchomić.

  #4 24.09.2010 12:45

a zapomniał bym co do GPU. Z tego co widziałem sytuacja jest nie jasna tzn. wahają się między opencl a cuda a podobno mieli użyć obu.