On 18 Sty, 21:24, Michoo <m...@v...pl> wrote:
> Mariusz Marszałkowski pisze:
>
>
>
> >> Po trzecie. Wydajnosc matlaba to sprawa drugorzedna. 70% to
> >> niezly wynik.
> > To inna sprawa z ktora sie zgadzam. Po prostu czesto mnie
> > zasypywano informacjami o super wydajnosci matlaba, a teraz
> > wiem ze wydajnosc raczej ma przecietna.
>
> Napisz teraz to samo mnożenie macierzy w javie i porównaj wyniki. Okaże
> się, że matlab jest wyjątkowo szybki. ;)

Gdy testowałem ostatnio wydajnosc javy, to czesto czasy wykonania
na "czesciach obliczeniowych" algorytmu nie roznily sie w ogole od C+
+.
Szczegolnie na architekturze 64-bitowej java rzadko odstaje od C++.
Przez czesci obliczeniowe rozumiem cos takiego, gdzie w petetlach
sa wykonywane obliczenia arytmetyczono logiczne. Gdy sie pojawia
wywolywanie duzej ilosci metod do dopiero java wyraznie traci.

Pozdrawiam

do góry

>> Matlab ma pierdyliard funkcji, sporo zastosowań się znajdzie :)
>>
>> Ale nie za fafdziesi?t tysięcy... no chyba że piracimy, wtedy tak.
>
> To zalezy ile pakietow sobie dokupisz.

Interesowały mnie bilbioteki do projektowania filtrów cyfrowych.

> Matlab edu to koszt az 400 zlotych bodajze. Bez przesady.

edu mnie "nie urządza".

--
Azarien

do góry

Mariusz Marszałkowski <m...@g...com> wrote:
> Witam
>
> Od dość dawna słyszę opinie że procedury zaimplementowane w
> matlabie są bardzo wydajne. Nie znam matlaba, ale wczoraj przez
> przypadek miałem go pod ręką, no i tyle ile można się nauczyć
> przez godzinę sprawdziłem.
>
> Program w matlabie robił coś takiego:
> for i=1:20000
> v = a * m1;
> a = v * m2;
> end;
>
> Gdzie v i a to wektory double po 1000 elementów, a
> m1 i m2 to macierze po 1000 na 1000 elementów.
>
> Zainicjalizowane były losowymi liczbami.
>
> Program wykonywał się około 100 sekund.
>
> Na tym samym sprzęcie odpaliłem podobny
> program napisany w C, skompilowany gcc.
> Program w C był podobny, a nie taki sam,
> gdyż robił ciut więcej obliczeń. No i w C
> wykonywało to 70s.
>
> Więc to tylko plotki że matlab jest taki wydajny?
... generalnie sila matlaba tkwi nie w szybkosci, ale
w toolkitach do specjalizowanych obliczen z danych dziedzin.
Z powazaniem
Adam Przybyla

do góry

On Tue, 19 Jan 2010 11:52:49 +0100, "Wiktor S."
<wswiktor&poczta,fm@no.spam> wrote:

>Interesowały mnie bilbioteki do projektowania filtrów cyfrowych.

Czyli ograniczony zakres.

>> Matlab edu to koszt az 400 zlotych bodajze. Bez przesady.
>
>edu mnie "nie urządza".

Wiesz, jezeli bedziesz zarabial na tym, to i bedzie Cie stac, zeby
dodac jedno zero na koniec kwoty. Poza tym bez przesady -- rownie
kosztowne sa pelne wersje softu bylego Borlanda, czy Microsoftu.

milego dnia, hej

do góry

On 18 Sty, 13:15, Mariusz Marszałkowski <m...@g...com> wrote:

> Program wykonywał się około 100 sekund.
>
> Na tym samym sprzęcie odpaliłem podobny
> program napisany w C, skompilowany gcc.
> Program w C był podobny, a nie taki sam,
> gdyż robił ciut więcej obliczeń. No i w C
> wykonywało to 70s.
>
> Więc to tylko plotki że matlab jest taki wydajny?

bardzo chcialbym zobaczyc ten kod. Jakos nie wierze, ze ad hoc
napisany kod mnozenia macierzy jest szybszy od MKLa.
Nie zapomniales przypadkiem o jednym zerze w petli w kodzie C?

do góry

On 21 Sty, 08:57, thrunduil <t...@w...pl> wrote:
> On 18 Sty, 13:15, Mariusz Marszałkowski <m...@g...com> wrote:
>
> > Program wykonywał się około 100 sekund.
>
> > Na tym samym sprzęcie odpaliłem podobny
> > program napisany w C, skompilowany gcc.
> > Program w C był podobny, a nie taki sam,
> > gdyż robił ciut więcej obliczeń. No i w C
> > wykonywało to 70s.
>
> > Więc to tylko plotki że matlab jest taki wydajny?
>
> bardzo chcialbym zobaczyc ten kod. Jakos nie wierze, ze ad hoc
> napisany kod mnozenia macierzy jest szybszy od MKLa.
> Nie zapomniales przypadkiem o jednym zerze w petli w kodzie C?

Wręcz przeciwnie. Kod w C tak naprawdę przeliczał ogromną
sztuczną sieć neuronową, więc macierze w C były o jeden
element większy i dodatkowo obliczał funkcję: 2/( 1 + exp( -x ) ) - 1.

Ale oczywiście mogłem się gdzieś pomylić, nie mam kodu na
tym komputerze, poproszę żeby mi przysłali i go wkleję.

Pozdrawiam

do góry

On 19 Sty, 07:15, Mariusz Marszałkowski <m...@g...com> wrote:
> On 19 Sty, 02:52, bartekltg <b...@g...com> wrote:
>
> > On 18 Sty, 20:26, Mariusz Marszałkowski <m...@g...com> wrote:
>
> > > Nie rozumie, a co ja porównałem jak nie mnożenie macierzy?
>
> > Porownales wektor * macierz. Ja zastanawialem sie nad porownaniem
> > mnozenia 2 macierzy kwadratowych (i nieco wiekszych niz 1000).
>
> Nie wiem czy się skuszę (mam masę innych rzeczy do testowana) na
> taki test, ale może... Nie znam tego algorytmu który ma mniejszą
> złożoność niż N^3. Obecnie jakie jest dokładne teoretyczne
> ograniczenie?

Coppersmitha-Winograda daje n^2.376, ale stala jest tak duza,
za na razie komputery nie bawia sie takimi macierzami pelnymi.

Niby mozna uzywac algorytmu Strassena (n^log_2 7 = log^2.807),
ale ma on klopoty z numeryczna stabilnoscia. Blas uzywa n^3
(jeszcze do tego wroce).

> Może jakbym miał przystępnie opisany ten algorytm to bym napisał w
> gołym C.
> Zapodajcie linka do dobrego algorytmu, może spróbuję.

http://en.wikipedia.org/wiki/Strassen_algorithm
ale IHMO nie ma sensu n^3 starczy.

> > > Napisałem wydajniej to co opisałem: mnożenie macierzy o
> > > rozmiarze Nx1 przez macierz MxN. Super wydajny pakiet powinien
> > > mieć specjalną implementację do takich macierzy.
>
> > A nie jest to wydajne? Masz czas tego samego rzedu co w jezyku
> > kompilowalnym (i to skompilowanem pod swoj system i procek!).
>
> Zależy jak oceniać. Słyszałem opinie z których wynikało że
> matlab to wszystko robi z 50 razy szybciej. W świetle tamtych

http://ubuntuforums.org/archive/index.php/t-1295370.
html
:)

> opinii wypadł śmiesznie, i głównie to chciałem sprawdzić. A
> czy jest 2 razy szybszy czy 2 razy wolniejszy to osobiście
> zgadzam się że nie powód do oceniania pakietu. Chciałem się
> tylko upewnić czy nie jest 50 razy lepszy :)

50 na dzien dobry brzmi smiesznie.
Ale nadal bede mowic, ze sprawdziles to dla
danych nieso spoza zakresu w ktorym matlab jest dobry.

> Przy jednym z moich projektów miesięczny rachunek za energię
> na komputery liczące to około 1000zł. Dużo nie brakuje aby
> starczyło na wypłatę dla nastepnego programisty...

Teraz polowe zaoszczedzisz.. Student na pol etatu na to pojdzie?

> Właśnie od różnych ludzi i z różnych środowisk, w
> końcu mnie sprowokowali.

Skoro sprowokowali, to zrob uczciwy test na duzych
maciezach a nie pitu-pitu wektorkami po 1000 elementow:)

> > Moze rzeczywiscie pisali mnozenie macierzy w javie;)
>
> Sadze ze w ogole nie pisali i w ogole nie porownywali czasow,
> tylko ulegli marketingowi matlaba.

:)


> Ale mogil sie postarac a wrecz powinni. Wystarczy rozpoznac
> ze mnozymy wektor przez macierz i dac goto do wyspecjalizowanej
> procedurki. Tak samo jesli mnozymy macierz [NxK] przez [KxM] dla
> M i N znacznie wiekszych niz K, to jakas wyspecjalizowana procedura
> wymnozylaby duzo szybciej niz ogolna.

Dla bardzo malych K mozna by sie bawic w rozwijanie petli.
Dla wiekszych - nie ma znaczenia przy algorytmie n^3.


> > Ja nadal uwazam, ze jesli pakiet numeryczny daje ten sam rzad
> > wielkosci, to jest przyzwoity wynik.
>
> Ja tez tak podejrzewam, ale teraz tez wiem ze nie ma
> implementacji 50 razy wydajniejszych.

Za to sa 50razy mniej wydajne;)

> > W miare mozliwosci (trzeba napisac) zrob to porownanie przy mnozeniu
> > dwuch macierzy 1000x1000. Roznica powinna sie znacznie zmniejszyc.
>
> Nie obiecuje, ale sprobuje, tylko zapodajcie dobry opis algorytmu,
> nigdy
> nie implementowalem lepszego algorytmu mnozenia macierzy.


> Może mieć algorytm o lepszej zlozonosci niż N^3 i
> jego moc się nie ujawnia gdy mnozymy macierze
> podobne do wierszowych.


Nie. Matlab, (mimo mojego natkniecia sie na informacje,
ze jednak) nie korzysta z szybszych algorytmow
(przynajmniej dla macierzy rzedu 1000-2000).

Dowod literaturowy. Matlab korzysta z BLASa jako
silnika do operacji na macierzach:
http://www.mathworks.com/access/helpdesk/help/techdo
c/ref/mtimes.html
[*]
Wiki gdzies wsponilala, ze BLAS uzywa dla duzych macierzy jakios
modyfikacji
Strassena, jadnak w kodzie tego nie widac:
http://www.netlib.org/blas/dgemm.f (macierz macierz).

Dowod statystyczny (12 macierzy o wielkosciach ciut ponizej 1000 do
ok2000):
wyn=[];for j=95:110; n=floor(2^(j/10)); a=rand(n); b=rand(n);
tic;a*b;wyn=[wyn;n,toc], end;
plot(log(wyn(:,1)),log(wyn(:,2)),'*' ) %poogladajmy sobie
[s,serr]=lscov([x,ones(size(x))],y)

Czas algorytmu to n^k hdzie k= 2.99 +- 0.06

Wiec n^3. Przynajmniej nie bede sie bac o stabilnosc numeryczna.

Jednak polecam napisanie tego n^3 i porownaine z matlabem.
Moze ci 'z roznych srodowisk' nie mylili sie tak bardzo
i kombajn bedize szybszy od napredce zmajstrowanego
programiku (pomijajac wspolczynnik 50 wziety z sufitu;)

pozdrawiam
bartekltg

[*] z tego linku wynika tez, ze jednak uzywa dgemv, czyli
specjalizowanej procedury macierz-wektor.

Czyzby 1000 bylo nadl tam mala liczba.
Moze porwnajmy monzenie M_kxn * wektor_n
gdzie n rzedu 10^6 a k rzedu kilkadziesiat.

do góry

On 21 Sty, 09:05, Mariusz Marszałkowski <m...@g...com> wrote:

> Wręcz przeciwnie. Kod w C tak naprawdę przeliczał ogromną
> sztuczną sieć neuronową, więc macierze w C były o jeden
> element większy i dodatkowo obliczał funkcję: 2/( 1 + exp( -x ) ) - 1.
>
> Ale oczywiście mogłem się gdzieś pomylić, nie mam kodu na
> tym komputerze, poproszę żeby mi przysłali i go wkleję.

To jest w zasadzie niemozliwe. Kod mnozenia macierzy jest bardzo
zlozony. Bez naprawde dobrze stuningowanego memory use, wstaweg
asemblerowych
i dlugiego testowania parametrow optymalizacyjnych nie ma szans na
zblizenie sie do wydajnosci Matlaba. Istnieja szybsze implementacje
mnozenia macierzy,
np GOTO blas jest ok 10% szybszy, ale i tak to jest w zasadzue
technologiczny limit na dzisiaj.
Kod Matlabla (tj bibliteka MKL, matlab nie napisal tego kodu sam)
jest o rzad wielkosci szybszy od dobrze stuningowanego kodu w C.

do góry

On 21 Sty, 09:18, bartekltg <b...@g...com> wrote:

> > Ale mogil sie postarac a wrecz powinni. Wystarczy rozpoznac
> > ze mnozymy wektor przez macierz i dac goto do wyspecjalizowanej
> > procedurki. Tak samo jesli mnozymy macierz [NxK] przez [KxM] dla
> > M i N znacznie wiekszych niz K, to jakas wyspecjalizowana procedura
> > wymnozylaby duzo szybciej niz ogolna.
>
> Dla bardzo malych K mozna by sie bawic w rozwijanie petli.
> Dla wiekszych - nie ma znaczenia przy algorytmie n^3.
>

Może to rzuci jakieś światło na całą dyskusję (slaj 16ty):
http://www-users.mat.uni.torun.pl/~bala/wyklad_arch/
wshop2000.pdf
Złożoność ciągle jest N^3 ale działa szybciej niż pętelki.

Blokowe mnożenie wykorzystuje ATLAS. Idea jest taka, żeby
cache maskymalnie efektywnie wykorzystać.
Ja kiedyś robiłem porównania ATLAS vs ręczny kod i ATLAS był
dużo szybszy. Z tego co pamiętam to oprócz mnożenia rozwiązywałem
układy równań.

Pozdrawiam,
Wit Jakuczun

do góry

On 21 Sty, 09:28, Wit Jakuczun <w...@g...com> wrote:
> On 21 Sty, 09:18, bartekltg <b...@g...com> wrote:
>
> > > Ale mogil sie postarac a wrecz powinni. Wystarczy rozpoznac
> > > ze mnozymy wektor przez macierz i dac goto do wyspecjalizowanej
> > > procedurki. Tak samo jesli mnozymy macierz [NxK] przez [KxM] dla
> > > M i N znacznie wiekszych niz K, to jakas wyspecjalizowana procedura
> > > wymnozylaby duzo szybciej niz ogolna.
>
> > Dla bardzo malych K mozna by sie bawic w rozwijanie petli.
> > Dla wiekszych - nie ma znaczenia przy algorytmie n^3.
>
> Może to rzuci jakieś światło na całą dyskusję (slaj
16ty):http://www-users.mat.uni.torun.pl/~bala/wyklad
_arch/wshop2000.pdf
> Złożoność ciągle jest N^3 ale działa szybciej niż pętelki.
>
> Blokowe mnożenie wykorzystuje ATLAS. Idea jest taka, żeby
> cache maskymalnie efektywnie wykorzystać.
> Ja kiedyś robiłem porównania ATLAS vs ręczny kod i ATLAS był
> dużo szybszy. Z tego co pamiętam to oprócz mnożenia rozwiązywałem
> układy równań.
>
Uzupełnienie:

http://www.mimuw.edu.pl/~przykry/matmult.php

Pozdrawiam,
Wit Jakuczun

do góry